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.

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?

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.

Gah, that's a lot of source files, and a lot of dependencies.

I was going to try and simplify it, but I don't even know what to build, and in what order.

Read README.MD and still a little clueless.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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!

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

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.

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

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

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.

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

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.

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.

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

No, it's not a laptop.

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.

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.

I'm not sure what you mean by "organization of the modules"?

1) Do you mean the compilation targets?

There are four: zcsound (a library used by the other targets), romview (a small helper utility), zelda (the main program that plays the game), and zquest (the main editor program).

2) Do you mean the literal modules? They are listed in plain text in the /modules folder. The CMake script parses the files and creates a list of sources accordingly. But this part of the CMake script should be 100% platform-independent and you shouldn't need to touch it.

3) Do you mean the external libraries? They're described in the README, I believe. The sources for all external libraries are in the zip files in the "other" folder. We do not have any scripts for building these dependencies; you will have to figure out how to use whatever scripts they provide themselves.

No.

No. As mentioned above, the add-on sources are provided but there is no CMake file to build the dependencies.

Binaries are built and stored in /libs. Most developers don't touch these since the dependencies are painful to configure and build; obviously if you want to link in a different version of Allegro you will have to rebuild them though.

Ahahaha! Um... yeah, the entire Allegro header tree is duplicated in /allegro because different parts of the code #include various internal Allegro headers. I agree that's far from ideal but not trivial to fix...

Please ZIP up the package that you built, and I will test it on 10.04. I do no tknow what had changed from 2011 to 2017 in the *ubuntu distros, except that when I tried to run a much later version of most of my hardware, it did not even recognise my trackpad as an input device, so I just stopped caring.

They dropped kexts, probably in a massive way, I would think.

We do need some kind of explanation of the file branching on GH. That is certainly true, and it needs to remain current. DD and Gleeok also added all of the backend and other modules, that are newer than the last version that compiled (via a makefile) in MinGW.

I can certainly send you that if you want it too; but clearly this is something that needs to be resolved on the home front.

I don't know what you're referring to, ZoriaRPG. There are two active branches, with clear-cut purposes: 2.50.x and master. The 2.50.x is a maintenance branch for bug fixes to the 2.50 line of releases. Master contains the current development code.

If you're trying to update the CMake scripts, you should do so on one of these two branches (only). I prefer master since the master branch contains some cleanup of CMakeLists which probably makes it easier to use and modify.

Hey guys, I'm trying to build latest Allegro 4.4.3 from GIT with your patches applied, and it fails to build properly with some missing declaration errors. Can you take a look and see if there is code missing which you have applied to your own fork of Allegro?

https://www.allegro.cc/forums/thread/616995

OK, solved the movement problem - Linux was registering my trackpad as a joystick, but one that was permanently jammed in the top left position. Go figure.
Anyway, a

[joystick]
joystick_device=/dev/null

in ag.cfg sorted that out

Next, I'll look at the sound. allegro.log just says that sound driver is disabled.

By the way, I'm not sure if you (ZC developers) are asking for help, or what sort of help you want. Anyway I am happy to have a poke around the code and test it on Linux for you. I also have a Mac but I'm pretty sure nothing using Allegro 4 works on recent macOS.

Pete

BOOYA!

Yeah, that was a good call. Every once in a while, someone makes a useful post here. (It's how we don't die.)

Chris Katko - cakes for you, humble pie for me! Sorry I forgot to give you credit for your insight (I got distracted in the middle of writing that post)

I have been suspecting that Allegro's MIDI and DIGI drivers simply do not work on newer Linux systems. Something in the kernel extensions, or driver support that comes with them; or a missing dep; perhaps?

ZC does work on OSX, through to the latest releases, although that idiotic security feature that Apple introduced requires workarounds. We need to package ZC for OSX using an installer in the future.

Good to see that you sorted the joystick issue. Why your trackpad was read as one is beyond me, but as I mentioned, I had issues using my system trackpad on 12.10.

If you upload the binaries that you compiled, and the Linx allegro libs, I will try them on my old 10,04 netbook.

Is your trackpad a standalone USB device, or is it part of an integrated keyboard+trackpad unit?

You are either half right or half wrong; take your pick. A number of older programs I've compiled against Allegro 4.4 on a fairly up-to-date system (kernel 4.12) have required MIDI_NONE in order for install_audio() to successfully return. I recently compiled a SpeedHack entry from 2002, and the only Allegro-specific patching it required was MIDI_NONE. (Other patching involved the C standard, which has apparently changed more than Allegro's API over the same period of time.)

As for possible explanations and solutions (for when MIDI is absolutely necessary), perhaps someone closer to Allegro's source can comment.

Anyway, what about the A4 example programs? Can you get MIDI output from them?

Bad nomenclature. I meant, that we need explanations on the paths and the includes, and such, in the readme.md file, although we could probably use a disclaimer in the readme.md file on the purpose of each branch in the tree, too.

I do not have a Linux system with this issue, but I will ask Grayswandir to try them. He is supposed to be signing up here to contribute to this thread. I am unsure what would have been disabled (in the Linux kernel) that is mucking up the allegro MIDI drivers. We may need to go with another MIDI system for our stuff, which I was considering anyway.

I would love to add MIDI + SoundFont support, but I'm not sure what libraries to use for that--any suggestions?. Obviously if there is a way to fix the allegro MIDI support, that would be fantastic, but I suspect that the access method is simply deprecated in the kernel.

Did other allegro sound routines (digital sound files, WAV and so forth), alogg, and almp3 work when you did this?

@Edgar Reynaldo, yes I missed an #include "wddraw.h" when applying the patches. Sorry about that.

Found a bug!
Start a game, head right from the start screen and die there.
Play again, head right again.
Game crashes with an assert, here

This is on Linux using the code from github. I haven't tried it with the released version, or other platforms.

Pete

Which commit are you using? I believe I fixed this issue a few days ago (c86bd1b464fb80da557df1d1593e43d074c3e656)

WAV worked fine, though I have yet to run across programs using alogg/almp3.

At that point, I would consider replacing MIDI with MOD.

With FluidSyth it's possible to support MIDI under Allegro5 relatively easily, it seems.

https://sourceforge.net/p/dunedynasty/dunedynasty/ci/f5a884821842ea9b414515f2742fccf4c45658a0/tree/src/audio/allegro_midi.cpp

Personally, to assist this project, I'd be interesting either in working on my a4a5 compatibility bridge idea, or, perhaps moreso, in making A5 plugins for Midi, packfiles, and other A4 features missing from A5.

SiegeLord applied the patch to GIT, and the binaries I built are on the dev board.

I'm gonna try my hand at learning CMake and trying to make a CMakeLists.txt for each ZC dependency. If I can get those all built properly then I can try building ZC. I wanna play it bad, but I want to play my own build for some strange reason.

Edit
I never played ZC all the way through. I kept trying to borrow it from my brother but he never let me play it except at his house. And that was years ago back on the NES. I still have mine, and it works if you treat the cartridges nice.

Lots of quotes here, so please bear with me...

The tl;dr is that we need to fix the KB issue, and the colour conversion slowdown on Windows, plus the audio issues on Linux.

This is not an option for us. Our userbase is very heavily MIDI-dependent. I have been looking at all of the various allegro config options for MIDI drivers, so if any of you could try setting various config options to see what works, and find one, please report it to us, so that we know what's going on with this thing.

I'm thinking that this may be an ALSA issue, too. I wish that I knew what changed in the Linux kernel that is causing this, but I have not been keeping pace with Linux stuff in the last five years.

(I run Ubuntu 10.04.)

I'm thinking that some of the tid-bits here may apply to this: https://wiki.allegro.cc/index.php?title=Using_TiMidity%2B%2B_with_ALSA_raw_MIDI

Setting the specific MIDI driver used by the kernel, may fix the issue. Allegro simply needs to know where to find it.

I grabbed the bins. We still need some kind of fix for the threading issue (keyboard input), and I should mention that on WIndows (and on OSX), fullscreen display has serious issues if you use -bit video bitmaps. Our fix, was to blit our -bit memory bitmap to a 24/32b memory bitmap.

I'm not sure if any combination of compiler, OS version, or libs, would help with that issue, as it seems to be related to changes in DirectDraw/DirectX. OSX in general, no longer supports dropping to an 8-bit plane without heavy-handed forcing the mode, which is just silly.

Which branch, master or 2.50.x?

Note: Fixing both the threading issue (keyboard input) and the Linux audio issues are my main concern at this point. Any help here, even casual, is very useful, and I would appreciate it.

As I have said, the a4a5 thing seems ideal, to me. Adding ag5 plugins for all of the missing a4 elements seems like as much work, and it may have other shortcomings. Using ag4 and ag5 at the same time, to permit a slow transition, would solve most of our major concerns. In fact, if we could use a5 input, that would be very beneficial.

Ag5 supports TTFs now, right? I was going to try to get alfont.h working, so that we can add TTF support, but if this transition layer works, and we can use the ag5 string drawing to an ag4 bitmap, holy hell, that would be brilliant.

Reharding CMake This is also a learning curve thing for me. Until ZC moved to CMake, I rarely, if ever, used it. I am in no state to fix the CMake lists, as I would need to learn the same stuff as everyone else here seems to need to learn, and I do not have all of the systems and compilers at my disposal, to test this stuff.

I'm in the process of trying to acquire a dirt cheap OSX laptop--all of my Mac stuff is PPC, not Intel--and trying the Code::Blocks config. I expect that to be broken too, and I will eventually need to learn CMake, but well, finite time, and lots of work-related worries at present.

Some ZC Notes

The ZC Repo is set up with two main branches:

Master This represents the 'next gen' main release, dubbed 2.60. All of the most radical changes are going into this.

2.50.x This represents the latest planned 'stable; release, dubbed 2.53.0. THis build is my present priority, to get out a final build for the 2.50.x line.

Undeterminedi also plan to do interim-releases of 2.54, and 2.55, incorporating new features, and fixes, as a user-transition phase until 2.60 is ready. I was originally hoping that master would be 2.55, but the scope of the planned changes, improvements, and other new stuff keeps pushing it forward. Feature creep is taking over, and it seems that it will take a while to solidify the plans.

Once I have 2.53.0 done and ready, I can focus on both master, and some kind of interim release. My goal, is to see one major release every 6 to 12 months, from this point onward.

One major user concern in the present 2.53.0 betas is that the framerate was halved, seemingly caused by the lack of ASM routines for colour conversion. I do not know if this is an allegro bug, or an artefact of how the libs were compiled. If you run 2.50.2, and 2.53.0-beta2 sie-by-side, the maximum FLS is halved for the latter.

For vanilla stuff, this is not a huge issue, but once you factor in scripting events, this can be a major issue, particularly on older HW, which many of the people in the ZC community still use.

I'll try compiling the latest 4.4.3 repo next week,a nd see if my compilation produces any different results. For those interested, I am using:

[graphics]
disable_direct_updating=1
gfx_cardw=DXWN
gfx_card = DXAC

...in ag.cfg.

This is on Windows. I'm not sure how any of this affects Linux, save that on my old Inspiron 910, running ZQ using Ubuntu 10.04LTE with Gnome, was unplayably slow, in a stock, non-scripted quest, whereas on the exact same system running Win XP it was super-fast.

Once I acquire more parts, i will rebuild my second Dell E6430, running 10.04, and 12.10, and see what happens. I can run that side-by-side with my E6430 running Win 7, to compare.

if any of you know in what Linux kernel the changes were introduced that affect MIDI drivers, please let me know,

Master. It was indeed fixed by DarkDragon's commit (as mentioned above)

I've now got digi sound working on Lubuntu but no midi yet. This was using the Allegro provided by the distro and choosing the sound card manually (ALSA in my case). So we are getting there.

As an aside, I also tried on 64-bit Linux. I had to find all the source code for alogg etc. and recompile them as 64 bit libraries. It compiles and runs, but can't load the quest files. There are some assumptions about the size of various integers (specifically that long is 32 bits) which I believe will require some quite extensive fixing if you go down that route - see https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

Pete

Pete, you cannot compile as 64b. The short of this, is that we support old c++03, which has no idea how to handle newer types. I'm pretty sure that fixed.h would cause massive issues, too.

For audio, perhaps the JACK driver might be better?

I;m thinking that you need to figure out what your system MIDI device is, and set it in ag.cfg. For ALSA, The TiMIDI FAQ has some useful information on configurations:

https://wiki.allegro.cc/index.php?title=Using_TiMidity%2B%2B_with_ALSA_raw_MIDI

The tl;dr

I'm also posting DarkDragon's allegro+ZC libs building steps (Windows, MSVC) here:

I don't think it's new types as such, just that the code assumes in several places that long is 32 bit (particularly reading from dat files). It's just a bit tricky because void pointers are used (e.g. p_igetl) which stops the compiler from spotting all the problems. Furthermore there are things like enemy::dmiscs which are defined as long but probably don't really need to be 64-bit integers. Anyway I agree this doesn't seem to be a priority just now, I'm just flagging it up.

The latest commit to fixed.h is "Made Allegro more 64-bit friendly"; I think it's OK.

I tried all the Linux drivers using detect_digi_driver, ALSA was the only one that didn't return -1. Likewise for detect_midi_driver. Is JACK something that can be installed? I'll check.

I can but try. I have had timidity working in the distant past but it was very CPU intensive.

Aren't u32 and u64 implemented in just about all compilers by now?

The issue isn't compiler support. As Peter Hull correctly points out, the issues are

1) a lot of places in the code (especially in the loading/saving) take the address of integer types, and each case must be manually inspected to make sure the types remain correct in 64-bit mode;

2) the code uses a hodge-podge of different typedefs for representing the same type; in the current code unsigned int == dword == uint32_t. In 64 bits this equivalence is no longer true.

I've been converting the integer types to uint* in places that matter as I go, but this is far from an overnight process.

For a4a5 i was only planning one way conversion from A4 to A5 bitmaps and blotting A4 bitmaps to the A5 window. First draw everything to an A4 bitmap, then to the A5 window, then do A5 drawing on top of that if needed. But no A5 drawing on A4 bitmaps...

Holy heck, thanks for passing this along. I'm going to try it out.

No problem, mate. If you discover anything useful out of that, please post about it.

At present, I am having strange issues with LOADPNG ad LIBJPG. It does not seem to matter what compiler, or who compiled 4.4.3, PNG and JPG loading is failing on the initial call to the libs, but it succeeds every call thereafter.

I do not see why, or if there is some linking issue that we have all missed, or if I need to package a blank PNG with ZQuest and have the initial tile editor import graphic function load a blank PNG so that it masks out the bug, just to get this release out.

I do know that I can somehow compile Allegro.dll from ~4MB down to ~550KB, with various config options, all seemingly as static libs, and that the Allegro CMake config files are in need of revision in the future. How much baggage does it truly need? How many licks to the centre of a Tootsie Roll pop?

On another note, who is in charge of the depot database?

I would like to link the current dev team to the old Zelda Classic entry, so that we can retain the old reviews of the programme, rather than using the new entry that I opened. JMan cannot find his login details, and from what I can see, his account was expired by someone at some point, as when I tried to add him to the depot project that I opened, it claimed that the user was invalid.

Is there anyone that can go into the Zelda Classic depot entry in the database, and add DarkDragon and me to that, so that we can bring it up to current, and purge the duplicate entry?

Matthew is. But he's been M.I.A. for a year now.

https://www.allegro.cc/members/matthew.leverton/

Check out his website and send him an e-mail if you really need it.

[edit] Looks like his website now forwards to his google plus page?

It has done that for at least a few years now.

Well, after over fsixty hours of building different Allegro configs, I decided to look at this PNG and JPEG issue from a different angle. It was still related to the allegro change, but it was rather idiotic. I fixed it in the ZC source by setting packfile_password to NULL before loading the image.

Sigh.

We have Zelda Classic, v2.53.0 Beta 7 for Windows available, for any of you who wish to try it.

A Linux build may take a while yet though, as we have not sorted the sound issue. I still believe that this is something with ALSA in the kernel. ::shrug::

I gave out your latest release of ZC a test run. Made it through like 10 screens before I died. Lame. But, I noticed that you don't support 16:10 WideScreen aspect ratios like 1920x1080 (Standard HD). I can show you how to detect all available fullscreen modes in Allegro 4 if you wish.

It was something I worked on back when Allegro was on 4.3.10. Like 8 years ago or something.

EDIT
I suck at this game. I managed to buy a candle but I don't know what to burn. No spoilers please I'm basically playign this game through the first time.

EDIT2
Here's an updated chm manual for Allegro 4.4.3. It comes with my binaries, but I thought you might like it.

https://www.allegro.cc/files/attachment/611020

See get_gfx_mode_list(int card) under the graphics section of the api.