> >>>>From a game standpoint, think "quake engine". The actual game doesn't need >>>to tell the GX engine everything over and over again all the time. It >>>tells it the basic stuff once, and then it just says "render me". You >>>don't need DRI for sending the "render me" command, you need DRI because >>>you send each vertex separately. >>> >>You could view the static geometry of quake levels as a single display list >>and ask for the whole thing to be rendered each frame. >> >>However, the reality of the quake type games is anything but - huge amounts of >>effort have gone into the process of figuring out (as quickly as possible) >>what minimal amount of work can be done to render the visible portion of the >>level at each frame. >> >>Quake generates very dynamic data from quite a static environment in the name >>of performance... >> > > I think I understand...even though Linus is refering to Quake's wire > protocol here, you are pointing out that the real challenge is the > underlying game engine which is highly optimized for that specific > application. Am I correct?
I think the multiplayer aspects of the game are a separate issue. Talking about the difference between a big display list with the whole quake level in it and the visibility/bsp-tree/whatever-new-technique coding that quake & other games use to squeeze as much as possible out of the hardware. It may be that simple visibility issues are pretty well understood now, and that the competition between game engines is moving to the shading engines (and physics engines if the reports about doom 3 are right). Keith _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
