   wacky bug with int, warning WTF is what you'll think
  I have a wacky bug with int, WTF is what you WILL thinkhttp://www.sendspace.com/file/9a0bmxif you compile the app and put a break point on line 68 of s2d_ft.cpp  you'll see y = 449 (which is target_height(480) - slot->bitmap_top(15)). Now, here is the kicker. If you do y = 449 on line 67, which doesnt change the value of y. The letters WILL be rendered differently. w/o adding y = 449 you'll see te with the top of e lower then the top of t. if you add y = 449 they will start at the same height. WTF!I am compiling with visual studio 2005, you'll need sdl, freetype and freeimage.   
  The behavior you're describing sounds like you could have an issue where you're corrupted the stack, or you're reading data off the stack from where you're not supposed to be reading. This kind of behavior can seem even weirder if you have optimizations enabled.Do you mind posting the relevant code here?  No offense or anything, but I'd rather not download random zip files.   ;  i pasted it earlier today http://rafb.net/p/lg2dDT82.htmla stack corruption does sound logical, i cant see it in this code. I kept thinking int was updating a struct instead of an actual int but... i dont see how i could of corrupted it in code.btw a lot of that code is from the freetype tutorial http://freetype.sourceforge.net/freetype2/docs/tutorial/example1.c fromhttp://freetype.sourceforge.net/freetype2/docs/tutorial/step1.htmlDont look at the tutorial, look at my code :X.Even if it was a stack corruption, i didnt change the value of y. Or maybe i did but visual studios didnt pick it up. adding thisprintf("%d ", y);y=449+16;printf("%d ", y);y -= 16;printf("%d \n", y);show 465 465 449 in both causes. one case where i comment out y=449+16; causing the e to start lower then t and the other where i didnt comment the y= out and got the e way up were the top of t was. weird.This is a debug build too.PS: Bug happens also with gcc, i am building with codeblocks + mingw. I primarily use visual studios but it nice to see that it isnt a compiler bug :X   ;  I've looked at your code and I really tried to find the mistake, but seriously (and I don't mean to offend) ... you badly need to get in the habit of writing CLEAN code ... this is some pretty bad spaghetti you got there, and I'm not surprised that you've managed to shoot yourself in the foot there. :For now I'd check all array accesses to make sure you never try to index an array past its end. Also, make sure all your pointers are set to null if they're not pointing to anything valid and check for null before you access them. Actually, that doesn't just go for pointers. Initialize ALL your variables to sane values or assign them proper values right away. For instance:MyObject* anObject = 0;// ... loads of code// ... finally make the pointer point to somethinganObject = new MyObject;is better thanMyObject* anObject; // pointer not initialized ... going to contain some random valuebecause accessing a null pointer will give you an error right away, whereas if you try to access an object via a pointer that contains a garbage address that might not cause problems right away, but then something else will go wrong later and you'll have a hard time finding out why.   ;  Hey Red Ant.Most of the code come from freetype so i try to leave it the same so ppl will recognize the few changes i made instead of changing it all and confusing guys who looked at the tutorial beforei'll clean it up and do another paste.   ;  Problem solved.I am an idioti was excepting y to always be the same value which is why i did 480-15. turns out the api updates a value that i didnt think it touched :X. when i did y=480-15 it was an incorrect assumption.