Hi again,
I haven't been able to spend much time on finishing this (usual real-life stuff getting in the way that we all endure
) but I've added some bits:
- (very) basic textures on buildings/grass/water
- rooftops/mounds
- waves...well water movement, hardly realistic motions!
- erm...a scroller...always a scroller...but I've implemented it differently so it's staying in for now
Anyway, the purpose of this prog for me was/is as a learning exercise, and there's been stacks of C++/OpenGL learning been done which is why it's taking so long...one such learning curve is that I OO'd it then eventually found that new/delete and memalloc/free link to the MSVCRT.DLL...so de-OO'd it and used GlobalAlloc/GlobalFree instead to avoid the __chkstk errors from my huge static arrays at the time (I haven't implemented my own new/delete routines yet)...which brings me to an issue I'm currently stuck on, and I'm really hoping someone here has some suggestions...
...when I enable the VC 2005 size optimizations, my textures go wrong (compare debug and release EXEs) - they look different...if I make the debug version use the size optimizations it also looks wrong, so I have tracked it to the optimizations specifically. The textures are created in the Shapes.cpp's InitTextures method and are stored using pointer arrays allocated using GlobalAlloc, extract here:
void InitTextures() {
GLubyte **textureStore = (GLubyte**)GlobalAlloc(GPTR,TEXTURES*sizeof(GLubyte*));
for (int t=0;t<TEXTURES;t++) {
textureStore[t] = (GLubyte*)GlobalAlloc(GPTR,TEXTURES*TEXTURE_SIZE*sizeof(GLubyte));
}
...
glGenTextures(TEXTURES, textureIDs);
for (int x=0;x<TEXTURES;x++) {
glBindTexture (GL_TEXTURE_2D, x);
// Texture repeats over both S & R axis so out of range co-ords still get textured
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, TEXTURE_WIDTH, TEXTURE_HEIGHT, 0, GL_RGBA, GL_UNSIGNED_BYTE, &textureStore[x][0]);
}
// Free dynamic array
GlobalFree(textureStore);
}
I've tried giving textureStore broader scope by defining it out of the method, also removing the GlobalFree altogether (as in attached source) without any difference...mainly because I figure that if the optimization is affecting it then maybe my texture memory is being seen as available and something is stomping over it, but the corruption seems consistent which kind of shoots that theory really...maybe the optimizations use different data types under the hood yielding different values or something like that?
BTW this is regardless of whether I use Crinkler or not so it's not the compressor trashing data or anything like that.
Anyone come across stuff like this before? I'm away from my computer for a week (not sure how I'll cope) - but thanks in advance for any ideas if you have any!
Correct kind of view (without optimization):
Wrong kind of view (with size optimization):
Apart from this issue the code itself seems to work fine, albeit quite hard going on the CPU/GPU, and I've put as many comments in as I can - in case anyone sees something they want to try and improve on in their own intros...I'm at the 4k limit, so I'll have to start making the code optimizations (i.e. will be unreadable) now to fit stuff in
PS Shockwave - cheers for the mention in the gears intro - I was/am totally gobsmacked!
