Printable View
Hi, it's really great news the sources from Zelda Classic are now open-source. I tried to compile with the given VC2008 solution but it failed. I tried to compile with the makefile, but it seems the libraries given with the git repository are in a 32 bits format and is invalid with the distribution of mingw I currently have. What is the setup you use to build the sources? Thanks.
The VS2008 builds are not up to date. @Gleeok 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.
@Saffith
Know what's going on here by chance?
http://stackoverflow.com/questions/3...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
@Saffith
Another roadblock. -__-
Let me guess I was suppose to install dx7. I Just copied it like it told me to in the instructions.
Code: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.
@Saffith
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'
@Saffith
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. :p
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: 'ﾐY,ﾙﾓｂ韋・縮 ｰ莎幸Ty<ｪ､・ (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 @Saffith 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
@Gleeok
Actually Gleeok, I can compile it just find.
I'll look at the new package over the weekend. @Gleeok : 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.
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?Quote:
Originally Posted by Gleeok
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?
@ZoriaRPG
Don't use the .proj files. You can't compile ZC 2.5.2 with those.
@Saffith does the makefile compile on Linux as far as you know?
Quote:
Originally Posted by Tamamo
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.
@Gleeok
No, I have had no such errors since I switched to MSYS.
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.Quote:
Originally Posted by Tamamo
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.Quote:
Originally Posted by ZoriaRPG
You know that header files are not supposed to produce object files right?
Then it needs to be included in another cpp file.Quote:
Originally Posted by Gleeok
Que? Donde esta mi medicamento? No habla Engles.Quote:
Originally Posted by Tamamo
Find your own medicine, and you mispelled Inglés.
I meant it needs to be added to the other make lines for the cpps that include it gleeok.
I tried looking for "another.cpp" file but it doesn't exist. ;)
The makefile only needs that information so that it can tell which object files depend on what and therefore what needs rebuilt when a file changes. It'll still build correctly without it; it just won't always know what to build. I'll add it in, but, honestly, the makefile's in such bad shape that it's probably a better idea to build from scratch every time anyway. I've been meaning to add a build-deps target for a while now...
I already know what I have to do. I'm japanese, I don't speak english as a first language mkay.
obj/zquest.o: src/zquest.cpp src/bind.h src/config.h src/colors.h src/editbox.h src/EditboxNew.h src/ffasm.h src/ffc.h src/ffscript.h src/fontsdat.h src/gamedata.h src/gui.h src/items.h src/jwin.h src/jwinfsel.h src/load_gif.h src/midi.h src/parser/Compiler.h src/qst.h src/save_gif.h src/sfx.h src/sprite.h src/subscr.h src/tab_ctl.h src/tiles.h src/zc_alleg.h src/zcmusic.h src/zdefs.h src/zq_class.h src/zq_cset.h src/zq_custom.h src/zq_doors.h src/zq_files.h src/zq_init.h src/zq_misc.h src/zq_subscr.h src/zq_tiles.h src/zquest.h src/zquestdat.h src/zsys.h
$(CC) $(OPTS) -D_ZQUEST_SCALE_ $(CFLAG) -c src/zquest.cpp -o obj/zquest.o $(SFLAG) $(WINFLAG)
@Saffith
Might want to get on that.
Ah, that's right. Now I remember why I never use makefiles.
I have to ask, as I initially thought that was [sarcasm], but I can't be sure: Japanese?Quote:
Originally Posted by Tamamo
@Grayswandir ... We need to figure out why he can't get allegro to compile. I'm betting this is one of those things that was fixed in 4.3/4.4.Quote:
Originally Posted by Tamamo
I might do a test Linux build though.
It goes beyond that. We don't use Git the way it is meant to work, which is why this is such a flipping mess/nightmare. I'll start a thread on this, and see where it goes, but we need a stable commit before anything will ever work properly.Quote:
Originally Posted by Tamamo
This is the makefile I used to get 2.6 to build, if you want it as a reference: http://pastebin.com/KdW6XEGS
It's only for linux. I moved stuff into a src directories and such, and set it up to use wildcards and automated dependency generation instead of listing every file's dependencies manually.
Not that I'm terribly aware of what's going on, but I don't see the advantage of splitting repositories - it's the same program, after all. You can make all the branches you want.
Thanks, that'll help a lot. I really ought to learn to do makefiles properly at some point...
I'm planning to delete the 2.60 folder and create a proper branch for 2.50.x, and probably another for further 2.x versions. Meant to do it over the weekend, but, y'know, stuff.