About: Performance optimizations

Description
Metadata
Settings
- owl:sameAs
- Inference Rule:

About: Performance optimizations Sponge Permalink

An Entity of Type : owl:Thing, within Data Space : 134.155.108.49:8890 associated with source dataset(s)

Lordtoran tried to summarize a few of the problems with the current engine in this thread on Scourgeweb: A few posts later he outlined a rough plan: Eihrul, former lead developer of Sauerbraten, hung out for a few weeks on #scourge and shared his thoughts:

Attributes	Values
rdfs:label	Performance optimizations
rdfs:comment	Lordtoran tried to summarize a few of the problems with the current engine in this thread on Scourgeweb: A few posts later he outlined a rough plan: Eihrul, former lead developer of Sauerbraten, hung out for a few weeks on #scourge and shared his thoughts:
dcterms:subject	Wishlist
dbkwik:scourge/pro...iPageUsesTemplate	dbkwik:resource/sLUR2OALFlelAetDSwoy7g==
abstract	Lordtoran tried to summarize a few of the problems with the current engine in this thread on Scourgeweb: A few posts later he outlined a rough plan: Eihrul, former lead developer of Sauerbraten, hung out for a few weeks on #scourge and shared his thoughts: * The render engine is currently full of hooks into other parts of the code which makes it very hard to reorganize the render sequence. * A speedup might be achieved by switching from display lists to vertex arrays or VBOs (where available) and tag the objects to draw by the render states they require, and then draw the scene one tag after the other. This minimizes render state changes. * For higher-class hardware, vertex/fragment programs could be faster. This isn't hard to do and doesn't require an additional render path, as the driver will simply skip the fixed pipeline if FPs/VPs are enabled, and vice versa. * Switching to .md5 as the model format of choice will put less load on the vertex stage and conserve graphics memory, as animation is done via simple transforms and no interpolation vertices need to be calculated. Problem: No free .md5 models and modeling tools are available. Lordtoran has verified that the render engine indeed hooks into the other code to no end. Reorganizing the render loop and making the engine portable or even replaceable requires decimating these hooks, which is way too much work for a single developer so the project would have to focus exclusively on this issue for a while. As a result, the code would be cleaner, easy to optimize and (with a little effort) very, very fast. For low-end devices the engine could be replaced with a 2D one that uses prerendered imagery from the 3D version.

OpenLink Virtuoso version 07.20.3217, on Linux (x86_64-pc-linux-gnu), Standard Edition
Data on this page belongs to its respective rights holders.
Virtuoso Faceted Browser Copyright © 2009-2012 OpenLink Software