Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 22 Feb 2006
Offline Last Active Yesterday, 12:07 PM

#5222315 Messing with the depth buffer for skybox effect

Posted by gdunbar on 09 April 2015 - 04:09 PM

EDIT: Hey you're right, if I draw the planets and skybox first and then clear the z buffer, I should get exactly the output I want. I guess the only complaint would be that often the skybox takes up very little of the screen, and is therefore usually drawn last.


You're worried about the performance of drawing the full skybox, when usually it would be mostly blocked by objects in front? I'm hardly an expert on graphics performance but I wouldn't think it would be a big deal.


If you're really worried, you could experiment by drawing the skybox a bunch of times per frame and see how many you can do before it affects frame rate. If the answer is in the single digits, maybe worry about it... if in the hundreds, safe to ignore. That would be easy enough to do, and should quickly assuage your fears without doing serious profiling or anything.



#5222300 Messing with the depth buffer for skybox effect

Posted by gdunbar on 09 April 2015 - 03:24 PM

What if you just clear the z-buffer after drawing your planets, but before drawing everything else? You could even futz with the projection matrix at the same time, and, as you say, "make it real" by drawing the planets at their proper distance.



#5195891 Writing code more general

Posted by gdunbar on 02 December 2014 - 09:46 AM

The void pointer thing is troublesome. I may be missing some of the fine points, but to me, the point of having an interface like IMeshLoaderPlugin, and a method like IMeshLoaderPlugin::loadFile, is that, given an IMeshLoaderPlugin, you can call loadFile() without knowing what kind of plugin you have. In this case, that is lost; if you have an assimp plugin, you have to give it an AssimpDesc or it will fail. Worse, it will fail at run-time, not at compile-time.


So, my question to you: Is there some good reason to have a generic IMeshLoaderPlugin::loadFile method, and the related IMeshLoader::load function? Why not just have separate AssimpLoader::loadAssimpFile and HeightmapLoader::loadHeightmapFile functions? You may well be getting some other benefit from the generic IMeshLoaderPlugin::loadFile method that I'm just not seeing. However, if I were you, I'd be looking at my class abstraction carefully. If you really have plugins that are not interchangeable, then you probably don't need any of this enum stuff in the first place.


Anyways, I hope that's a little helpful. I've probably asked more questions than supplied answers. Good luck!


#5168350 How dangerous is returning a initialized pointer in C++?

Posted by gdunbar on 22 July 2014 - 06:07 AM

All the discussion about smart pointers is great. However, it is possible to make the original code safe (or safer) without using smart pointers. You need to use a static function for Create, instead of a standard function. A static function is part of the class, but doesn't access any of the class members, and thus is safe to use even if you don't have an instantiated object. So, change:

EngineAPI *Create();


static EngineAPI *Create();

And change:

gEngine = gEngine->Create();


gEngine = EngineAPI::Create();

Again, all the smart pointer and ownership discussion is great, but static Create functions are a pattern you'll often see, and are perfectly valid.



#5139766 Removing Large number of objects from vector immediately.

Posted by gdunbar on 17 March 2014 - 12:39 PM

How have you profiled this code? I suspect that the "delete list1;" call might be pretty quick compared to the allocations and push_back() calls (which will dynamically resize your vector). First step is to verify that the slow part is actually what you think it is.


Second step is to be sure you are using a non-debug build, as allocations and deletes can be significantly slower with debug builds.


If you are using Visual Studio, be sure to turn off the STL debugging stuff, too, as that can be frightfully slow.


OK, if all of that doesn't help (and I think it will), the big optimization I can think of is to move away from std::vector and use the C-style array allocation mechanism directly. Then you can allocate and free a while bunch of objects at once. This is not nearly as maintainable, though, so be sure to exhaust other possibilities first.


Hmm... an object pool could work too. Also to be avoided if possible.


Good luck!


#5000997 Virtual still the bad way ?

Posted by gdunbar on 14 November 2012 - 02:03 PM

Virtual functions are the bedrock of modern, object-oriented C++, and are unlikely to be a significant performance bottleneck on today's relatively fast processors. I recommend you proceed with using them. If at some point in the future, as a result of performance profiling, you do identify a virtual function or two that are slowing your code down (perhaps used very often in a tight loop), then address the problem locally at that time.

Good luck!

#4957634 Seeking in Direct Show

Posted by gdunbar on 10 July 2012 - 09:54 AM

No, that's not what you want at all. You aren't writing your own filter, just using existing filters.

The documentation isn't great, but this topic "Seeking the Filter Graph" should help:


It's the IMediaSeeking interface that you want.

Good luck!