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
Online Last Active Today, 01:11 PM

Posts I've Made

In Topic: Writing code more general

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!


In Topic: Problem with Guest comments on Dev Journal

13 November 2014 - 07:28 AM

How much spam are we talking here? If I'm going to get more than a couple of spams a day, I'm not sure I want to moderate comments anyways. In that case, I suppose just making it more obvious that registration is free is probably the best I can hope for.




In Topic: Is there a better way to flip texture in OpenGL

29 October 2014 - 06:52 AM

Well, you could get rid of the if's with a few tweaks and some math tricks. Something like (note: untested, but you should get the idea):

public void draw(int x, int y, int width, int height, float xp, float yp,
            float xdirection, float ydirection) {
        x = x + ( 1.0f - xdirection ) / 2.0f * (float) width;
        float spriteX = (float) x / (float) tex.getTextureWidth();
        y = y + ( 1.0f - ydirection ) / 2.0f * (float) height;
        float spriteY = (float) y / (float) tex.getTextureHeight();

        float spriteWidth = (float) width / (float) tex.getTextureWidth();
        float spriteHeight = (float) height / (float) tex.getTextureHeight();

        float spriteX2 = spriteX + xdirection * spriteWidth;
        float spriteY2 = spriteY + ydirection * spriteHeight;



// in game loop:
atlas.draw(0, 0, 16, 16, 0.0f, 0.0f, -1.0f, 1.0f); // flips horizontal

I'm not entirely sure this will be any faster than just using the 2 if statements, though. You'd want to test and be sure.


Hmm, thinking more... you could probably pre-compute all this stuff, as well, and save all of the floating point math. Presumably right now for a sprite you are storing x, y, width, height, flipHoriz, and flipVert. If you store spriteX, spriteY, spriteX2, and spriteY2, then you only calculate them once, not every rendering loop. That seems like the best option if performance is an issue.


Just some thoughts!


In Topic: How dangerous is returning a initialized pointer in C++?

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.



In Topic: Bitmap loader: Memory corruption and debugging

16 May 2014 - 09:29 AM


I'm not saying that it isn't the problem, but I have the feeling that I've written beyond one of the pointers I've manually allocated.  This error has manifested itself before, and I am quite sure that is where I am screwing up.  If my theory in response #4 is correct, I might end up just using .tga instead..



Seems most likely. Here are the steps I would take:


1) Get a consistent reproduction of the crash. Writing a simple test app that simply loads and unloads a bitmap over and over might be a good start. Keep adding stuff until you can repro, but the simpler the better.

2) Once you have that, see if you can figure out why it is breaking. If (as seems like a reasonable explanation), you are writing past allocated memory, try allocating the buffer slightly bigger, and then (right before you free it) see what got written past the expected end. Set a memory breakpoint on that location and figure out what code is going wrong. Etc.


If you can't get a consistent repro, things are a little harder. Again, get a test program that crashes every time, if not in the same place. Randomly loading bitmaps until boom. Then, start removing code until it stops crashing. The last thing you removed was your bad actor.


Good luck, memory corruption bugs can be very frustrating.