Warzone 2100 Forums

are the changes to be made or design decisions/ideas documented somewhere? would hate to get in anyones way..

also.. what would be the requirements for a new shadowing code or terrain renderer? I have papers for a whole host of algorithms for (immediate/deferred) (dynamic/static) (volumetric/normal) lighting and shadowing as well as other stuff..

Requirements are basically OpenGL 2.0-compatible, fast, and pretty

Not much in the way of documented plans, I'm afraid.

OK I'll dust off my red book.

I think I'll best not work on code you are actively working on, especially if there are no documented designs.. Don't want to run into the situation where I am undoing your design as I go.

As far as shadowing and terrain rendering, can you tell me why you'd want this changed, or what you feel the problems with the current code are?

When I have that and I get my build running I'll go ahead and make it Warzone 2101 goodness for you

The current shadow code uses old school stenciling, which is now the biggest FPS-killer in the game. It scales horribly with number of models and model complexity.

The current terrain renderer is extremely messy, and slow. If you run without shadows, it consumes nearly all your GPU time.

I am rewriting the other old school OpenGL code mostly so that it can run on OpenGL ES 2. However, for graphics performance, shadows and terrain are the only ones that matter now.

For non-graphics performance, I think path-finding is where most of the processing time is consumed. However, this code has been optimized quite a bit already, and might be harder to optimize further.

Ooh, the good old stencil shadowing it's been a while.

I won't mind looking at the terrain- and lighting engine then. Shouldn't be a problem trying to get it all up to spec

Optimizing code and doing cool GFX awesomeness are among my favorite coding pastimes.

I'll see to it that the code will be OpenGL ES 2 compatible, then.

Per, did you make changes according to MINMAX_TSCEN parameter of wzm in your gfxqueue? Afair, it raises in-game fps with AR mod in massive battles a lot.

No, those changes are a bit outside the scope of gfxqueue. But if anyone wants to look at the WZM code, I can push it somewhere.

Also, in wzm code, texture's and connector's coords were float point. Will it affect netcode synchronization somehow?

IIRC only the dimensions that wzm keeps in TSCEN_MINMAX is used for game calculations, and everything else should be safe as floating point. It is possible that the connectors are also used, though...

*cough* postprocessing *cough*

Dunno how hard it would be to implement, but it would probably go fairly painlessly on top of whatever rendering is already present. Just add another framebuffer before dumping the image onto the screen, allowing for a custom fragment shader to play with. Would allow for experimenting with stuff like SSAO, "god rays" (assuming we render the sky as a separate pass) etc.

Anyway, this is not strictly necessary, just throwing out ideas in case I'll inspire anyone

IIRC, Connectors were floats. They were changed to ints for network sync reasons. Cyp would know more.

Jorzi wrote:*cough* postprocessing *cough*

Dunno how hard it would be to implement, but it would probably go fairly painlessly on top of whatever rendering is already present. Just add another framebuffer before dumping the image onto the screen, allowing for a custom fragment shader to play with. Would allow for experimenting with stuff like SSAO, "god rays" (assuming we render the sky as a separate pass) etc.

Anyway, this is not strictly necessary, just throwing out ideas in case I'll inspire anyone

Been away for a while.. was/am extremely busy for the boss-man Going to continue setting up a MSVC 2013 express build.

Interesting, yes. Had planned to see what was possible without removing too much hardware support for older systems.

IMHO we could always make some extra settings available for people with beefier GPUs/CPUs for these kinds of things.

Depending on what we want to support it will place some limitations on what we can do.. Simple stuff like max. shader length, number of available texture units and/or render surfaces, memory bandwidth, OpenCL support etc. can really mess with plans. I do have a substantial library of papers with cool algorithms for all sorts of crazy things.. Let's see where that takes us.

I remember some sort of distance fog in the original game which got lost some day. What happened to it?