I am back to wanting to figure out why my tiled terrain broke when you made the change that I requested when you changed the meaning of the counts. I have been working on other things so just limited it to loading one tile where the problem was avoided.
I think it would be easier if the debugging information was on and I could step into the cge code. When I do full clean and build with the debug settings and it builds all the cge code with my project, I still cannot step into cge code, and if my code is called from cge code via callback the stack is unavailable.
How can I enable debugging into cge in lazarus?
I asked google, and its ‘AI’ overview were idiotic wrong LLM garbage. The top results were also poor and clearly where the LLM built its word soup from. I swear the world is going backwards, except for CGE!
Hm, nothing special should be necessary to debug code using CGE. You should be able to “step into” CGE code from your application.
Debugging works in both Lazarus debugger, and Delphi debugger, and VS Code (various debugger backends, we tested fpDebug and GDB). I see you use Lazarus – our castle_base.lpk has “Generate Info for debugger” out-of-the-box.
I just tested it using FPC 3.2.2, Lazarus 3.4, on Linux/x86_64, using our examples/eye_of_beholder. I set a breakpoint at LabelFps.Caption := 'FPS: ' + Container.Fps.ToString line , and when it occured, pressing F7 steps into CGE code – I can debug TCastleView.Container implementation etc.
Can you perform the above test, to make sure it works the same on your system, with eye_of_beholder?
If this also fails for you, then we’ll debug, please let me know the OS and FPC version you use. I’ll see can I reproduce the problem
I loaded eye_of_behold, set breakpoint on that line (#142 in mine). Run, [Play], it stops at the breakpoint, F7 and debugger goes straight to next line #147.
I am on Win10, FPC 3.2.2 and CGE from a week or so ago.
Woah! Like magic the problem is gone! I set it back to loading and building 9 tiles which I haven’t been able to do since that change, but haven’t tested recently. And now it works. So I haven’t been able to load multiple tiles and build a large world since you made many changes to improve shadow performance and probably other performance improvements.
It is much faster framerate in debug mode than it was before july. Thanks so much for that!!
So I don’t need to debug into cge now… but really it would be so handy for understanding things so would be good to figure out.
But at least I am back on track to wherever I am going.
I tested now the same thing on Windows, and it works OK for me, just like it did on Linux. That is, F7 steps into the CGE source code.
I’m using Lazarus 3.4, also FPC 3.2.2 (on both Windows and Linux), the test was done on unmodified CGE from master branch (we didn’t make any changes to CGE compilation configuration lately that could affect this).
So, I’m a bit stumbled on why it doesn’t work for you, esp. as you also tried on eye_of_beholder from unmodified CGE – so all project and packages settings are equal.
My next suspicion are some non-standard settings in Lazarus. Can you retry your test with clean Lazarus configuration? How to do this:
You can run your existing Lazarus with --primary-config-path command-line option. E.g.
cd c:/lazarus
lazarus.exe --primary-config-path=c:/tmp
Alternative, maybe safer and will also help with 2nd recommendation: install new FPC/Lazarus combination using fpcupdeluxe. This installs separate Lazarus, that (when run by new icon on desktop) will use a separate config, unrelated to your old Lazarus. Remember to associate CGE packages with new Lazarus (in CGE editor preferences, set path to new Lazarus and there “Register Lazarus Packages”). After you’ve done, you can delete that FPC/Lazarus installation if you wish (remember to change CGE settings again to use older Lazarus), it doesn’t change your system installation in any way.
Another idea: in case you have some older Lazarus (you didn’t mention Lazarus version above, this is unrelated to FPC version), try to use other version. The latest is 3.6, so I recommend this (I did my tests on 3.4, though 3.6 should work as well).
Your recording is same as what I do except F7 steps over because it would seem there is no debugging info on the cge compiled code even though it built with everything else.
I am also using Lazarus 3.4. I have had cge for a long time… perhaps I installed it initially in some way as a package or something that would have separate compiler settings that I am still getting somehow even years later? I have never been able to step into cge code.
I didn’t know there was a new Lazarus, (that is exciting, they are going fast) but I have always had a lazarus relatively concurrent with cge so I don’t think that is my debug issue.
Do you have compiler variables that control any aspect of how cge builds that would be separate from the whole project? It is building the cge code when I build my project because it will stop on syntax error so why would it behave as if it had different compiler settings than the project?
When you build using Lazarus, the CGE code (in castle_xxx.lpk packages) is compiled using options in that package, independently of your project (well, to some extent – some options, like memory-leak detection, are only set on the project and they affect everything, i.e. memory leaks are always checked for the whole project including all packages).
So, we both use the same options, just because we use unmodified castle_base.lpk, the project options should not even matter. (or their “Debug” / “Release” mode). The package options should have this:
So, it’s weird that it doesn’t work for you. Unless some user-specific Lazarus setting affects this. Try my advises to test with separate, “clean” Lazarus settings. Lazarus version 3.4 should indeed be OK – it is what I used for my tests too.
