Allegro.cc - Online Community

Allegro.cc Forums » The Depot » Open Source Zelda Classic

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Open Source Zelda Classic
ZoriaRPG
Member #16,714
July 2017
avatar

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Can you give us a general layout of the build? Does it build allegro alongside ZC? What about the add-ons? How are those built/installed beforehand? Dependencies?

I was going to try a few things, but I'm at work right now, so I'll come back to this later on.

Can I build ZC with my own version of allegro? You guys didn't do anything silly like #include <allegro.h> did you?

Chris Katko
Member #1,881
January 2002
avatar

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.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Edgar Reynaldo
Member #8,592
May 2007
avatar

Specter Phoenix
Member #1,425
July 2001
avatar

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. :)

"Can't a man even talk to himself without being interrupted?" -Krull(1983)
"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix
"Programming == AWESOME the rest is just tools to accomplish it."
END OF LINE

Gideon Weems
Member #3,925
October 2003

What's AG? Armageddon Games.

I have fond memories of Zelda Classic. It was my first introduction to the original Zelda. They did a great job with it.

Specter Phoenix
Member #1,425
July 2001
avatar

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.

"Can't a man even talk to himself without being interrupted?" -Krull(1983)
"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix
"Programming == AWESOME the rest is just tools to accomplish it."
END OF LINE

ZoriaRPG
Member #16,714
July 2017
avatar

#include "allegro.h" is everywhere. Every drawing facet relies on allegro. How could it not be?

The Allegro libs are not compiled with ZC though. The ZC binaries rely on a precompiled allegro44.dll, that must be produced with the custom Allegro build, first.

AGN has never gone away. :)

The codebase is gigantic, and it does rely on quite a few deps. Most of these are for audio, compression, and similar stuff. One gigantic thing that differs, is that the quest file structure uses a password mechanic, so many otherwise clean calls are wrapped in, or require a packfile_password call.

I should have linked to the GitHub page in the OP:

https://github.com/ArmageddonGames/ZeldaClassic

The 'master' branch is the future, '2.60' WIP stuff, and the current 'stable' is in the 2.50.x branch. ( That reflects v2.53.0. )

Edgar Reynaldo
Member #8,592
May 2007
avatar

You guys didn't do anything silly like #include <allegro.h> did you?

ZoriaRPG said:

#include "allegro.h" is everywhere. Every drawing facet relies on allegro. How could it not be?

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.

Audric
Member #907
January 2001

I disagree, angled brackets indicate the header is in "a" system-wide location that is not relative to the current directory you are building (if a file happens to have this name in current directory, it must ignore it). It does not imply that it will be the same directory as the compiler's standard libraries : it's the build system's job to provide the specific locations.

Switching from one version of allegro 3 / 4 to an other can be as easy as setting two options in a game's makefile : -I /mingw/include/older/allegro3.9.35 and -L/mingw/lib/older/allegro3.9.35

ZoriaRPG
Member #16,714
July 2017
avatar

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.

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.

Quote:

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.

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.

Quote:

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.

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

DarkDragon said:

[...]

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.

bamccaig
Member #7,536
July 2006
avatar

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.

This advice sounds Windows specific, and only because Windows is such a shitshow. In *nixes, you'd expect to find libraries in the "system" locations (i.e., /usr/include and /usr/lib). It's not weird at all. It makes perfect sense. Windows is the ecosystem that doesn't make any sense.

Neil Roy
Member #2,229
April 2002
avatar

Audric said:

I disagree, angled brackets indicate the header is in "a" system-wide location that is not relative to the current directory

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.

--
Deluxe Pacman (website now gone)
"I am not ashamed of my belief in God."

Peter Hull
Member #1,136
March 2001

Audric is right. For reference:
https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
https://docs.microsoft.com/en-gb/cpp/preprocessor/hash-include-directive-c-cpp
It is possible to specify the sequence of searched paths completely, if you want. Otherwise you get the compiler's defaults.

ZoriaRPG
Member #16,714
July 2017
avatar

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.

Peter Hull
Member #1,136
March 2001

I tried to compile on Linux. It nearly worked first time, I just had to copy alunixac.h to allegro/include/allegro/platform.

Well done to all concerned! :D

However I've now got three executables, zelda, romview and zquest, none of which do anything when run.

What's next? I guess I am missing some data files? I couldn't get the information from the wiki.

Cheers,
Pete

ZoriaRPG
Member #16,714
July 2017
avatar

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.

Gideon Weems
Member #3,925
October 2003

You might want to ask whether this package maintainer built ZC himself, given the upstream link.

Peter Hull
Member #1,136
March 2001

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

Chris Katko
Member #1,881
January 2002
avatar

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.

Do you have a joystick? I haven't tried the codebase myself, but that's a common joystick-is-plugged-in failure mode for applications/games.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Peter Hull
Member #1,136
March 2001

Do you have a joystick?

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

ZoriaRPG
Member #16,714
July 2017
avatar

Do you have a laptop? if so, it could be the accelerometer in your display, acting as a joystick. We ran into this with several Linux users, and that is clearly an allegro-side issue, because ag4 has no idea how to interface with it.

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.

Eh? What do you qualify as our 'embedded' allegro?

The sound issue is precisely what Grayswandir ran into. I do not understand what is causing it, but it seems to be a problem related to building allegro, and linking the sound libs, on newer Linux systems.

DarkDragon
Member #8,337
February 2007

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).

Peter Hull
Member #1,136
March 2001

ZoriaRPG said:

Do you have a laptop? if so, it could be the accelerometer in your display, acting as a joystick.

No, it's not a laptop.

Quote:

Eh? What do you qualify as our 'embedded' allegro?

Sorry, bad terminology. I mean the modified allegro that's part of the ZC github repository. I used that, rather than stock allegro from the Ubuntu apt package.

Edgar Reynaldo
Member #8,592
May 2007
avatar

 1   2   3 


Go to: