Originally from: Bill
Author wrote:
There is now a 1.4a version on the glidos page. Honestly, you guys are
way more into the coding guts than I am. I kinda left off in the early
80286 x86 assy days. Might try some coding again. But I sure got a lot
of catching up to do!
Hm. Glidos can trap the system call, can't it?
McG.
Well, I wish I could say programming has gotten easier, but really it's just a shift in the way of thinking about problem solving. The method makes it easier to solve a lot of problems that used to be difficult...but of course programs now solve much more difficult problems instead. I suggest learning C++ and win32 API. if nothing it gives you a much better insight into the how and why of what modern computers do. and it's fun to make stuff. not nearly so difficult to get fun graphics and stuff on the screen, which means you can get to the fun to play with part before you get frustrated :)
Essentially that's all glidos does is trap system calls, and adapt them to call opengl instead. you are correct, glidos is just an operating environment shell. it doesn't know what TR is doing internally, or why. it merely responds to glide system calls such that the output is correct and the program gets the proper returned values. It doesn't, and CAN'T really know when TR has done something that would require it's textures reloaded, for example. on the other hand, Glidos can dump IT'S textures, since they're stored in a separate format, in real VRAM most likely, with their own index IDs. but glidos SHOULD know to reload in those cases, because now were talking about glidos locally managed data (the IDs are at least, the textures themselves are managed by opengl in VRAM). The ID's weren't getting updated, which is glidos own data, TR has no clue, just as glidos has no clue what TR is doing. say TR loads a level. It dumps the texture cache, and reloads the texture set for the new level. These textures would be uploaded to glides memory for use by TR, in the form of a system call, and this texture would be assigned a texture ID by which TR could tell glide which texture it wanted. the system call is trapped by glidos, which loads the texture, a glide ID that TR is expecting is probably matched it to a openGL ID, and the texture is converted to opengls native texture format, and stored (most likely) in VRAM. if glidos' texture load is called, that's all glidos knows...it doesn't know whether TR wants a new texture because it's loading a level, or refreshing an existing texture. on the other hand, if windows interferes with the programs operation, or if the user alt-tabs, or the screen saver comes on, or the video mode is switched (for video playback or to got to the main menu, or yes...when a level is loaded....) then most likely openGL dumps the textures (mode switches usually require that all services be shut down and restarted, I'm not too familiar with OpenGL, but Direct3D works this way). and since T R isn't aware of this (glide is running in a DOS driver which doesn't handle such problems), it doesn't care, it sends no special signal, it just keeps right on going, and glidos is now drawing with invalid ID's, which end up being random video memory most likely, which is generally kept cleared to zero but some sections are normally just padding, or recently used, and these can show up as green stripes or noise. I believe(I'm guessing) that the order I listed the textures disappearance would correspond to their position in the texture list somehow, probably towards the higher ID's in the list.
Now this is just a guess on what's happening, though it's probably a pretty educated one :) I'm just now learning the finer points of 3D graphics, and I'm starting with Direct3D since I already know the rest of the API, though I am familiar with OpenGL's API interface and such. It makes perfect sense, and I'll try an extended run of Tombraider with v1.14a today, and let you know the results.
