Support compiling under Linux about dune-ii---the-maker HOT 28 CLOSED

perhaps mac OS as well? (X86)

from dune-ii---the-maker.

I want to get rid of fblend anyway. It might suffer on the performance side of things, but I want to decouple from Allegro slowly.

I believe fblend routines can be replaced by allegro equivalent calls for now.

from dune-ii---the-maker.

Yes it should provide one with software rendering since according to the tutorials GL-windows are an option (kinda proof: http://wiki.libsdl.org/CategoryRender). Unless you want to develop 3D-models for everything you shouldn't mess with it, I guess. The current graphics adapters have 2D acceleration built-in so even 2D-rendering could be offloaded if everything is tied precisely in your code or in SDL.

...was my opinion until I had taken a look at SDL.

• they have much of beautiful functionality in stand-alone modules ( http://wiki.libsdl.org/FAQDevelopment#does_sdl_have_text_drawing_support ). They mention the libraries page which does not exist an it's hard to find what is the set of modules they are talking about.
• OK, you've found some of them: https://github.com/libsdl-org (SDL_mixer, SDL_ttf, SDL_image). Looks great. But I've found no documentation inside SDL_ttf repo at all. Of course, there's nothing about it in the official wiki. I bet you'll grow a willing-to-kill-everyone-Hulk in your head just trying to migrate a more or less working project to SDL having no docs/examples on critical parts of SDL.

It's up to you. Make a research. It still could be better than I think after a glance.

from dune-ii---the-maker.

Even prerequisites fail to build on Debian Buster.

Dune-II---The-Maker/dependencies/src/fblend0.5/fblend$ make
gcc -c src/cadd.c -o obj/unix/release/cadd.o -O2 -ffast-math -fomit-frame-pointer -I. -Isrc -Iinclude
gcc -c src/mem_test.c -o obj/unix/release/mem_test.o -O2 -ffast-math -fomit-frame-pointer -I. -Isrc -Iinclude
gcc -c src/csub.c -o obj/unix/release/csub.o -O2 -ffast-math -fomit-frame-pointer -I. -Isrc -Iinclude
gcc -c src/ctrans.c -o obj/unix/release/ctrans.o -O2 -ffast-math -fomit-frame-pointer -I. -Isrc -Iinclude
gcc -c src/radd.c -o obj/unix/release/radd.o -O2 -ffast-math -fomit-frame-pointer -I. -Isrc -Iinclude
gcc -c src/rtrans.c -o obj/unix/release/rtrans.o -O2 -ffast-math -fomit-frame-pointer -I. -Isrc -Iinclude
gcc -c src/2xstretch.c -o obj/unix/release/2xstretch.o -O2 -ffast-math -fomit-frame-pointer -I. -Isrc -Iinclude
gcc -c src/fade.c -o obj/unix/release/fade.o -O2 -ffast-math -fomit-frame-pointer -I. -Isrc -Iinclude
make: *** No rule to make target '/asmdef.c', needed by 'obj/unix/asmdef.exe'.  Stop.

BTW, fblend uses ASM optimizations. For that I'm not sure if it's OK to build it on amd64 platform. If you're not sure as well, will it be then better to disable that dependency on amd64?

from dune-ii---the-maker.

On allegro page they claim it works on Linux. Interesting fblend does not compile. Also asmdef.exe? Does not sound like Linux target. Maybe cmake was not run properly?
I want to make it work on Linux, cause that's my poison of choice, but need to find time first :)

from dune-ii---the-maker.

I've just cloned the project right into my CLion (Debian Bullseye). It only has allegro4.4 and 5 in package base. There's no packages for alfont, almp3 and fblend. Since CMakefile itself doesn't provide proper targets to build those extensions with cmake I've found those sources in dependencies and tried to build them manually.

For alfont and almp3 I've had to tweak makefiles to not use -march=pentium otherwise the build fails (64-bit platform is incompatible with -march=pentium)
For almp3 I've also needed to fix (char *)data += blabla errors with data = ((char *)data) + blabla;
For fblend I've just did fix.sh unix; make command.

from dune-ii---the-maker.

@SantjagoCorkez that sounds promising. So the only thing lacking is d2tm pointing to those libs. On my environment I copied the libraries into my mingw/lib dir. Might be sufficient for you to do it in a similar fashion.

from dune-ii---the-maker.

Well, I'm not sure I can do the same on 64-bit Linux. Those libraries for mingw seem to be 32-bit and compiled with 32-bit target. Will it be OK to link them statically into a 64-bit binary?

Dune-II---The-Maker/dependencies/mingw32/lib/libaldat$ file datalpha.o 
datalpha.o: Intel 80386 COFF object file, no line number info, not stripped, 4 sections, symbol offset=0x18e0, 60 symbols

from dune-ii---the-maker.

I am to old for CLion, so I am doing it the old fashioned way... writing CMakeLists.txt manually :)
So which version of Allegro is this? On Ubuntu newest is 5.2, but headers don't match with what you are using. For example "base" header is allegro5.h, not allegro.h. No version in headers is given as well.

from dune-ii---the-maker.

Well, I'm not sure I can do the same on 64-bit Linux. Those libraries for mingw seem to be 32-bit and compiled with 32-bit target. Will it be OK to link them statically into a 64-bit binary?

Dune-II---The-Maker/dependencies/mingw32/lib/libaldat$ file datalpha.o 
datalpha.o: Intel 80386 COFF object file, no line number info, not stripped, 4 sections, symbol offset=0x18e0, 60 symbols

libs in mingw32 are for windows. Don't link these on your linux. If you have correct allegro version on your OS add something like this to your CMakeLists.txt (I did it for allegro5, don't know older package names, so you'll need to fix these):

find_package(PkgConfig REQUIRED)
pkg_check_modules(ALLEGRO5 REQUIRED allegro-5 allegro_font-5)

target_link_libraries(d2tm fblend alleg aldat almp3dll alfontdll -static-libgcc -static-libstdc++ ${ALLEGRO5_LIBRARIES})
//...
target_include_directories(d2tm
        PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/building ${CMAKE_CURRENT_SOURCE_DIR}/include ${ALLEGRO5_INCLUDE_DIRS})
target_compile_options(d2tm PUBLIC ${ALLEGRO5_CFLAGS_OTHER})

Don't know how to write CMake for windows and linux optionally... yet :)

from dune-ii---the-maker.

d2tm uses allegro 4.2

from dune-ii---the-maker.

Well, I'm not sure I can do the same on 64-bit Linux. Those libraries for mingw seem to be 32-bit and compiled with 32-bit target. Will it be OK to link them statically into a 64-bit binary?

Dune-II---The-Maker/dependencies/mingw32/lib/libaldat$ file datalpha.o 
datalpha.o: Intel 80386 COFF object file, no line number info, not stripped, 4 sections, symbol offset=0x18e0, 60 symbols

Not sure about 64 bit. But I don't think it would harm trying.

from dune-ii---the-maker.

As I've said, I'm on Debuan Bullseye. It has

• allegro5 (which is allegro 5.2 ATM)
• allegro4 (which is allegro 4.4)

Allegro 4.4 is enough to compile add-ons, though, fblend fails due to errors in makefile itself (and I'm not sure those assembler codes are OK for 64-bit platform)

from dune-ii---the-maker.

allegro 4.4 then, although I am not sure if 4.2->4.4 has any breaking changes. You can't use Allegro 5 (it is a totally different API than 4)

from dune-ii---the-maker.

find_package(PkgConfig REQUIRED)
pkg_check_modules(ALLEGRO5 REQUIRED allegro-5 allegro_font-5)

target_link_libraries(d2tm fblend alleg aldat almp3dll alfontdll -static-libgcc -static-libstdc++ ${ALLEGRO5_LIBRARIES})
//...
target_include_directories(d2tm
        PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/building ${CMAKE_CURRENT_SOURCE_DIR}/include ${ALLEGRO5_INCLUDE_DIRS})
target_compile_options(d2tm PUBLIC ${ALLEGRO5_CFLAGS_OTHER})

Don't know how to write CMake for windows and linux optionally... yet :)

# set the project name
project(d2tm)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DUNIX")
set(CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -DUNIX")

# this cmakelist file is directly tied to MinGW, if you know a better way please let me know (PR, comment, etc)
#link_directories("lib/mingw")
include_directories("dependencies/src/alfont/include")
link_directories("dependencies/src/alfont/lib/djgpp")
include_directories("dependencies/src/almp3/include")
link_directories("dependencies/src/almp3/lib/djgpp")
# add the executableS
add_executable(d2tm Script.rc)
target_link_libraries(d2tm fblend alleg aldat almp3 alfont -static-libgcc -static-libstdc++)

But, as I've said, I need fblend to compile D2TM itself and I can't compile it due to errors in fblend. For now seems linux (64-bit at least) builds are broken.

allegro 4.4 then, although I am not sure if 4.2->4.4 has any breaking changes

At least not in API

You can't use Allegro 5 (it is a totally different API than 4)

Sure. That's true.

from dune-ii---the-maker.

About fblend. In the d2tm code, find all fblend related stuff and comment it out. I could fix that later using the equivalent allegro drawing functions (most likely a combination between draw_trans_sprite and set_trans_blender). Atleast that gets fblend out of the way.

from dune-ii---the-maker.

Now it complains about non-existent libaldat library. Where did you get all those plugins?

from dune-ii---the-maker.

afaik allegro 4.2 has support built in for data files.

see also: https://www.allegro.cc/manual/4/api/structures-and-types-defined-by-allegro/datafile

could be you need to build allegro yourself? https://www.allegro.cc/files/?v=4.2
When I check the allegro download page, I can see libaldat is part of the binaries. (do note, their page has download links pointing to http which are blocked by Chrome now (mixing http/https content, etc).

from dune-ii---the-maker.

Have built 4.4 from the sources manually. It builds libaldat.a but doesn't install it (that's why debian package misses libaldat). Copied it myself. D2TM build is broken.

In file included from ./Dune-II---The-Maker/dependencies/allegro44/include/allegro/base.h:41,
                 from ./Dune-II---The-Maker/dependencies/allegro44/include/allegro.h:25,
                 from ./Dune-II---The-Maker/include/allegroh.h:17,
                 from ./Dune-II---The-Maker/include/d2tmh.h:14,
                 from ./Dune-II---The-Maker/cGame_logic.cpp:22:
./Dune-II---The-Maker/dependencies/allegro44/include/allegro/alcompat.h:44:22: error: conflicting declaration of C function ‘fixed fadd(fixed, fixed)’
   44 |       AL_ALIAS(fixed fadd(fixed x, fixed y), fixadd(x, y))
      |                      ^~~~
./Dune-II---The-Maker/dependencies/allegro44/include/allegro/internal/alconfig.h:164:49: note: in definition of macro ‘AL_ALIAS’
  164 |       static __attribute__((unused)) __inline__ DECL    \
      |                                                 ^~~~

Tried to build 4.2 from the sources. The build itself is broken (configure command fails due to broken makefile, fixing it leads to

gcc -DALLEGRO_MODULES_PATH=\"./Dune-II---The-Maker/dependencies/allegro42/lib/allegro\" -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro  -DALLEGRO_LIB_BUILD  -mtune=k8 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -Wall -Wno-unused  ./src/i386/asmdef.c -o obj/unix/asmdef
/usr/bin/ld: /tmp/ccYqVnTX.o: warning: relocation against `_persp_xoffset_f' in read-only section `.text'
/usr/bin/ld: /tmp/ccYqVnTX.o: in function `set_window_title':
asmdef.c:(.text+0x43): undefined reference to `system_driver'
/usr/bin/ld: /tmp/ccYqVnTX.o: in function `desktop_color_depth':
asmdef.c:(.text+0x63): undefined reference to `system_driver'
/usr/bin/ld: /tmp/ccYqVnTX.o: in function `get_desktop_resolution':
asmdef.c:(.text+0x83): undefined reference to `system_driver'
/usr/bin/ld: /tmp/ccYqVnTX.o: in function `is_windowed_mode':
asmdef.c:(.text+0xe3): undefined reference to `gfx_driver'
/usr/bin/ld: /tmp/ccYqVnTX.o: in function `is_screen_bitmap':
asmdef.c:(.text+0x1a6): undefined reference to `screen'
/usr/bin/ld: /tmp/ccYqVnTX.o: in function `acquire_screen':
asmdef.c:(.text+0x263): undefined reference to `screen'
/usr/bin/ld: /tmp/ccYqVnTX.o: in function `release_screen':
asmdef.c:(.text+0x283): undefined reference to `screen'
/usr/bin/ld: /tmp/ccYqVnTX.o: in function `makecol15':
asmdef.c:(.text+0x322): undefined reference to `_rgb_g_shift_15'

Nah... I'd rather wait until you migrate to something useable because allegro sucks.

from dune-ii---the-maker.

Allegro 4 is eol a long time now. So yeah I can imagine this sucks and drains energy.

I think I'll move to SDL. Not sure if 1.2 is prefered for "old style" games or not.

from dune-ii---the-maker.

If you decide to migrate to something I'd kindly ask you to look first at the versions being provided in current release of Debian/Ubuntu. Maybe with some fallback to those in CentOS (but most developers provide with just Debian/Ubuntu packages and don't care of other distributions)

from dune-ii---the-maker.

When I start with this I'll try to notify this ticket as well. So your comment will remind me, and perhaps you could help me decide which library to migrate to. As I would like it to be cross-platform. Since it is not technically demanding what D2TM is doing I aim it to be runnable on a wide range of platforms.

from dune-ii---the-maker.

Then, according to what's written on the https://www.libsdl.org/ - that's what you need.

As for Debian Bullseye the package base contains:

• libsdl 1.2.15
• libsdl 2.0.14

I guess both will do unless 1.2.x is EOL

from dune-ii---the-maker.

I suppose it is wise to use SDL 2.x since 1.2 is no longer supported. I believe it is still possible to use software rendering (I don't want to rely on OpenGL in any way). See also: https://www.libsdl.org/download-1.2.php

good to know! 👍

from dune-ii---the-maker.

If i can say something: SDL2 is a living library.
It is used for many games and also supports many development platforms.
SDL2 also uses different modules as needed:

• SDL_ttf 2.0
• SDL_image 2.0
• SDL_mixer 2.0
• SDL_net 2.0
• SDL2_gfx
  All these modules are also up to date, which is no longer the case for SDL1.2 and associated modules. SDL1.2 is dead and SDL2 is so much better. With SDL2 the developer does not need to code in OpenGL or Vulkan. However, the library is responsible for using the graphics card by offering hardware acceleration.

Nowadays SDL2 is more used as a frontend to OpenGL / Vulkan. Everything that is displayed is at these 3D libraries. the SDL2 is the link with the keyboard, the mouse ...
For a project like d2tm, SDL2 would be perfect :)

from dune-ii---the-maker.

SDL2 looks like the best option so far. We need to do #57 first.

from dune-ii---the-maker.

We're not using SDL yet, but with this pr: #424 we get to a point where we should be able to compile the project for linux / mac os x. Might not be out of the box , but atleast the project no longer depends on binaries of dependencies. Also, the dependencies (ALFONT and Allegro) should work under linux, and most probably under mac os x. (although I am unsure about the latter, due to Mac OS dropping 32 bit support, and I don't know if Allegro 4.x works under Mac OS)

from dune-ii---the-maker.

Build works on Ubuntu (latest) GH action. Thx to all and @Akatsuki57 for helping out!

from dune-ii---the-maker.