On Dec 29, 2007 10:44 PM, Kevin Gillette <[EMAIL PROTECTED]> wrote: > yes... that's a problem. if you keep increasing the GL requirement, the > majority of us will be unable to keep up without upgrading our hardware, and > it sounds like there's no plan to support a simpler renderer (and the very > existence of an alternate renderer would conflict with the code roadmap), > which means there'll probably be some inevitable code fork and a project > divide.
I really do not understand your point of view here. Are you saying that instead of working to create a more modern renderer with higher hardware demand, we should be working to reinstate the software renderer? Do you seriously propose that we should never increase the hardware requirements? > i'm not exactly sure what you mean by retained mode. afaict it's just a > highly optimized layer on top of immediate using display lists and similar. No, not in OpenGL terminology. From the OpenGL SuperBible: "There are two different approaches to low-level programming APIs for real-time 3D graphics—both of which are well supported by OpenGL. The first approach is called retained mode. In retained mode, you provide the API or toolkit with higher level geometric descriptions of your objects in the scene. These blocks of geometry data can be transferred quickly to the graphics hardware, or even stored directly in the hardware's local memory for faster access. The second approach to 3D rendering is called immediate mode. In immediate mode, you procedurally build up geometric objects one piece at a time. Although flexible, this suffers performance-wise." We wish to upload entities to be drawn to the GPU as static arrays of data that are ready to be drawn (retained mode), not by issuing one function call for each piece of graphics information in the scene frame (immediate mode). > either way, opengl is a state machine, and i can see nothing that requires a > dedicated choice between flexible use of immediate mode, and simple retained > mode use. for example, you could draw the terrain (i don't imagine how > you'd do that in retained without breaking the mesh into tile groups of > maybe 20x20 -- buffering and drawing the entire map would obviously be a > mistake), then draw the stuff that doesn't work well in retained, such as > defensive structures (or, iirc, the new "foundation" thing for defensive > structs), *then* have the retained mode stuff go to work. Actually, buffering and drawing the entire map may be far faster than drawing, texturing and colouring each vertex separately. The GPU is extremely fast at handling easily vectorized data, and our map "model" is not even very detailed. We *already* draw an entire map for the smallest maps - the currently rendered view is 64x64, and many maps are that large or only slightly larger. In any case, my plan is to make it draw 64 strips containing 64 tiles at a time from the map buffer, so that we only draw the seen part of the map. That is 64 function calls into OpenGL rather than 64 * 64 * 6 (vertices) * 3 (colour, geometry, texture) function calls, and since the data is prebuffered, it is *far* more easily vectorized. Remember that the GPU is a vector processing unit with lots of specialized cores running in parallel, and they have to chew on large data streams, or they won't be doing their intended job properly. > there are always > going to be effects that you need direct control of verts on a > frame-by-frame basis to achieve, and it doesn't look like there's any chance > of that in retained without overloading ram. I'm not sure what effects you are referring to. > there's always a future in > immediate mode... certainly that doesn't mean that everything should be done > in immediate mode, but to forsake it completely is ridiculous. without the > flexibility of directly controlling gl *at certain times*, then the only > thing the renderer is capable of doing is stacking childrens' building > blocks on top of each other with really good lighting. People achieve detailed control over vertex data (and even pixel data!) by using shaders nowadays. - Per _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
