Compiling Zelda Classic instructions?

The VS2008 builds are not up to date. [MENTION=42714]Gleeok[/MENTION] takes care of that naturally. Saffith is the one who updates the makefile which is set up for 32 bit format by default. Either wait for Gleeok or download a 32 bit distribution of mingw.

I'm not sure it's even possible to compile some of the libraries as 64-bit. Try using the -m32 switch with MinGW.

How do we go about compiling using an MSYS environment. I have it set up correctly but whenever I try to compile use the make command it returns an error saying it cannot locate the allegro libraries. Which I know exist. Also how do I go about linking the Boost libraries?

Did you install Allegro after building it? If it's installed properly, you should be able to run allegro-config to get the necessary arguments. If the ALLEG_LIB setting in the makefile doesn't work for some reason, you should be able to change it to
ALLEG_LIB = `allegro-config --libs --shared`

The Boost libraries used are header-only; they don't need any linking.

[MENTION=38582]Saffith[/MENTION]
Know what's going on here by chance?
http://stackoverflow.com/questions/37660730/compiling-allegro-4-for-mingw-msys

Try running
export UNIX_TOOLS=1
first.

Also, if you get an operand type mismatch error on fnstsw (I thought we had fixed that, but I'm still seeing it), in src/i386/icpus.s, change line 70 to
fnstsw %ax

[MENTION=38582]Saffith[/MENTION]
Another roadblock. -__-
Let me guess I was suppose to install dx7. I Just copied it like it told me to in the instructions.

C:\msys\allegro>Compiling Allegro for MinGW32, optimised. Please wait...
gcc -s  -Wl,--subsystem,windows -o tests/win/dibgrab.exe obj/mingw32/alleg/dibgrab.o lib/mingw32/liballeg.a -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x135): undefined reference to `save_bitmap'
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x1cc): undefined reference to `_imp__default_palette'
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x1dc): undefined reference to `set_palette_to_hdc'
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x277): undefined reference to `blit_from_hdc'
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x2f0): undefined reference to `stretch_blit_to_hdc'
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x4c3): undefined reference to `_install_allegro_version_check'
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x4d0): undefined reference to `set_gdi_color_format'
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x4ec): undefined reference to `create_bitmap_ex'
obj/mingw32/alleg/dibgrab.o:dibgrab.c😞.text+0x562): undefined reference to `destroy_bitmap'
collect2.exe: error: ld returned 1 exit status
make: *** [tests/win/dibgrab.exe] Error 1

If you didn't install DX7, yeah, you probably should. I don't think that's the problem here, though. dibgrab is a test, not part of Allegro itself. It doesn't really matter if you don't build it, but maybe it's failing because Allegro didn't compile.
It's looking for the static library, but ZC doesn't use that. Check in lib/mingw32. If the dll's there, you can probably just make install and be done with it. Otherwise, maybe do a make veryclean and start again.

[MENTION=38582]Saffith[/MENTION]

Okay got allegro compiled
Did you remove the Linkhandler or something? Says it can't find it.

make *** No rule to make target 'src/linkHandler.cpp' meeded by 'oj/linkHandler.o'

[MENTION=38582]Saffith[/MENTION]
Almost there! I'm 10 meters from the top of the hill and then there's the downward spiral!
I fixed the linkhandler issue.

It compiles, but it is not raining men unfortunately.

edit: And yes I moved the dependencies. "The data files from 2.5.2 over as well as the quest files and everything. Still isn't working."

edit2: I wish I had a mac like you Saffith. 😞

Nah, Linux. My only Mac's a VM. Wouldn't recommend that.

Anything useful in allegro.log? Failing that, console output?

I'll fix the LinkHandler stuff in the makefile. You'd think I could at least delete things properly. 😛

Allegro is outputting a Invalid header string errors upon getting pass the the title screen of ZC "which it loops and crashes" and opening ZQuest which it doesn't crash interestingly enough.

Decrypting...okay.
Opening...okay.
Invalid header string: '&#65424;Y,&#65433;&#65427;&#65346;&#38859;&#12539;&#32302;&#65392;&#33678;&#24184;Ty&#59169;<&#65386;&#65380;&#12539; (was expecting 'AG Zelda Classic Quest File
' or 'AG ZC Enhanced Quest File
'😉

Ah, shoot, forgot about that. Another thing that never got removed properly: disabled encryption. export USE_ENCRYPTION=1 and build it again. You might have to make clean first, but I don't think it's necessary.

Works. strangely the executables don't have their icons though. Not that it matters.
Thanks again [MENTION=38582]Saffith[/MENTION] really means a lot you taking the time the last few days to settle this matter.
Now It's time to fix that freaking hookshot that has been the death of us, am I right?

AFAIK I've dealt with all the complaints about compiling on MSVC x86. Let me know if something is still broken for you

[MENTION=42714]Gleeok[/MENTION]
Actually Gleeok, I can compile it just find.

I'll look at the new package over the weekend. [MENTION=42714]Gleeok[/MENTION] : Does this use the 2.6 files, as we discussed, or do I still need to fiddle with it, to use those?

Nothing uses the 2.6 files. The 2.6 files are just the 2.52 files I think, or somewhere around there, I forget.

I don't use anything but the current working version of ZC, which is what's in the trunk right now.

Gleeok wrote:Nothing uses the 2.6 files. The 2.6 files are just the 2.52 files I think, or somewhere around there, I forget.

I don't use anything but the current working version of ZC, which is what's in the trunk right now.

So, the short answer is that the builds under those .proj files are unstable, and use the new enemy and engine code changes; or were those reverted?

Would it be possible to request that we start using a basic changelog for 'latest', pretty please, so that we have a simple list of what has changed since 2.5.2?

[MENTION=42228]ZoriaRPG[/MENTION]
Don't use the .proj files. You can't compile ZC 2.5.2 with those.

[MENTION=38582]Saffith[/MENTION] does the makefile compile on Linux as far as you know?

Tamamo wrote:[MENTION=38582]Saffith[/MENTION] does the makefile compile on Linux as far as you know?

Are you talking about relative directory preprocessor errors? That's the only thing I can think of. If so, the problem is probably that I add "src/" to the include path and maybe nothing else does.

[MENTION=42714]Gleeok[/MENTION]
No, I have had no such errors since I switched to MSYS.

Tamamo wrote:[MENTION=42228]ZoriaRPG[/MENTION]
Don't use the .proj files. You can't compile ZC 2.5.2 with those.

I have the .proj files from the old 2.50.1 source pack. I had originally intended to make a pacage with that too, but overall a makefile is always the way to go for other people to use it.

We need to discuss policies though, for Git. As of now, there is no stable build 'master', with forks for additions. Without that, the git repo is just a trainwreck, and we're never going t have good participation. I think we should have a 2.5.2 masterbranch, for people to do things with, if they wish, and a 2.x master branch, that has all of the known-stable additions/changes to date, that you, Gleeok, Saffith, and I have made.

That's the script drawing stuf, and probably some npc and object stuff.

This will allow interested people an entry point to download, compile, and test; and a point to make their own contributions.

ZoriaRPG wrote:I have the .proj files from the old 2.50.1 source pack. I had originally intended to make a pacage with that too, but overall a makefile is always the way to go for other people to use it.

We need to discuss policies though, for Git. As of now, there is no stable build 'master', with forks for additions. Without that, the git repo is just a trainwreck, and we're never going t have good participation. I think we should have a 2.5.2 masterbranch, for people to do things with, if they wish, and a 2.x master branch, that has all of the known-stable additions/changes to date, that you, Gleeok, Saffith, and I have made.

That's the script drawing stuf, and probably some npc and object stuff.

This will allow interested people an entry point to download, compile, and test; and a point to make their own contributions.

I vouched already for separating them into two repositories. But gleeok isn't arsed enough to do it apparently.

[MENTION=38582]Saffith[/MENTION] [MENTION=42714]Gleeok[/MENTION]

obj/bind.o: src/bind.h src/config.h
$(CC) $(OPTS) $(CFLAG) -c src/bind.h -o obj/bind.o $(SFLAG) $(WINFLAG)

I'm doing something wrong here not sure what though. :/

You know that header files are not supposed to produce object files right?

Gleeok wrote:You know that header files are not supposed to produce object files right?

Then it needs to be included in another cpp file.

Tamamo wrote:Then it needs to be included in another cpp file.

Que? Donde esta mi medicamento? No habla Engles.