Refactoring Arx Fatalis: Difference between revisions

From Arx Libertatis Wiki
Jump to navigation Jump to search
(Start discussion about the renderer rewrite)
Line 57: Line 57:
** For OpenGL we may currently technically be able to run with GL 1.5 but really need some extensions to run well
** For OpenGL we may currently technically be able to run with GL 1.5 but really need some extensions to run well
** OpenGL ES support would be really useful
** OpenGL ES support would be really useful
** We could have multiple backends / code paths with different requierements
** We could have multiple backends / code paths with different requirements


* Support for offscreen rendering and postprocessing
* Will we be using forward rendering (used now) or deferred shading
** Transparent objects are in the minority (and often are emissive or don't have normal lighting) while there are many small lights, so deferred shading could be a good option
*** However, we probably need to deal with the lights anyway for the shadows and separate real light sources from those that are used to simulate global illumination


* Support for HDR rendering
* Long-term goals to keep in mind:
** Support for offscreen rendering and post-processing (with depth buffer available)
** Support for HDR rendering
** Supports for real shadows (shadow mapping or shadow volumes?)


=== Roadmap ===
=== Roadmap ===

Revision as of 23:34, 29 January 2013

Subsystems - Discussion regarding the engine initialization and its major components

Scripting

  • Remove / cleanup the script parsing in GetInfosCombineWithIO
  • Parse scripts into some form of IR instead of executing directly.
  • Share loaded scripts between IOs
  • Match timers by name when loading savegames
  • Cleanup GetInfosCombineWithIO()

Savegames

  • Keep the SaveBlock instance open througout the game (and create it at game start to simplify things)
  • Autosave when changing levels - almost all needed information is already saved here
  • Track which IOs changed and don't always save all of them!

Audio

  • Implement environmental effects (reverb) for the OpenAL backend using the EFX OpenAL extension. Reverb is available in the DirectSound backend when EAX is available (Creative drivers only?)

Interface

  • Rewrite that mess.
  • Fix aspect ratio of some interface elements for non-5:4 resolutions.

Renderer

Current state

  • Lighting is done on the CPU
    • Static light components are pre-calculated for static scene meshes
    • Other lighting is done per frame
  • Lighting is per vertex only - there is no support for per-fragment lighting effect (normal maps, ...)
  • Vertex transformation is done on the CPU, except for static scene meshes
    • Animation is done on the CPU
    • OpenGL doesn't directly support the pre-transformed vertex format used, we currently use a small vertex shader for this
    • D3D doesn't clip the pre-transformed vertices - we removed (some of?) the SW frustrum clamping code and this has caused rendering artifacts for some users
  • Vertices are already managed in vertex buffers, there is little of the immediate mode GL API
  • We don't have any shader infrastructure
    • Possibly useful project: shiny
  • Vertex colors are stored as the D3D-friendly BRGA format - OpenGL needs the ARB_vertex_array_bgra extension for this.
  • We have no infrastructure for post-processing effects
    • This could remove the need for he normal rendering code to know about some spell effects
    • This could be useful to reimplement brightness/contrast/gamma, at least in windowed mode or when not otherwise supported.

Goals

  • What OpenGL / Direct3D versions do we want to target?
    • Under Linux we should support the open-source Mesa drivers, but for what chipsets
    • For D3D we already use D3D9
    • For OpenGL we may currently technically be able to run with GL 1.5 but really need some extensions to run well
    • OpenGL ES support would be really useful
    • We could have multiple backends / code paths with different requirements
  • Will we be using forward rendering (used now) or deferred shading
    • Transparent objects are in the minority (and often are emissive or don't have normal lighting) while there are many small lights, so deferred shading could be a good option
      • However, we probably need to deal with the lights anyway for the shadows and separate real light sources from those that are used to simulate global illumination
  • Long-term goals to keep in mind:
    • Support for offscreen rendering and post-processing (with depth buffer available)
    • Support for HDR rendering
    • Supports for real shadows (shadow mapping or shadow volumes?)

Roadmap

  • TODO