A rare bug (and therefore absolutely non-critical) with ShadowMaps. At some angles a few distant objects might become visible through invisible ones. This only happens at near-screen-edge angles (never in front) and extremely rarely.

P.S. This might be bug with my specific videocard (Radeon 5400) as seldomly it shows different bugs in different games. So I'll test it deeper when I completely switch to ShadowMaps.

While having "truly 64 bits" accuracy, our random64 function can return only high(LongWord) variants of 64-bit integer. This is caused by initializing the 64-bit seed by two sequential 32-bit seeds. However, knowing the first 32-bit seed we can always calculate the next one, they are not independent.
E.g. compare this to SysUtils.random(int64). As they have variable-cycling algorithm which is slower, they still are free from the problem of xorshift algorithm that two sequential seeds are not independent. Yes, they also do not have truly independence, but a higher degree of.
We're using a single-variable pseudorandom generation algorithm, which is while easier and faster, cannot provide for 64 bit diversity based on two non-independent 32 bit randoms.

There are few ways we can fix this:

1. Leave it "as is". There is actually no serious problem at all. The random is truly 64 bits, it just doesn't use all the possible variants of a 64-bit integer. And I can hardly imagine user ever experiencing two identical 64-bit random sequence probability of which is still determined by 32-bit random seed: 1/high(LongWord).
2. Modify the algorithm to use two independent seeds in case of 64 bit integer request. We shall fake 2-variable cycling algorithm for 64 bit randoms then, and also we shall avoid cycling the 32-bit seed twice (which is also no problem, actually).
3. Make a separate implementation of xorshift64 bit, the one I'm using to randomize and turn two 32bit randoms into a 64 bit one.

The easiest way to fix the issue (except not fixing it at all :)) is "3". We can easily get a 64-bit seed from randomize and turn random64 into a separate and semi-independent (but the initial random seed is the same) random algorithm. It will still reproduce the random sequence fine, however calls to random64 won't affect next values of random and vice versa.

https://github.com/castle-engine/castle-engine/tree/master/examples/3d_sound_game seems to use 2 unused (and inexistent) units gamesounds.pas and thunder.pas in Project Inspector (contained in .LPI file).

I've been playing around with safe threaded loading of data and eventually made a special safe-loading wrapping for XML/X3D/Image loading: see https://github.com/eugeneloza/decoherence/blob/master/decoinputoutput.pas#L44
There's still a nasty bug in Debug mode + Linux (see http://forum.lazarus.freepascal.org/index.php/topic,36823.0.html ), but the approach looks altogether useful. Maybe, CGE I/O procedures may be wrapped in Critical Sections as default (tunable with a global compiler directive)?
Even more... maybe the whole render process might be a Critical Section to be able to be released into a thread?

Just saw a very strange bug in Castle wiki at Github: most text is enclosed within h1 tag. I'm not sure if this is the only page affected...

Hi,
Just curious if you're interested in supporting the Delphinus-Packagemanager. It is an alternative Packagemanager for the Delphi-IDE for installing packages/source/components through Githubhosted repositories. You could make the engine available on it(if there are no prebuildbinary dependencies). In addition, each time a new release is marked, people see that an update is available.

https://github.com/Memnarch/Delphinus/wiki
(My Blog)
http://memnarch.bplaced.net/

If you have any questions, don't hesitate to ask me.

I've got a lot of

Warning: (4104) Implicit string type conversion from "AnsiString" to "WideString" (30 times)
Warning: (4105) Implicit string type conversion with potential data loss from "WideString" to "AnsiString" (53 times)

when compiling the Engine in Lazarus. Still no problems ever occurred.
However, when I exported my Decoherence data to XML I've eventually remained without Cyrillic characters due to wrong WideString to AnsiString conversion :)
Making AnsiString := UTF8encode(WideString) and TXMLDocument.CreateTextNode(UTF8decode(AnsiString)) solved the problem correctly (Cyrillic again displaying). Actually the last conversion was redundant - everything worked correctly without it, but, anyway, at least it removed the warning :)
Maybe, it's a correct way to solve the issue (if it needs to be solved)?
It's also possible just to remove the warnings by {$WARN 4105 OFF} and {$WARN 4104 OFF} if it's intended.

I can't seem to change the TCastleWindowCustom children Window.height/width runtime. I can easily set Window.height/ Window.width before Window.Open, but not after. Window.doResize also doesn't work. Window.ResizeAllowed := raOnlyAtOpen also doesn't prevent the user from resizing the Window in case it is assigned after window.open.
However, I can set Window size in Initialization right after creating the window instance and it'll work correctly before the window is open.
P.S. I'm absolutely sure it worked before, e.g. in April-May.
P.P.S. setting fullscreen to "true" normally enters fullscreen mode and resizes the Window.
Simple example attached.
ResizeProblem.tar.gz

During my work on the Debian package for the 6.* version of castle-game, I noticed that (at least) the body-begin.html and body-end.html contain several references to on-line source. Off-line documentation should not automatically load on-line data (links are of course fine). Could you consider changing the off-line documentation to be self contained, i.e. provide the objects needed in the source of castle-engine?

The issue isn't new, until now (version 5.2), I have stripped out the footer.html from the documentation to prevent the piwik code from entering the off-line documentation, but the current documentation is adding lots of more on-line sources.

Side note, in Debian I will patch the documentation to use the system versions of the JavaScript files if that remains in the documentation, I don't expect/need you to solve that.

Related note, I'll for Debian I'll probably need to zip the content of https://github.com/castle-engine/cge-www to properly generate the documentation. Do I need everything, or is the data that I need limited?

http://michalis.ii.uni.wroc.pl/cge-www-preview/x3d_extensions_screen_effects.php
GLSL documentation leads to obsolete page
http://www.opengl.org/documentation/glsl/
Looks like the correct link is
https://www.opengl.org/sdk/docs/man4/index.php
However, they've merged API and GLSL documentation.

Actually random64 returns some (seed64 mod N), therefore it can be both 0 and less than HIGH(DWORD). But seed64 is given by (seed32 shl 32 + seed32) and as seed32 cannot be zero, seed32 shl 32 always returns at least HIGH(DWORD).

I'm getting a "The argument cannot be assigned to" error when trying to change TGenericStructList elements fields. Is this correct? Works fine with object lists... Didn't try it with simple lists (like integer lists).

type TSomeRecord = record
  value: integer;
end;
type TMyList = specialize TGenericStructList<TSomeRecord>;
...
var List: TMyList;
    MyRec: TSomeRecord;
...
List := TMyList.create;
MyRec.value := 0;
List.add(myRec);
List[0].value := 1; //<--------- "Error: The argument cannot be assigned to"

It would be great to have some TiledMap component. It should be compatible with "Tiled Map Editor" file format. Which class should be an ancestor to "TCastleTiledMap"?

There is a bug in the castle-engine/examples/fonts/html_text.lpr
Buttons are in wrong positions. This is possibly caused by TCastleButton that don't recalculate button width when caption has changed.

Hi,I found that if the caption value contain chinese characters in the CastleEngineManifest.xml,after install the game,the caption will be unreadable.It the CastleEngineManifest.xml file(you can modify from the drawing_toy demo)
<?xml version="1.0" encoding="utf-8"?> <project name="drawing_toy" caption="测试" qualified_name="net.sourceforge.castleengine.drawingtoy" standalone_source="drawing_toy_standalone.lpr" game_units="Game"> <package> <include path="README.txt" /> </package> </project>

If I use non ASCII (but UTF8) letter like "ę" in file name (and manifest) then build tool don't recognizes it correctly.
There is: "Fatal: Can't open file ....lpr" error on output.
Pure FPC and Lazarus works OK with those files.

http://castle-engine.sourceforge.net/apidoc/html/CastleGLImages.TGLImage.html
TGLImage contains 4 variants of "create" however, their description seems to mismatch... Maybe I should try to fix the issue?

Do we need to have a shuffle procedure in a TGenericStructList and similar? I'm speaking of http://forum.lazarus.freepascal.org/index.php/topic,34882.msg229682.html#msg229682 . Never needed anything like that myself yet. However, looks like it's a nice feature worth adding and looks like a simple thing to do (maybe, even make helpers for normal generic lists). If "yes" then I'm on it :)

I see a problem if nonzero-angle of background and viewpoint (camera) is equal:
After load of example file, the background gradient looks not complete.
If I rotate the camera interactively (rotations become unequal), painting becomes correct.
test.x3d.txt

in https://github.com/castle-engine/castle-engine/wiki/Android "Test compiling and running android_demo" -> "p.5"

I think it's a good idea to mention that running
adb devices
shows no devices unless USB debugging is "on" on the device (had a lot of trying-and-failing until I've figured out this simple requirement :)).
e.g. "In order to install and run the device from the destop PC you have to enable USB debugging mode on your Android phone/tablet"

While working on an update Debian package for castle-engine the Debian package checker Lintian reported several spelling mistakes.

Please find a patch fixing the issues attached to this bug.

fix-typos-found-by-lintian.patch.txt

Well... I've made the possibility to compress the game data, but eventually I'm not sure which is faster to load, e.g. a 38kb raw file or 8kb compressed file. While providing almost 5x compression, comparing to "huge" size of textures this hardly counts as a significant. Well... Reading 38kb is slower than reading 8kb, so sequential processing of data should look faster overall. However, decompression takes additional CPU resource. This should be "faster or equal" for Desktops, but for low-speed Android ARM CPU I doubt that it will do any good. So... Which looks "faster" in implementation?
If there is no clear answer (and yes, there should actually be none) then I can make a simple speed test for reading-writing gzipped/raw data which can be run both at Desktop and Android.
On the other hand, exploring the compression issues, I've eventually found out that Save3D and Load3D automatically detect compression based on URL/MimeType (guessed from extension). Maybe, it's better to reimplement the URLWriteXML/URLReadXML (meaning f05778e and 2377d1b) compression in the same way? WDYT? If yes, then I'm on it :)
P.S. CastleURIUtils lacks ".gz" for archives. Maybe it's a good idea to extend it? Should raw ".gz" extension count as gzipped?

Hmm... something as simple as comparing two TVector3 is not working... Maybe, I'm missing something?
Using MyVector1.Equals(MyVector1,MyVector2) doesn't look nice to me...

I've ran into a strange Application.OnTimer bug on Windows7x64 + Lazarus 32 bit 1.6.0, FPC 3.0.0. It skips some timer events (approx. 1 of 30) if there is a font output Window.OnRender - this bug is not caught in OpenGL graphics output.
This happens only when run inside Lazarus. The compiled program doesn't make any skips. In Linux everything works fine also both standalone and inside Lazarus.
Maybe something in my system conflicts with Application timer? The suspect is GDB vs ZoneAlarm firewall, there is a known issue between GDB and Comodo firewall, maybe it has some softer manifestation here.
The most simple program I could reproduce the bug is:
AppTimerBug.tar.gz
Could anybody test it on another windows system? It should report something like "312ms" in dos-window, but 550 and higher shouldn't happen (I've experienced up to 1678ms versus demanded 300ms).

I've thought of implementing something similar to TTimer in LCL, looks relatively simple, we can even just include CustomTimer.pas from LCL without dragging the whole library. What do you think?

1. Castle Game Engine + Lazarus + QT5... is it supported?
2. Implementation of PBR materials available?

In a very simple code:

  Img := LoadImage('1.png', [TRGBAlphaImage]) as TRGBAlphaImage;
  SaveImage(img,'1a.png');

the simple Load-Save fails to keep "alpha channel". Yes, there is a "hidden" alpha=0 RGB-image at 1.png... but it should remain alpha=0.
I.e. SaveImage treats only (0,0,0,0) as transparent, but not (value,value,value,0).
See the attachment with test-case.
It fails at images "1.png" and "5.png", while absolutely identical images (made just by rotating '1.png' - they also contain the 'hidden' part) work fine. Image 1.png contains a "hidden alpha=0" sub-image, which I've tried to remove with GIMP -> 5.png. Eraser brush didn't remove the hidden image, so I've over-painted it with black color (0,0,0,255) and then erased it (0,0,0,0). Eventually SaveImage interprets non-transparent black color (0,0,0,alpha<>0) as transparent...
There are some other artefacts relative to this issue (harder to reproduce, but "appearing" at DrawFrom when buggy alpha channel is interpreted in a wrong way after saving)...
P.S. I'm not exactly sure if it's SaveImage the one which fails. However, saving an image with "buggy" alpha channel (e.g. by DrawFrom) depends on what else is present at this image. E.g. mixing one buggy image with a normal one produces a normal result. Sometimes, copying and saving a part from a "normal image" yields a buggy result.
It might be the problem of accidentally using AlphaDecide based on top-left pixel of the image (the symptoms witness about that)? When, e.g. by some accident HasAlpha is not set properly?
LoadSaveImageError.tar.gz

I've got a warning on compiling CastleRandom unit:

...castle-engine/src/base/castlerandom.pas(170,12) Warning: (5066) Symbol "GetTickCount64" is deprecated: "to measure time, better use Timer + TimerSeconds or ProcessTimer + ProcessTimerSeconds"

Actually GetTickCount64 is a good method to get a "very" accurate amount of CPU ticks (we need it to initialize random as fine as possible and getticksount is the best candidate). However, if you intend to remove GetTickCount64 from CGE, maybe, I should change it to freepascal's GetTickCount (AFAIR they also have a 64 bit version, which we, actually would rarely need - if I recall it correctly, it'll take around 3000 days (more than 8 years) of up-time to overflow a 32-bit gettickcount :)). Or, maybe move the GetTickCount64 function to CastleRandom unit if it's the only unit using it? I remember you've written about problems with getting time on Android devices.
Or, maybe just wrap it inside {$Warn 5066 OFF} if its intended?

Yesterday I've encountered a minor random seed initialization problem.
It was 0:00-0:05 o'clock and random was initialized with very "small" seed unexpectedly yielding very small values.
I'll see what I can do with it. Maybe I should use /dev/random in Linux and copy FPC initialization procedure in Windows to seed the algorithm.

Hi, Michalis!
I've encountered a wierd problem.
Yesterday this code was working absolutely flawlessly:

TextureProperties.KeepExisting := 1;
...
(something).FdTextureProperties.Value := TextureProperties;
...
FreeAndNil(something);
...
FreeAndNil(TextureProperties);

But today I get a SIGSEGV at FreeAndNil(TextureProperties) as if it doesn't KeepExisting (the same problem I fixed for good by KeepExisting)... why? I'm sure I've fixed this issue yesterday and everything was working flawlessly afair. I don't see you've addressed any freeing operations checks in last commits (I've updated CGE to latest GIT since my last PULL request)...

fpcupdeluxe requires svn (subversion package in Debian Linux) installed otherwise it won't work with some explanatory but hard-to-read due to poor color scheme error message :) I think it's worth mentioning at https://github.com/castle-engine/castle-engine/wiki/fpcupdeluxe

Hi, Michalis!
I'm again experiencing problems with Cyrillic UTF8 encoding/decoding :) That's gonna be a habit :)
Namely speaking: TDOMElementHelper.TextData
In Linux (Lazarus 1.6.2 FPC 3.0.0) getting ValueNode.TextData works fine.
But in Windows (Lazarus 1.6.4 FPC 3.0.2) it returns a mess unless I do UTF8encode(ValueNode.TextData).
While specifying UTF8encode in Linux returns a mess :)
I don't see any platform-specific stuff in TDOMElementHelper.TextData and it already internally uses UTF8encode to convert the result to AnsiString as UTF8Encode((Node as TDOMText).Data).

@eugeneloza , this may interest you, since I know that you use castle-anim-frames and CGE from GitHub :)

In the commit e240cc9 , I knowingly made a change that may significantly increase the loading time (and memory consumption) of castle-anim-frames. In short, the "equality_epsilon" used by castle-anim-frames (see https://castle-engine.sourceforge.io/castle_animation_frames.php ) is temporarily ignored.

I will fix it in 2-3 days, you can watch this issue :) During that time, please

• either use earlier engine versions, before e240cc9 ,
• or don't look too closely at the loading times of castle-anim-frames :)

Sorry for the mess, it's only temporary :)

I've made a patch to support dmAlphaBlend, however, I couldn't figure out how to push it to github... Still to new to all those forks and etc... I see that the file structure has been changed on 10th October, but my fork I've downloaded yesterday had different file structure... Maybe this feature was already implemented and I have to update my branch somehow?
Well... here's the patch:
castleimages.pas.zip
AlphaBlendTest.zip
I've used https://en.wikipedia.org/wiki/Alpha_compositing formula for alpha-blending. And it works only for Vector4byte type pixels.

Maybe, that's because I have "scrot" assigned to K_PrintScreen in XFCE key bindings? Needs checking.
I've seen this behaviour only in windowed mode. Didn't check it fullscreen.

If it's true then some comment near the definition might come in handy.

Now that we officially have tsr8's tiledmap loader in the engine code, I am planning on writing a tiledmap loader for X3D in the same way as how the engine handles non-X3D formats like 3DS or Spine. The problem is I also want to retain TTiledMap instance so that I can get informations that can't be translated directly to X3D nodes like the Object layer. So I am thinking of modifying TCastleSceneCore and add 2 new properties:

• RetainLoaderInstance: A boolean field that tells the engine to keep loader instance after loading process is done, default is false.
• LoaderInstance: A TObject field that holds loader instance.

Of course we also need to modify all existing x3dloadinternal*.pas code to follow this changes.

What do you think Michalis?

As usually I've invented a bycicle and made up a joystick example :) Afterwards I saw that there is already an example available in "examples". I haven't tried it yet. I'll check it and maybe it'd be a good idea to merge them?
JoyTest.tar.gz

Well, my old, cheap and reliable all-purpose A4Tech OP-35D optical mouse finally died. I've decided to by a A4Tech x750 laser mouse. It works and feels a bit more comfortable (not mentioning that it's 5 times more expensive), and there are no problem on Linux.
However, on Win7 I've experienced a strange behavior in Caste Game Engine (Decohrence).
There is a DPI switch button on the mouse (I really needed it (sarcasm)), and it has several switchable modes from 100 DPI to 3600 DPI.
OP-35D worked "fine" both in games and in Windows software. But, x750 on "average DPI" settings is too fast in Windows software and too slow in Decoherence window with MouseLook = true (and TES: Oblivion / fullscreen too, so it's not just CGE :) I haven't tried it anywhere else yet).
This isn't a critical problem, of course. However, maybe there is a way to "understand" and "take into account" mouse DPI (it should be reported by a driver)?

Eventually I've bought a cheap gamepad for myself :)
After a few minor fixes (see eugeneloza@adb4ec3 ) I've managed to make my gamepad work on Linux smoothly.
But It works not as expected on Windows.
I couldn't solve the puzzle of Up/Down/Pressed state, the implementation is much more complex in Windows and therefore I don't really understand where it fails...
I've managed fix onAxisMove event spamming, but POV axes don't trigger onAxisMove events, moreover they provide incorrect data for my gamepad (UP=UP, LEFT=UP, RIGHT=RIGHT, DOWN=DOWNLEFT) while everything is correct in Linux and in native gamepad test software.
@tsr8 I believe you are much more experienced in gamepads than me... if you could give me a hand here I'd be very grateful.

@michaliskambi Is it possible to implement "TCastleWindow.gamepadlook" similar to "TCastleWindow.mouselook"? Where should I start digging? It's a theoretical question for now as I'm buisy with my game interface at the moment, so don't take it too seriously, just a hint or reference to the procedure will be absolutely enough for me to understand whether I am capable of doing that... :)
Maybe it's a good idea to make gamepad events linked to TCastleWindow.OnMotion? E.g. integrate it in TInputPressReleaseType = (itKey, itMouseButton, itMouseWheel, itJoystickAxis, itJoystickButton); I see that TCameraInputListener and TUIContainer already have some joystick support.

P.S. When I make changes to castlejoysticks.pas it doesn't compile together with my program and I have to compile castle_base manually. Strange, because castleimages works like a charm here even while editing "inc" files. Maybe, there's something wrong with package settings for castlejoysticks.pas unit so its change doesn't call to re-compile the castle_base automatically?
It's not listed in castle_base.lpk but is used in CastleUIControls.

Hi,

first of all, this is an awesone engine!

For the moment i have a problem when loading a level with X3D models which contain sounds, e.g.:

PROTO Door [ ] {
  Group {
    children [
      DEF TimerOpen TimeSensor { 
        cycleInterval 0.5
      }
      DEF TimerClose TimeSensor { 
        cycleInterval 0.5
      }

      DEF DoorNode Inline { 
        url "door_final.x3d" 
      }

      Sound {
        intensity 0.5
        source DEF DoorOpenSound AudioClip {
          url "../sounds/door_open.wav"
        }
      }
      Sound {
        intensity 0.5
        source DEF DoorCloseSound AudioClip {
          url "../sounds/door_close.wav"
        }
      }
# Stuff...      

The problem is, when it loads the X3D model it calls TRepoSoundEngine.LoadSoundsBuffers which initialized the progress bar. But this progress bar is already active when loading a level. This means it raises an Exception.

To avoid this i don't call the progress bar in TRepoSoundEngine.LoadSoundsBuffers at all when its active:

procedure TRepoSoundEngine.LoadSoundsBuffers;
var
  ST: TSoundType;
  ProgressActive: boolean;
begin
  { load sound buffers and allocate sound for music. Only if we have any sound
    (other than stNone). }
  if ALActive and (Sounds.Count > 1) then
  begin
    ProgressActive := Progress.Active;
    if not ProgressActive then
      Progress.Init(Sounds.Count - 1, 'Loading sounds');
    try
      { We do progress to "Sounds.Count - 1" because we start
        iterating from ST = 1 because ST = 0 = stNone never exists. }
      Assert(Sounds[stNone].URL = '');
      for ST := 1 to Sounds.Count - 1 do
      begin
        if Sounds[ST].URL <> '' then
        try
          Sounds[ST].FBuffer := LoadBuffer(Sounds[ST].URL);
        except
          on E: Exception do
          begin
            Sounds[ST].FBuffer := 0;
            WritelnWarning('Sound', Format('Sound file "%s" cannot be loaded: %s',
              [Sounds[ST].URL, E.Message]));
          end;
        end;
        if not ProgressActive then
          Progress.Step;
      end;
    finally
      if not ProgressActive then
        Progress.Fini;
    end;

    MusicPlayer.AllocateSource;
  end;
end;

I've thought it might be a good idea to include Castle Game Engine version in log similar to {$I %FPCVERSION%}.
However, it doesn't seem to be "as easy" in Git version (where this information would be most useful).
{$I %DATE%} + {$I %TIME%} Will provide date and time of the last compillation, but not of the date of "latest commit to master branch"
Anyway, it's not that important to make any complex solution. E.g. static constant like "5.2.0", "6.0.0" or "Git version no earlier than 1.11.2016" (e.g. the latest date you've remembered to change it :)) automatically inserted at log start will be enough.
Maybe, adding FPC information to log initialization, such as {$I %FPCTARGETCPU%}; {$I %FPCTARGETOS%}; {$I %FPCVERSION%}; might also be useful?

Every time I compile a project, the Generic.Collection units keep recompiling over and over again. E.g.:
GenericRecompiled.txt

Build tool and whole castle engine building should utilize multi-core CPUs.

There is "--threads=value" option in fpmake but it doesn’t work for now.

I found a clue that --threads option works if there are many packages to compile. We have only one.

Michalis, hi!
Posting the test-case for the issue discussed at Discord. When a Model is inserted/removed from different SceneManagers the shaders keep recompiling every frame in case Model.Attributes.WireframeEffect := weSilhouette;.
It doesn't happen if the Model is just removed and added to Window.SceneManager, only if it is added to some other SceneManager in between.

ShadersKeepRecompiling.tar.gz

P.S. As I've said before, this issue is not urgent :)

https://github.com/castle-engine/castle-engine/wiki/Build%20Tool#create-manifest

  <package>
    <include path="documentation/*" recursive="True" />
    <include path="README.txt" />
    <include path="COPYING.GPL2.txt" />
    <exclude path="*.xcf" />
    <exclude path="data/internal/*" />
  <package>

Last one should be a closing tag:

  <package>
...
  </package>

Maybe it'd be a good idea not to use special (logical operations or system) characters like "|", ":", "/", "*", ">", etc. in web pages titles? E.g.

"Sound | Tutorial | Castle Game Engine.html"

It saves perfectly in Linux (thanks to UTF8), but then the saved file can't be acessed (renamed/deleted/opened) in Windows :) Firefox automatically replaces these characters, but only if save procedure was made in Windows. On Linux it doesn't replace anything.
Maybe something like

"Sound - Tutorial - Castle Game Engine.html"

might be better?

By default mouselook:=true hides the cursor (which is right), but if there is a transparent TCastleImage crossing the center of the viewport, then the cursor becomes visible.
(not really important, just to keep track of that issue)

While playing with string conversions I've found that
../src/x3d/x3d_node_helpers.inc
../src/ui/opengl/castlecontrols_tiledmap.inc
are missing in both CGE versions I have at my home PC. Everything compiles fine, so I think they just have been merged/renamed to other units and these links accidentally remained.
See screenshots attached.

Again two typos found. Please find a patch attached.

Maybe also grep and/or sed on the whole source tree to find/replace successfull (but not successfully). Idem for the typos in issue #53: occured, succeded and charater. They were not fixed in that issue because they didn't show up in the binaries.

fix-typos-found-by-lintian.patch.txt

Hi, Michalis!
At this time we have LogStream: TStream; which suggests we have only one log stream (e.g. either a file or a console in desktop applications).
But, actually, maybe its possible to have two simultaneous streams (both to file and console)? I'm not sure if this is "needed", my way of thinking is the following:
I usually need just console output to see it real-time.
However, I've several times got my X11 completely hung up by the game (the threads problem I've described earlier) and therefore it's hard to tell at which phase it fails. So a parallel log-file which I'll be able to see after rebooting might be a good hint on where to seek the error.
I'm not sure if log-file will represent the "current" state of the log if the app fails as badly as OS becomes unresponsive :) Neither I am sure it'll be helpful. But anyway, writing log both to a file and to console might come in handy.
What do you think?
If yes, I'll assign this to myself :) Looks like the task I can handle (Yes, I already have a bunch of "started but not finished" things to do, shame on me).
The idea is "if assigned(logstream2)" then add another few writeln procedures (as copy of logstream-related). And an additional ("add secondary log stream") routine to initialize/release logstream2 properly.
However, it'll be a minor efficiency drop for logging. Maybe, not worth it?

I think when there are alternative texture sources defined in ImageTexture, engine should not show the warning when 1st option fails.

Try downloading following and opening in view3dscene
http://www.web3d.org/x3d/content/ConformanceNist/Appearance/ImageTexture/Extrusion.x3d