DevilutionX - Diablo 1

Hello friends!

Soooooooo....
Finaly I got to somewhere, I was able to successfully recompile Diablo 1 client, my first recompiled project YAHOOO!!!




However, I'm unable to read and parse the mpq file during start up as You can see on screenshot.
It uses 3rd party library StormLib, I tried to debug that there, it fails on following part:


It looks more like MPQ file problem than a bug to me.

Is anyone willing to give it a try in case my files are incorrect?
Any advices from developers how to deal with that?

Thanks

@NoCache

Does the code you're compiling work on big-endian CPUs?

If the code reads the file in as one large buffer and the file was generated for little-endian machines, then the code snippet you posted will read values round the wrong way.

If endianness is the problem, then you'll need to:
1. Have a file with endianness conversion macros (e.g., LE32_TO_CPU()
2. Go through the code and insert the macros wherever data from the file is being read (e.g., LE64_TO_CPU(pHeader->HetTablePos64)) (that's assuming that HetTablePos64 is 64-bit

HINTS:
- #include <machine/endian.h> defines BYTE_ORDER, so you can use #if (BYTE_ORDER == BIG_ENDIAN) to define the correct versions of the macros in both big and little-endian platforms
- GCC 4.4.0 and newer have built in __builtin_bswap16(x), __builtin_bswap32(x), __builtin_bswap64(x)

Hans

I think it's unlikely your data files are corrupt.

gcc 5.3.0 et al is here.



Unfortunately these files appear to have both compression and encryption. Maybe the code supports individual data files, too?
https://en.wikipedia.org/wiki/MPQ_(file_format)

@NoCache
Once you see anything about byteoffsets, headers and stuff when it come to reading files to memory , you can be on 99% sure it is Endianes which cause issues.

To add to Han's answer, you also may use SDL's endian conversion functions:



And for gcc if you use any old one (like one from SDK), just build latest one from adtools repo, so to have 8.2.0. It is well tested already.

@Hans
I found that Big-endian is supported by code, so all I had to do so to configure the environment correctly.
Tried to use the __buildin swap functions but it ended as undefined reference, anyway, I found the functions in SDL_Endian while wondering around in SDK.

Now I'm able to read the files, open the main window and initialize SDL, then I got to GR, so it is time to do some debugging



@kas1e, @thematic
I used default SDK's gcc, but I will definitely recompile it again with latest adtools

@everyone
thanks for suggestions, I wouldn't figure it out without You :)

I will keep You informed

Is anyone willing to help me with debugging?
Since this is my first project, I'm not so experienced with this stuff so it could help to speed it up a lot.

Feel free to send me pm or by email if interested, thanks :)

@NoCache

Quote:

The SDK included gcc is version 4.2.4, so is quite ancient and doesn't have the builtin swap functions.

What is the correct way for memory allocation?
I'm sorry if it was already discussed in some other thread, I just can't find proper answer..
I'm not 100% sure how it works but I will try to describe my concern
Lets say I need to open a file, so I will allocate needed memory size with malloc function and load the file into the memory. Now I need to decode the content in memory so I need to use some operations like swap some bytes etc.
Is it OK to use malloc operation for this purpose regarding memory protection or should AllocVecTags() be used instead?
Devilution goes to GR in following function, I'm trying to understand what is going on and memory protection comes to my mind as possible issue


Thanks

Looks nice... Well done.

Nice

@NoCache

Looks good. Well done.

When will we try it?

Virginio

@RIBDEVIL

Now it mainly depends on how fast I will be able to resolve Run-Length Encoding (RLE) on big-endian platform...

Anyone worked with that already on some project? :)

@NoCache
Not about RLE, but just before you meet with some strange random crashes on running of some port or somewhere in the gameplay:

Many games/code use stack for some things (trivial but need to be said), and usually size of default stack size on amigaos4 is too low for. And results of low stack size are crashes on some parts which should't crashes.

So, to avoid setting all the time stack size in the shell, or in the icon, there is some variable called "stack cookie", which you set in the code (i usually put it right before main(){} ), and i usually set 1000000 (1 megabyte) for any game port to avoid any possible problems , and then doens't matter if user run it from shell, or from icon: stack cookie which set in code will always have priority, and 1megabyte of stack size can cover all the needs of almost all the ports i meet with. If i remember right the only time when i set 2megabyte of stack size was Odyssey. So, to set stack cookie there is code:



It is the same necessary as to deal with pathes and endianes. Most of time you will forget about it as about something trivial, and then users will start reporting that everything crashes there or there. So stack cookie are must all the time if you do not want to have problems :) Some time of course you will be lucky, and port will have no problems with stack (and that low one which is default on amigaos4 will be enough), but other times you will be out of luck

@kas1e

I believe the default stack size on Windows is 1MB. I had to bump this up recently on a project I was working on... so matching that on this port makes sense.

@kas1e

ah, I didn't know about that at all, so really good to know...
I will also make a note for future projects :)
thanks

By the way, encoding is resolved, it is going forward slowly, but there is at least some progress :)

@NoCache
Im already downloading diablo1 CD and hope to test your port soon :)

ps. did you have plans to add your aos4/endian changes to their repo ?

@kas1e
Another reason to finish this up :)

I'm in touch with DevilutionX developers, there want to support big endian platforms, so yes, I will upload my changes later on.
They also made jokes that that will have AmigaOS port done faster than Apple's :)

Looks like a fun game and i m eager to play it asap when its ready.

@NoCache
Do not know how far you come with your Diablo port, but some one with name "artur" did the port to vampire(68k), so all byteswapping and endian-related work probabaly or already done, or almost done.

Code are open, changes too, there is:
https://github.com/AmigaPorts/devilutionX/commits/master

I can of coure build os4 version myself from it, if it ready-enough, and all endian-related work done, but probabaly if you in interst to finish your first project, it will be fair that you will do so. But if you didn't want to spend much time on it anymore, i can port what arthur do.