Report article RSS Feed Low-End System Support – Part II

In this post I'll talk more about the upcoming software renderer including progress, performance and future plans. Note that this work is happening in parallel to the version 0.20 support, the software renderer won't be available until after the next build.

Posted by luciusDXL on Apr 4th, 2011

In this post I'll talk more about the upcoming software renderer including progress, performance and future plans. Note that this work is happening in parallel to the version 0.20 support, the software renderer won't be available until after the next build.

As I've been working on the next release, I occasionally fiddle with the software renderer. Currently I'm writing it in a separate test app, to avoid integration issues until after version 0.20 is released. Until recently, screenshots would be really boring since it was all boilerplate code but I'll go ahead and show the first screenshot now:

Statistics for images shown:
Resolution: 960x600.
Current features:

  • 32 bit renderer (8 bit will also be supported with all the palette effects)
  • Perspective correct texturing
  • 16 bit Z-Buffer (will probably be upgraded 32 bit)
  • Sub-pixel/sub-texel accuracy (no wobbling edges or textures)
  • Per polygon color, used for lighting (supports RGB, only intensity shown here)
  • Z-Fogging using a fog table.
  • Clipping.

And of course it supports 2D blits (including arbitrary scaling):


Currently performance isn't where I want it to be for multiple reasons:

  • It's using GDI for the final blit which can be slow. Obviously it should use DirectDraw and/or Direct 3D when available (just for the final blit though).
  • The bottleneck is the actual rasterization, in the future this will be optimized using SSE/SSE2 when available. However this won't occur until it has all the base features.
  • SSE/SSE2 optimizations for other parts of the pipeline as needed (transform, clipping, etc.).

Some of the additional features required before integration (post-0.20):

  • Dynamic lights (using the proper radial attenuation).
  • Mipmapping (probably with mip selection done per scanline).
  • Various pipeline improvements, backface culling and so on.

Finally I plan on adding hierarchical z-buffer based occlusion culling - at the batch, polygon and maybe even span level in order to reduce overdraw to near zero. This, combined with an optimized rasterizer, should allow the software renderer to run at very high resolutions on modern CPUs. This is more practical with software rendering (or at least simpler to get right) due to the lack of latency and also the fact that it handles small batches very well, which means that rendering can be sorted from front to back at a finer granularity without hurting batch performance or state switching performance.

Ultimately the goal is 60fps at 1024x768 on a 1 GHz CPU. Once the final blit is fixed (i.e. not taking 11ms at 1680x1050 because of GDI), I'm close to that goal now but still have to make it faster using the above methods in order to also have gameplay too (i.e. collision detection, AI, combat, etc.). :)

SSE will only be used when available, potentially widening the CPU support if you run at low resolutions (i.e. 320x200 or 640x480).

Hopefully this will allow anyone with a semi-modern computer (i.e. a computer purchased within the last 11 years) to play DaggerXL at good framerates, at least with the basic feature set. In addition the hardware renderer will go through another round of optimizations, as well as general program speed improvements and loading improvements upon start up.

Post comment Comments
ninjadave
ninjadave Apr 5 2011, 1:33am says:

I'd almost like to say it seems like overkill.

This looks like an impressive amount of groundwork. It also looks very CPU centered. I'm not familiar with older games, does the RAM not play as big of a role in the fps outcome?

+1 vote     reply to comment
luciusDXL Author
luciusDXL Apr 5 2011, 3:27am replied:

RAM is important of course, but most systems have more then enough RAM for this case. CPU performance will be more difficult to deal with then RAM usage by far - at least on the majority of systems.

+5 votes   reply to comment
booman
booman Apr 5 2011, 11:29am says:

"Ultimately the goal is 60fps at 1024x768 on a 1 GHz CPU" - This is exactly what I need. My goal is to play DaggerXL on my netbook anywhere and everywhere.
Looking forward to this optimization and a release. Thanks for the hard work... I can tell you are enjoying this.

+1 vote     reply to comment
Lacedaemonius
Lacedaemonius Apr 15 2011, 5:20pm says:

Will we ever beyond 2D sprites?

+1 vote     reply to comment
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

News
Browse
News
Report Abuse
Report article
Related Mods
DaggerXL (Daggerfall)
DaggerXL Daggerfall - Single Player Role Playing
Related Games
Daggerfall
Daggerfall Single Player Role Playing