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
DarkDragon
Member #8,337
February 2007

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.

Does it build allegro alongside ZC?

No.

Quote:

What about the add-ons?

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

Quote:

How are those built/installed beforehand? 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.

Quote:

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

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

ZoriaRPG
Member #16,714
July 2017
avatar

Peter Hull said:

[...]

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.

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.

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.

DarkDragon
Member #8,337
February 2007

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

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

Peter Hull
Member #1,136
March 2001

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 :D

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

Chris Katko
Member #1,881
January 2002
avatar

Linux was registering my trackpad as a joystick,

BOOYA!

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

Gideon Weems
Member #3,925
October 2003

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

Peter Hull
Member #1,136
March 2001

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)

ZoriaRPG
Member #16,714
July 2017
avatar

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 :D

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

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?

Gideon Weems
Member #3,925
October 2003

ZoriaRPG said:

I have been suspecting that Allegro's MIDI and DIGI drivers simply do not work on newer Linux systems.

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?

ZoriaRPG
Member #16,714
July 2017
avatar

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.

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.

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?

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?

DarkDragon
Member #8,337
February 2007

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

Peter Hull
Member #1,136
March 2001

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

DarkDragon
Member #8,337
February 2007

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

Gideon Weems
Member #3,925
October 2003

ZoriaRPG said:

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

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

Quote:

I would love to add MIDI + SoundFont support, but I'm not sure what libraries to use for that--any suggestions?

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

beoran
Member #12,636
March 2011

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

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.

ZoriaRPG
Member #16,714
July 2017
avatar

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.

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

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.

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

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.

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 [github.com]

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

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.

Beoran said:

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.

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,

Peter Hull
Member #1,136
March 2001

ZoriaRPG said:

Which branch, master or 2.50.x?

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

ZoriaRPG
Member #16,714
July 2017
avatar

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

#SelectExpand
1Find the device name of the Virtual Raw MIDI port. Since I went with the first Raw MIDI port, the device name I want is hw:1,0. 2 3amidi -l 4 5Device Name 6hw:0,0 MPU-401 MIDI 0-0 7hw:1,0 Virtual Raw MIDI (16 subdevices) 8hw:1,1 Virtual Raw MIDI (16 subdevices) 9hw:1,2 Virtual Raw MIDI (16 subdevices) 10hw:1,3 Virtual Raw MIDI (16 subdevices) 11 12Finally we tell Allegro to use that device in allegro.cfg. 13 14[sound] 15... 16alsa_rawmidi_device = hw:1,0

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

DarkDragon said:

1. Run Allegro's CMake with SHARED set to true (checked).
2. Compile Allegro (only). This will generate alleg44.lib and alleg44.dll.
3. Run Allegro's CMake with SHARED set to false (unchecked).
4. Compile loadpng and jpgalleg (only). This will generate jpgalleg.lib and loadpng.lib (no .dlls).
5. Copy all .libs into libs/win32 in your ZC folder
6. Rename jpgalleg.lib to libjpgal.lib (or alternatively, change the name in CMakeLists.txt).
7. Build ZC
8. Copy alleg44.dll into whichever folder you are running the ZC .exes from.

Alternatively, you can skip steps 3-8 and instead build jpgalleg and loadpng from the standalone source, like we used to do (sources are in other/ldpng15.zip and other/jpgalleg-2.5.tar). These don't have Visual Studio projects so you'll have to configure and build them yourself (way easier than CMake, amirite?)

Peter Hull
Member #1,136
March 2001

ZoriaRPG said:

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

Quote:

I'm pretty sure that fixed.h would cause massive issues, too.

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

Quote:

For audio, perhaps the JACK driver might be better?

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.

Quote:

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:

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

Arthur Kalliokoski
Second in Command
February 2005
avatar

just that the code assumes in several places that long is 32 bit (particularly reading from dat files).

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

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

DarkDragon
Member #8,337
February 2007

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.

beoran
Member #12,636
March 2011

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

Gideon Weems
Member #3,925
October 2003

ZoriaRPG said:

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

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

 1   2   3 


Go to: