Also, please wait a few moments before replying. I tend to edit my posts a few times after making one, instead of double-posting if I need to add something else.
I really don't wish to be so hostile right now, but really... I don't like it when someone acts like a know-it-all, saying something's wrong or that I'm incompetent when they haven't a clue about the situation, the context, or what actually is wrong without first seeing the source to begin with and familiarizing themselves with it. This is still early in development, I'm in no way spinning my wheels. Shit's getting done, it just isn't finished yet.
About the software mode thing, I don't need to re-clarify, my old post says this:
Quote
As for the shadows and lighting, well... first thing, GL_LIGHTING isn't even on. In fact, none of the lighting is done in OpenGL, there's no need currently. Hellbender has it's own lighting system, and it's extremely fast, and has no impact on performance (it ran on a Pentium after all). The intensity value that Hellbender assigns to a vertex, which is in the range of 0-255, is applied directly as the vertex color. So, a vertex that has the intensity of say... 128, has the vertex color of (0.5f, 0.5f, 0.5f) in OpenGL.
Shadows are rendered like any other model in the game, however, unlike software where it would render shadows to a 64x64 framebuffer (a simple char array), it now sends the polygons to OpenGL with the POLY_SHADOW flag. When that flag is passed with a GLdrawPolygon call, it switches from the main framebuffer to the FBO, draws the shadow polygons to the FBO, then switches back to the main framebuffer. This happens not randomly, but it happens very often.
First, the model of the object is drawn, then the objectDraw function (part of TV, not my code) calls AddShadowToDisplayList, which then has a callback that'll draw the same model blackened, to the shadow buffer. So for each model, it draws to the main framebuffer first, then switches to the shadow buffer, draws there, and then repeat the process for all models in the scene. Keep in mind, I already have an idea of how I can make this process faster. Also, it isn't the biggest framerate killer, and if I can solve the biggest culprit, this part may not push the framerate below 60 anyway.