Mocha Doom renderer performance ;-)

[Maes]

I finally ironed out almost all of the bugs in the renderer (must finish up masked columns), and even went a bit crazy with optimization by re-enabling the loop unrolled versions of R_DrawColumn and R_DrawSpan.

Furthermore, screen scaling proved to work reliably, and so I could experiment with raising the resolutions using fixed multipliers.

The results?

On a Pentium 4 @ 3.00 GHz, A flyby in E1M1 averages:

• 850 fps in 320 x 200 mode.
  
• 300 fps in 640 x 400 mode.
  
• 150 fps in 960 x 600 mode.
  
• 90 fps in 1280 x 800 mode.
  

I was actually surprised that it scaled up so acceptably. This means that framerate can actually be competitive -or at least comparable- with native source ports, and the end result will be tons faster than Flash Doom and even STARK. And that's without having brought in all Boom enhancements yet, and while having a much more "Doom compatible" and moddable codebase.

Now I don't recall what performance the older STARK engine got at those resolutions on similar hardware, but I recall it was nowhere near those figures. As usual, grab the stuff from the repo and fire up AWTRenderViewTester from the testers package. You won't be disappointed ;-)

P.S.: this is performance obtained using just pure Java code and standard AWT Java2D output. No OpenGL, no JNI, no external C libraries, no native, platform-dependent addons of any kind. And IMHO that's no little feat in itself.

Big screenshot of E1M1. I got a little crazy with this one e.g. all sprites are rendered with the invisible effect just for kicks, and there are some visible column misalignments which I still have to iron out. But hey...


Edit: I adapted Lee Killough's DrawColumn function, and it works better than the buggy Linuxdoom one (it's easy to swap them in and out due to the design of Mocha Doom). It's incredible how Java actually benefits from explicit loop unrolling, and it seems that a value of 4-8 is the "sweet spot".

[Spleen]

Awesome, glad to hear things are going so well!

Maes said:

It's incredible how Java actually benefits from explicit loop unrolling, and it seems that a value of 4-8 is the "sweet spot".

Doesn't that just mean the compiler sucks at optimization, though? :P

[Maes]

Spleen said:

Doesn't that just mean the compiler sucks at optimization, though? :P

I wondered that myself, but if you look at the unrolled loop, I doubt that any compiler in any language would catch that: the fixed point arithmetic, the non-trivial index progression and non-horizontal pixel arrangement would easily foil most automated attempts at unrolling. AFAIK only FORTRAN would be able to optimize successive-row accesses to some degree (due to its native column-major array format), and then it would also be confused by the fixed point computations.

Besides, I've seen manual unrolling used in C and C++ code too when there were non-trivial operations involving array transposition or other types of access that fuck up memory order.

[LexiMax]

Fantastic work Maes. Good to see you making so much progress.

I did notice some weirdness in your screenshots though. The most obvious one is the Tutti-Frutti effect on some of the walls, but I also noticed that if you look at the floor textures on the right hand side of the screen, there is this really weird zig-zagging pattern on the floor and ceiling. Any idea what's causing either effect?

Also what's wrong with LinuxDoom's DrawColumn and how does Lee's function fix it?

[Csonicgo]

AlexMax said:

I also noticed that if you look at the floor textures on the right hand side of the screen, there is this really weird zig-zagging pattern on the floor and ceiling. Any idea what's causing either effect?

that's literally doom's span "precision" going out the window. It is fixable (EE has the code to do it, pre- and post- cardboard).

[Maes]

AlexMax said:

I did notice some weirdness in your screenshots though. The most obvious one is the Tutti-Frutti effect on some of the walls

Yup, fixed that by using Killough's code rather than the LinuxDoom unrolled DrawColumn, which "misses" certain offsets.

AlexMax said:

but I also noticed that if you look at the floor textures on the right hand side of the screen, there is this really weird zig-zagging pattern on the floor and ceiling.

Good observation (that the problem in mainly on the right), so I will have to check the view plane functions (I'm guessing some math slipup, however it's only noticeable at higher-than-vanilla resolutions). Also, when actually moving, this also causes some weird small-scale floor warping, possibly related.

@Csonicgo: thanks, I'll take a look at that too.

Also, despite my original intent of making Mocha Doom more, well, Doom than Boom, I find it progressively easier to include Boom and other advanced port code in it, either for performance or stability. So in the end it will end more Mocha Boom than Mocha Doom, but hey...

[Mr. T]

This looks amazing Maes, well done.