Optimizing

[leileilol]

What are some to keep in mind?

I've already learned the hard way about having texture atlas/pages

[qbism]

Isn't that the trend? Entire scenes/maps with a single texture. UDK, etc.

[leileilol]

yeah but with bsp, tiled texturing and some 3d cards with 256x256 limits, ultrapaging everything isn't exactly feasible, but paging things like having muzzleflash, projectile AND impact on one texture, all the marks on another texture, etc. would help.

It's funny because Quake3 is fast and it didn't make an effort to atlas anything but the text....except on a OpenGL ES port where Q3 is a slug.

[mh]

Simplest optimization is to get your lightmap update parameters matching the actual native GPU formats. You can also quite easily remove a huge amount of pipeline stalling by scheduling them better.

Where to go from there depends on your target hardware. Do you have hardware T&L? Do you have shaders? What kind of bandwidth and fillrate are we talking about? These all influence the best places to attack next.

[Spike]

as you mention opengles, I assume you're making an arm/mobile port.

q3 does batching, but it uses memcpys to get those batches together.
arm devices don't exactly have a lot of cache, so memory access like that can be kinda slow.

combining multiple textures into one is problematic if you need to consider border regions between textures. this makes world/model textures rather painful, so when the content is not specifically designed for it, it only really works for 2d stuff.

Do you have an arm jit? try to compile gamecode natively?

quake3 uses about as many floats as quake1. make sure your arm port has hardware fpu enabled where possible.

various people seem to recommend using 16bit textures for mobile devices. I'm not sure if that's just due to memory usage or slowness with 32bit formats.

a device that supports only gles1 is generally considered too slow for a real fps. devices that supports gles2 are generally what you want to be using, even if you only use gles1.


the biggest optimisation possible is to get it to do nothing...

[mh]

[leileilol]

[Knightmare]

[Spike]

all PC hardware prefers GL_BGRA, for some weird reason, and GL_EXT_bgra is present in all windows-based opengl libraries, even microsoft's.

The general recommendation is to use internalformat=GL_RGBA8, format=GL_BGRA, type=GL_UNSIGNED_INT_8_8_8_8_REV (ie: the only byte ordering allowed by direct3d).

note that GL_BGRA is core in gl1.2 (but otherwise exists as GL_EXT_BGRA in all windows implementations).
note that GL_UNSIGNED_INT_8_8_8_8_REV also only exists from gl1.2, but is meant to be functionally identical to GL_UNSIGNED_BYTE on little endian systems.

This really only affects the speed of glTexImage calls and not the format stored on the gpu, so won't affect framerates in q3 at all, only load times. Quake1/2 engines will likely want to use it for lightmaps, but there are bigger issues there (like uploading the same lightmap 20 times per frame, along with multiple stalls) which should be addressed first.


leileilol: that video still has a higher framerate than fte running in the android emulator does.
mobile devices generally have shared video memory. the gles1 devices don't even support vbos - they'd be no faster. All I can really suggest is to reduce world geometry and make sure you're not overdrawing too much. Also avoid blending as that requires reading from the framebuffer too.
the fte android port is really just a gles1 port of fte, its basically identical to the pc version except for general gles issues (glClampd->glClampf, 16bit vertex indicies, glTexEnvf instead of glTexEnvi to work around android bugs... that's pretty much it, renderwise). It does also use 16bit textures, but not lightmaps because that would be more messy.
most people seem to get a playable framerate (>20) and enough seem to achieve vsync (at 55 or 60fps) that I'm not too concerned about raw performance with it. I do have to point out that q1 maps are generally quite a lot less detailed than your openarena maps, so I'm kinda wondering what the framerate differences is like with ftedroid and typical q1 vs q3 bsps.

[Knightmare]

Quake2 uses a temp lightmap image slot for the updates it does per-surface right before rendering each face. Batching these at the start of each frame will obviously require creating a second set of lightmap textures that are updated copies of the originals.

Minimizing uploads means updating each lightmap image with lightstyle and dlight info for every surface that uses it, before calling qglTexSubImage2D. Doing this efficently requires a way to quickly iterate through all surfaces that use a given lightmap image, and not looping through all surfaces in the BSP looking for a texturenum match for each lightmap image. Would using a special texturechain for each lightmap image generated on map load be the best way to do this?

What about for bmodels? Origin/angles for each bmodel are not available until it is rendered in the entity loop, so lightstyle/dlight info will need to be updated separately for each bmodel. Bmodels can be used by more than one entity, so batch updating their lightmaps at the beginning of the frame would be problematic, even if the entity info was available then.

[mh]

[Knightmare]

[Spike]

yeah, texture arrays mandate csqc.

if you're storing a chain of the surfaces in the lightmap, then I really hope that each lightmap has only a single texture, otherwise its pointless as each batch should have a single texture, and its probably faster to just glSubTexImage all surfaces in one go.

[mh]

[Knightmare]

Spike: That lightmap_surfaces pointer array is just a leftover from the old, removed two-pass lightmap blending code. I might repurpose it, though.

mh: Do the existing checks handle updates for the first frame when a surface is no longer dynamically lit, so that dlights are removed?