I've added that code into the place the OpenGL context is initialised and it certainly sorts out the text. I've #ifdef'd WIN32 so Linux won't be affected.
I'm still having trouble with the ship textures though. Say you launch from the station and switch between fullscreen/windowed mode. The station and docking port disappear and the flashers become blocks. Everything else looks okay, and I think any new ships that turn up will be okay because their texture will be reloaded. It seems any ship already present will have a problem. Although the planet seems to look okay - why would that be?
Is there a way to tell all entities their textures have gone and need to be reloaded?
Procedurally coloured, but not textured (unless you specify a texture).
It's a nice two-colour subdivision procedure that gets some noise and gradations added to complete the alien-planet look.
Dajt, you should look at the initialiseTextures routine in Entity.m for ideas as to how to invalidate the textures for each entity and force them to be reloaded.
Or wait for/collaborate with Ahruman's new texture handling routines.
"The planet Rear is scourged by well-intentioned OXZs."
Flushing textures should be trivial when the new texture and model code in place. With the texture code only, it’s merely relatively easy… I’ll look into setting it up. :-)
- (void) reloadTextures
{
#ifdef WIN32
int fi;
for (fi = 0; fi < n_faces; fi++)
faces[fi].texName = 0;
[self initialiseTextures];
[self generateDisplayList];
#endif
}
I've not made the method itself conditional, only it's contents, because some other platform may need it.
Now this nearly works, but not quite. It reloads some textures but not all. For example, the spinning cobra gets it's skin back, but no details like the front window. The station lights still come up as blocks... I thought it might be subentities causing it, but I did a ShipEntity specific version that reset the subentities as well and it didn't fix the problem. Stars and planets look bad too.
EDIT: Corba doesn't get it's skin back, but because the base model is grey I thought it did. This could be a clue as to why some models get no/incorrect textures.
So progress is being made, but no prize yet.
Last edited by dajt on Wed Apr 12, 2006 6:37 am, edited 1 time in total.
Yes, particles like flashers have a separate texName variable that will need to be reset somehow, best to write a different reloadTextures for the ParticleEntity class.
"The planet Rear is scourged by well-intentioned OXZs."
You may be overcomplicating things. Due to a strange design decision in OpenGL, it is entirely valid to reuse the old texture names in the new context without calling glGenTextures(), as long as you redo the set-up. (This will probably be deprecated, but still useable, in OpenGL 3.0.)
That is what is causing the problem... for some reason on Windows the texture data is corrupted and reusing the old texture names just shows rubbish.
It must be something to do with the Windows drivers, because it doesn't happen on the same PC running Linux.
You have to at least clear the texture names in the entity instances and TextureStore to force new versions to be loaded, and I figured if I'm doing this I may as well delete the corrupt textures and free their video memory.