January news: Ticoban, editor dragging, CastleGL based on dglOpenGL, tester improvements, Pascal custom RTTI attributes, more

Posted on

fps_game demo

Hi all! Our news have been quiet lately, let me fix this by a big list of recent developments 🙂

The list below is not really complete, we have some big thing (for Delphi people) already merged to CGE, but we’ll wait with announcing it until Delphi GetIt servers are fully back online. And we have another big thing (for VS Code people) almost finished. Stay patient 🙂

Onward with what we have to announce today:

  1. Ticoban, a 3D Sokoban version made using Castle Game Engine, is available now for free. Go check it out! By Rafael Campos.

  2. Editor now allows to drag multiple components in the hierarchy so you can more easily rearrange your components.

  3. Throughout CGE, we now use CastleGL unit to access the OpenGL API.

    This is a minimal fork of dglOpenGL, originally done by Sascha Willems and Delphi OpenGL Community (DGL). Our fork makes it compatible with all CGE compilers and platforms by using our CastleDynLib unit under the hood. E.g. it adds Delphi/Linux compatibility.

    We use it in CGE for all compilers (FPC and Delphi) and all platforms using desktop OpenGL (Linux, FreeBSD, macOS, Windows, …).

    This makes things simpler — so we just have 2 units, and both are in CGE: CastleGL (desktop OpenGL) and CastleGLES (OpenGLES). So code can just do {$ifdef OpenGLES} CastleGLES, {$else} CastleGL, {$endif}.

    And dglOpenGL is much better base than built-in things in FPC or Delphi.

    • FPC has GL, GLExt, but their extension querying was not useful with modern OpenGL (was using deprecated, and removed in core, glGetString(GL_EXTENSIONS) instead of glGetStringi(GL_EXTENSIONS, i)).

    • Delphi has OpenGL, OpenGLExt units but only for Windows.

    • They both miss some things, e.g. WGL routines to initialize modern context on Windows.

    We have been able to simplify some CGE code, esp. around WGL or dealing with GLExt issues, thanks to migrating to dglOpenGL. You can read more about my thoughts in #334.

  4. We’ve made a few CGE tester improvements and simplifications:

    • --no-window-create command-line option.

      Removed NO_WINDOW_SYSTEM define, no more IsConsoleMode check. The new --no-window-create option is better both for usage and development.

    • –filter command-line option, for both GUI and console testing, to filter tests by a wildcard.

    • Reliable reporting of both unhnandled exceptions and assertions’ failures, on both GUI and console.

    • Removed old FPCUnit-specific code. It was confusing now, without much benefit. We have completely own testing framework, though still heavily inspired by FPCUnit.

    • Cleaner compilation output (ignore deprecation warnings — tests knowingly use deprecated things, to test that deprecated stuff also works).

  5. There have been some internal refactors to make relevant code easier:

  6. TCastleContainer has now TCastleContainer.PixelsWidth / TCastleContainer.PixelsHeight and Width / Height are deprecated.

    Goal: to make it more clear that PixelsWidth / PixelsHeight are the actual size of the container. The existing Width / Height was a bit confusing.

    We have TCastleContainer.UnscaledWidth / TCastleContainer.UnscaledHeight to get the size of the container when you think with UI scaling. They should be renamed to Width / Height in the future, so they’ll get new more intuitive meaning.

  7. Now that Extended RTTI has been merged in FPC, we look with renewed interest at using some newer RTTI features in CGE.

    In particular, we have experimented some time ago with some ideas how we could use Pascal custom RTTI attributes. If both FPC and Delphi will have equal implementation, we really benefit a lot, we could add simpler API for publishing vectors, exposing test methods, exposing methods to be available as editor actions, etc.

Start the discussion at Castle Game Engine Forum