Regenerate Your Project for better Debug / Release settings in both Lazarus and Delphi (and to be prepared for secret features coming next week)

News
1
Regenerate Your Project

The summary of this post is: Download latest engine and use “Code -> Regenerate Project” menu item in the editor. It will regenerate the files inside your project (DPR, LPI, DPROJ, and CastleAutoGenerated.pas unit).

We’ve made a few improvements to them, and all together it means we strongly advise you to regenerate your project. The improvements are outlined below, though their real “big outcome” is to unlock 2 new features I will announce in further news posts 🙂

Notes:

  • As always, using the “Code -> Regenerate Project” is not strictly required by us.

    Just recommended, esp. if you develop a regular game following our “New Project” templates, and most examples, as seen in cross-platform manual. In such case, we advise you let us auto-generate your project files (as above: DPR, LPI, DPROJ, and CastleAutoGenerated.pas unit) and you only focus on putting code in units (like gameinitialize.pas, views, and of course as many additional units as you need).

    But if you develop something non-standard (like a Lazarus LCL or Delphi VCL / FMX application using TCastleControl) then you may prefer to manage the project yourself, manually. That’s cool too, engine will work perfectly, you will just have to activate some features explicitly, like starting logging (by InitializeLog) or debug features (by ApplicationProperties.InitializeDebug).

  • Note that you can also do this from command-line: run castle-engine generate-program.

  • As always for development, we recommend you have a backup, actually use a version control (like GIT, backed by a server like GitHub or GitLab) and check the differences caused by the regeneration. If you’re not using version control yet, you really should start :), there are lots of self-hosted and “cloud”-hosted options, also free, even for private (not public) projects.

After this long introduction, the things we improved:

  1. Newly generated Lazarus (LPI) projects include Debug / Release build modes, that set common optimization/debug flags and define DEBUG / RELEASE symbols.

    This is consistent with what our build tool has been doing since ~always and how we configure Delphi projects.

  2. The CastleAutoGenerated unit now calls ApplicationProperties.InitializeDebug or ApplicationProperties.InitializeRelease depending on the DEBUG define when compiling the project.

    This means we can do some stuff (like enabling inspector on F8 key, or file monitor — see future news!) regardless of whether the engine units were compiled with the DEBUG symbol or not.

    The idea is that the DEBUG symbol definition when compiling your project should matter, and the DEBUG symbol definition when compiling the engine should be something independent.

    Why? This allows to have pre-compiled engine, and the same engine (so, release) available for both debug and release projects. Right now compilation from our build tool actually compiles the engine and your project in the same mode (both are debug or both are release), and our advised Delphi compilation does the same. But it’s not going to be like this always. Compilation from Lazarus IDE using packages is already different: engine Lazarus packages are compiled with options independent from your project. Future Delphi integration may also mean you use engine units compiled once, from all projects.

    So we are getting ready for this, by “cleaning up” our debug/release relations between project and engine.

  3. We fixed mixed-up Debug and Release settings in auto-generated Delphi (DPROJ) files.

    By a mistake, since a few months, the DPROJ files we have auto-generated had DEBUG and RELEASE options mixed up.

    That is, when you selected “Debug” from Delphi, we actually made a release build (with optimizations and with RELEASE compilation symbol). Conversely, when you selected “Release”, we actually made a debug build (without optimizations and with DEBUG compilation symbol defined). I know, silly bug, we just caught it. Sorry — but at least you can fix it with literally one click, just regenerate project.

    This is connected to the inspector (invoked by F8): It means that our debug build didn’t react to F8, while release builds did… Fixed now. Inspector (F8) is active in debug builds now.

As usual for a long post without clear thing to screenshot, I just show something pretty 🙂 The screnshot comes from Cyberpunk City (old project) by carlcapu9 licensed under CC-BY-4.0.

1 Like