Refactoring Arx Fatalis

From Arx Libertatis Wiki
Jump to navigation Jump to search

Subsystems - Discussion regarding the engine initialization and its major components


  • Parse scripts into some form of IR instead of executing directly.
  • Share loaded scripts between IOs
  • Match timers by name when loading 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!


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


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


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
  • 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
  • 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.


  • Hardware transform & lighting
  • What OpenGL versions do we want to target?
    • Under Linux we should support the open-source Mesa drivers, but for what chipsets
    • 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
  • 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
  • We want to upgrade the visuals while also staying true to the original game atmosphere
    • Some effects that could be nice
      • Parallax bump mapping, Legend of Grimrock style :)
      • Improved fog
      • Nicer water
      • Have actual text rendered on in-game notices/signs (just so we have an excuse to implement distance field text rendering)
  • Long-term goals to keep in mind:
    • Support for offscreen rendering and post-processing (with depth buffer available)
    • Supports for real shadows (shadow mapping or shadow volumes?)
    • Support for HDR rendering
    • Support for stereographic rendering
      • This means separating updating (physics, animations, ...) and rendering, which is a good idea anyway!

Also see the List of Milestones.


  1. Separate game logic and rendering code
  2. TODO


Mostly sane by now:

  • Minor issues still exits
  • e.g. in the animation system
    • look of uses of 'ofRaw' outside TimeTypes.h

Arx has three different concepts of time:

Timer Pause Slowdown Current impl Notes
Interface ARXTimeMenu no abs value needed
Game delta_time_us (abs) / framedelay (frame) abs value stored in save games
Player Original_framedelay frame time only, no abs value

Interface time is only used to animate the GUI - it should not respect any game state such as pause or slowdown.

Game time is the in-game time (duh!). It is used for in game animations, NPC movements, etc. The speed can be affected by spells such as Slow time (Rhaa Rune (decrease)Tempus Rune (time)) and it can be stopped completely (when the menu is open).

Player time is the same as game time, but without any slowdown by spells. This is needeed so that player movement and attacks are not affected by the Slow time spell. Maybe this is best implemented by applying a player speedup on top of the game time though?