I'm making this thread to discuss open source, ZC, including compiling the source on various CMake configurations and compilers; particularly given the issue that Edgar encountered, so that there is a central place on allegro.cc to the ZC devs to pop in and work with the allegro forumers.

They have their own complete Allegro fork that they patch. The docs say "DO NOT USE stock allegro."

If I actually had free time, I'd love to do it myself. It sounds like a fun project and 99% of my job is migrating old programs and old data from systems 10+ years out of support.

Wow, ZC brings back memories of AG. Current AG is small compared to AG of old . I thought ZC had gotten into problems in the early 2000s so I'm glad to see I was wrong.

Yeah, I was part of AG back when they had an anime discussion forum where they had a thread of thousands of Anime pics that were of a racy nature. They did away with that years ago I believe. I don't even recall my username on there anymore.

You mistook my meaning. #include'ing by quotation marks is fine, but angle brackets is not, because then it expects to find the library in the system header location, which is bad, because you never want to install libraries in your compiler directories if you don't have to.

What I want to know is, is it possible to use my own allegro and dependencies that I provide? Because I know for sure that there will be binary compatibility faults between your pre-compiled allegro and any compilation of ZC by me because they used different compilers.

Basically, I need to compile your entire source librar(ies) and dependencies myself, so I need to know which files belong to which project, and what depends on what. Also, what is optional and what is not. Your cmake build script doesn't provide many options. At the very least, it should include options where to find allegro and the dependencies it needs. There should be an include and lib option for each dependency. Shared and static build options would be nice too, but aren't strictly necessary.

As far as I am aware, in cpp, if the compiler fails to find the quoted header at a local level, it shifts to the system-wide <header>. If you were worried that we hardcoded to use a system-wide, when we use a customised header, then no, we never did that.

I did notice your use of angle braces, but I did not instantly infer that your were specifying them. Sorry for the confusion.

A few things. Allegro must be static-linked, to work with this. If you use your own allegro lib that is static linked, it might work, but expect either pixel corruption, data issues, or plain old crashing. I ran into several issues trying to use a dynamically linked lib for Allegro 4.4.3 about a year back, that caused ZC to crash whenever it tried to use audio files in the packfiles.

Building the deps, for Linux: I'm unsure. I have some older .a files floating around, but this has been a major snag. No-one has been able to get a Linux build out recently, because they all have some sort of flaw.

I'm not the one that manages the CMake configs at all. I'm not even a CMake bloke. You want to work with :

As he created the CMake stuff for ZC. Any improvements for the CMake stuff are of course, quite welcome; so perhaps you and he can fix this for Linux. I will point Grayswandir over here too, as he is the only one of us using Linux at present.

We used to have plain old makefiles for these things, but every compiler is different, and that became a huge tangled mess. I shifted from using MinGW (on Windows) to MSVC 2008, because of the CMake shift. I simply do not know enough about CMake at present, to fix these things. It is so far past my generation, that it requires me to study it in depth, which requires more time than I have to spare, while I work on the rest of this mess.

In the interim, see if the files in /libs/Linux or libs/MinGW still work.

The minimum requirements are in /include:

almp3
alogg
dumb
gme
jpgalleg-2.5
loadpng
lping1212
pthread
zlib123

Some of these need to be updated, too--cough, cough, GME; what version now?--. If you see stuff here that Allegro 4.4.3 handles natively that we are wasting time using, let us know.

I agree with you. I use angle brackets all the time, because I have my compiler's directory, but I also have my own separate directory for added libraries which I include in the search folders the compiler looks in.

One should only use quotes for local headers.

You can also set up compiler-specific include paths, in most instances. Many IDEs allow adding a number of include paths, as well. Nothing makes a mess like having nine separate include paths for any given project; but it is nice to have a choice when you have a default, and a custom set of something.

Quoted includes are relative. That is the key facet, and I am not certain that the precise handling of that relativity is identical in all newer implementations of C and Cpp, and on every compiler (or environment).

It's one of those things that you think would be cleverer.

On Windows include <foo> will include from a path specified to the compiler, or environmental base. This can become broken, with some systems. Let's examine MinGW:

The typical MinGW system on Windows, also includes MSYS. The gcc compiler for MinGW, and the gcc compiler for MSYS, pull their include path from two entirely different places in the filesystem. If you have a makefile, and run it in MinGW-make, the results can be wildly different than if you ran it in MSYS with make.

I have experienced this first-hand.

You need the 2.50.2 Linux data files. Grab ZC 2.50.2 for Linux from here:

http://www.zeldaclassic.com/download/100/

Un-gzip it, and then drop your binaries into the path. The 2.50.2 executables all have a -l in their filename, and your new executables should not.

Don't forget to put the allegro44 lib and the new sound lib into the path.

What compiler did you use, and what Linux distro? Did you use the modified allegro 4.4 files when building the allegro 4.4 libs, or are you using a stock comfiguration?

Please let us know if you have sound, presuming that it runs without crashing, or having any other critical bugs.

ROMView should only need the alleg44 library file to run.

To answer your questions: I used Lubuntu 17.04 and GCC 6. I used 'your' allegro and other libraries, as supplied from github.

As far as I can tell with ldd, everything is statically-linked so I just copied the executable files across.

It did run. I got no sound with the version I built but the 2.50.2 version did have sound. I possibly haven't got the right development packages installed for sound, so it was skipped during build. I'll check that.

Unfortunately once the game starts, Link runs up to the top of the screen and then as far left as he can go, without me pressing anything. In fact, nothing I press apart from ESC does anything. This happens with 'my' version and with 2.50.2. I think that may be the game logic rather than Allegro since I can navigate the menus using the keyboard.

On the development side, I couldn't get the embedded version of Allegro to build at all, the makefiles just reported there was nothing to do. Unfortunately I have no skills with CMake whatsoever, so I don't know why.

Hope that helps,
Pete

No. Good point though, I've come across that, too.

I did create the CMake configuration (but I'm by no means a CMake expert, so please let me know if there are things that need fixing). In particular I didn't put in any config options for getting ZC to compile using MinGW (MSVC 2008 or higher should work).

I'd love to help get this building with CMake and MinGW, but unless somebody informs me as to the organization of the modules I can't really help and don't want to.