Linux OS - No building on 'Campaign'

[Mira-Chronos]

When i try to play at Campaign mode, there is no building, i have only units. But I must have 1000 credits to win...

My first view in mission:

I can kill ennemis

Here the log.txt log.txt

[stefanhendriks]

@pbomta the seed map generator seems to be broken. (hence it won't create a constyard, etc)

[pbomta]

Hmm, with what's currently in master, this works fine on Windows. Maybe it's a 64-bit problem? Allegro doesn't build on 64-bit MinGW on Windows, so we can't test that on Windows.

[pbomta]

@Akatsuki57 , could you check out this branch and compile it for your platform? https://github.com/stefanhendriks/Dune-II---The-Maker/compare/fix/458-no-rock-in-campaign I suspect that the static asserts will fail.

If they do, we found a 64-bit problem. We'll have to replace the types with int64_t and int32_t respectively, to have them the same on all platforms. But I'd like to add a unittest for the seedmap generator first.

@stefanhendriks , about unittesting: shall we use Catch2? Easy header-only lib. Quite popular (and rightfully so, I have used it). It's the second most popular one (after Google Test). See: https://www.jetbrains.com/lp/devecosystem-2020/cpp/ Google Test is harder to integrate, IIRC.

[Mira-Chronos]

You are quite right Assert fail

[stefanhendriks]

@stefanhendriks , about unittesting: shall we use Catch2? Easy header-only lib. Quite popular (and rightfully so, I have used it). It's the second most popular one (after Google Test). See: https://www.jetbrains.com/lp/devecosystem-2020/cpp/ Google Test is harder to integrate, IIRC.

Yes lets do some unit testing. I am open to anything here, as I don't have experience with Unit Testing and C++. So I'll just go with your experience. If you can set something up?

[stefanhendriks]

The seedMapGenerator was reverse-engineered (not by me). I checked out Open Dune's implementation but that seems to be very specific about what kind of int's its using (see https://github.com/OpenDUNE/OpenDUNE/blob/master/src/map.c#L1441).

[stefanhendriks]

About the static_assert. How does that work? It looks like it failed the build? So how was it possible to get this issue in the first place? Something with compiler flags?

[Mira-Chronos]

I replace unsigned long seed; by uint32_t seed; The assert get now okay, but the bug is still there.

[pbomta]

About the static_assert. How does that work? It looks like it failed the build? So how was it possible to get this issue in the first place? Something with compiler flags?

Width of types. Especially long. It can differ in bit width between platforms and 32 and 64 bit width. So it passes on our 32-bit MinGW setup, but not on 64-bit Linux.

[pbomta]

I replace unsigned long seed; by uint32_t seed; The assert get now okay, but the bug is still there.

Thanks for trying it out. But that's probably not the problem, then...

[stefanhendriks]

About the static_assert. How does that work? It looks like it failed the build? So how was it possible to get this issue in the first place? Something with compiler flags?

Width of types. Especially long. It can differ in bit width between platforms and 32 and 64 bit width. So it passes on our 32-bit MinGW setup, but not on 64-bit Linux.

What I meant was, if it fails the build. How come this issue was possible to create (it should succeed the build then). But anyhow, doesn't matter :) Fact remains something needs to be fixed here.

I see in the Open Dune code all kinds of references to an int_16 or something. (which makes sense, Dune 2 was made for 80286 I believe)

[Mira-Chronos]

can someone launch the game under windows in debug mode, select the first mission of the Harkonnens for example and quit. (do nothing else, not move units or build a building) Then upload the log file so that I can look in detail at what changes in order to be able to solve this bug which handicaps the linux version?

[cm8]

please see https://github.com/stefanhendriks/Dune-II---The-Maker/issues/577#issuecomment-1849258824 for a fix

Maybe this ticket can be merged with #577 or one of them closed as they seem to track the same issue..

---

For a 32bit compile -O3 optimization is too agressive for the ini file reading code (d2tm aborts), but -O2 works ok. However, on amd64 this does not seem to apply (d2tm does ok with -O3 compiler option). In case anyone is interested in compiling d2tm as a 32bit executable on a 64bit machine, try

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 557a265e..4770a1e3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -86,6 +86,12 @@ if (UNIX)
       alfont
       fmt::fmt
   )
+  #builds 32-bit binaries, needs 32bit liballeg.so to link to
+  set_target_properties(${PROJECT_NAME} PROPERTIES LINK_FLAGS "-L/usr/lib/i386-linux-gnu/")
+  add_definitions( -m32)
+  set(CMAKE_EXE_LINKER_FLAGS         "${CMAKE_EXE_LINKER_FLAGS} -m32")
+  set(CMAKE_SHARED_LIBRARY_C_FLAGS   "${CMAKE_SHARED_LIBRARY_C_FLAGS} -m32")
+  set(CMAKE_SHARED_LIBRARY_CXX_FLAGS "${CMAKE_SHARED_LIBRARY_CXX_FLAGS} -m32")
 else()
   target_link_libraries(${PROJECT_NAME}
   PRIVATE
@@ -100,7 +106,7 @@ endif()
 if(CMAKE_BUILD_TYPE MATCHES Debug)
   set(D2TM_OPTMIZATION "-O0")
 else()
-  set(D2TM_OPTMIZATION "-O3")
+  set(D2TM_OPTMIZATION "-O2")
   set_target_properties(${PROJECT_NAME} PROPERTIES
     INTERPROCEDURAL_OPTIMIZATION TRUE
   )

This did not help with this issue. However, the info may aid in debugging other issues if different field width handling of 32bit/64bit toolchains are a vague suspect to start debugging with. As prerequisites for this to work you need cross-compiling set up properly, see

• How to Compile 32-bit Apps on 64-bit Ubuntu?
• How to compile 32-bit executable on 64 bit system

Finally for the executable to link, 32bit version of allegro is needed as well, e. g. apt install liballegro4.4:i386 (if the compiler still complains that it skips x86_64 shared object of allegro when linking d2tm, try cd /usr/lib/i386-linux-gnu/ ; ln -s liballeg.so.4.4 liballeg.so )