Who's Online |
58 user(s) are online ( 34 user(s) are browsing Forums)
Members: 0
Guests: 58
more...
|
|
|
|
DevilutionX - Diablo 1
|
Posted on: 2019/2/2 21:53
#1
|
Just popping in 
Joined: 2018/12/16 8:42 Last Login
: 2019/9/15 5:46
From Czech Republic
Group:
Registered Users
|
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:
// This function gets the right positions of the hash table and the block table.
static int VerifyMpqTablePositions(TMPQArchive * ha, ULONGLONG FileSize)
{
TMPQHeader * pHeader = ha->pHeader;
ULONGLONG ByteOffset;
// Check the begin of HET table
if(pHeader->HetTablePos64)
{
ByteOffset = ha->MpqPos + pHeader->HetTablePos64;
if(ByteOffset > FileSize)
{
printf("HET table error\n");
return ERROR_BAD_FORMAT;
}
}
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
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/3 1:54
#2
|
Home away from home 
Joined: 2007/1/26 21:48 Last Login
: 6/23 11:02
From New Zealand
Group:
Registered Users
|
@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
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/3 13:35
#3
|
Quite a regular 
Joined: 2007/2/27 10:47 Last Login
: 6/15 20:18
From Gravity well
Group:
Registered Users
|
I think it's unlikely your data files are corrupt. gcc 5.3.0 et al is here.
http://os4depot.net/index.php?function=showfile&file=development/misc/adtools.lha
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)
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/3 13:41
#4
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@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:
#define SDL_SwapLE16(X) (X)
#define SDL_SwapLE32(X) (X)
#define SDL_SwapLE64(X) (X)
#define SDL_SwapBE16(X) SDL_Swap16(X)
#define SDL_SwapBE32(X) SDL_Swap32(X)
#define SDL_SwapBE64(X) SDL_Swap64(X)
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.
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/3 18:21
#5
|
Just popping in 
Joined: 2018/12/16 8:42 Last Login
: 2019/9/15 5:46
From Czech Republic
Group:
Registered Users
|
@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
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/6 9:59
#6
|
Just popping in 
Joined: 2018/12/16 8:42 Last Login
: 2019/9/15 5:46
From Czech Republic
Group:
Registered Users
|
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 :)
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/6 12:09
#7
|
Just can't stay away 
Joined: 2006/11/30 11:30 Last Login
: Yesterday 18:12
From Finland
Group:
Registered Users
|
@NoCache Quote: @kas1e, @thematic I used default SDK's gcc, but I will definitely recompile it again with latest adtools
The SDK included gcc is version 4.2.4, so is quite ancient and doesn't have the builtin swap functions.
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/11 21:50
#8
|
Just popping in 
Joined: 2018/12/16 8:42 Last Login
: 2019/9/15 5:46
From Czech Republic
Group:
Registered Users
|
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
void __fastcall CelDrawDatOnly(char *pDecodeTo, char *pRLEBytes, int dwRLESize, int dwRLEWdt)
{
char *v4; // esi
char *v5; // edi
int v6; // edx
unsigned int v7; // eax
unsigned int v8; // ecx
char v9; // cf
unsigned int v10; // ecx
char *v11; // [esp+4h] [ebp-8h]
v11 = pRLEBytes;
if ( pDecodeTo && pRLEBytes )
{
v4 = pRLEBytes;
v5 = pDecodeTo;
do
{
v6 = dwRLEWdt;
do
{
while ( 1 )
{
v7 = static_cast<unsigned char>(*v4++);
if ( (v7 & 0x80u) == 0 )
break;
_LOBYTE(v7) = -(char)v7;
v5 += v7;
v6 -= v7;
if ( !v6 )
goto LABEL_14;
}
v6 -= v7;
v8 = v7 >> 1;
if ( v7 & 1 )
{
*v5++ = *v4++; ///<<<<<<<<<<<<<< Grim Reaper
if ( !v8 )
continue;
}
v9 = v8 & 1;
v10 = v7 >> 2;
if ( v9 )
{
*(_WORD *)v5 = *(_WORD *)v4;
v4 += 2;
v5 += 2;
if ( !v10 )
continue;
}
qmemcpy(v5, v4, 4 * v10);
v4 += 4 * v10;
v5 += 4 * v10;
}
while ( v6 );
LABEL_14:
v5 += -dwRLEWdt - 768;
}
while ( &v11[dwRLESize] != v4 );
}
}
Thanks
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/15 21:29
#9
|
Just popping in 
Joined: 2018/12/16 8:42 Last Login
: 2019/9/15 5:46
From Czech Republic
Group:
Registered Users
|
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/15 22:21
#10
|
Site Builder 
Joined: 2006/12/2 23:57 Last Login
: Yesterday 14:09
From Athens/Dublin
Group:
Staff members Webmasters
|
Looks nice... Well done.
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/16 6:22
#11
|
Quite a regular 
Joined: 2008/10/29 10:20 Last Login
: 5/14 15:53
From Uppsala, Sweden
Group:
Registered Users
|
Nice
|
AmigaOne X5000 Radeon HD 7700
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/16 11:55
#12
|
Not too shy to talk 
Joined: 2010/1/22 20:03 Last Login
: 2019/4/16 21:09
From VIGO SPAIN
Group:
Registered Users
|
@NoCache
Looks good. Well done.
When will we try it?
Virginio
|
AmigaOne X5000 OS4.1 FEU1 And Lubuntu 10.04  1200 towered with Blizzard PPC - BVision and Mediator And a new fantastic Chameleon64
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/16 12:09
#13
|
Just popping in 
Joined: 2018/12/16 8:42 Last Login
: 2019/9/15 5:46
From Czech Republic
Group:
Registered Users
|
@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? :)
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/16 12:21
#14
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@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:
#ifdef __amigaos4__
static const char* __attribute__((used)) stackcookie = "$STACK: 1000000";
#endif
main() {....}
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
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/17 2:53
#15
|
Just popping in 
Joined: 2006/12/5 2:30 Last Login
: 2021/1/25 9:02
From Vancouver, Canada
Group:
Registered Users
|
@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.
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/18 7:27
#16
|
Just popping in 
Joined: 2018/12/16 8:42 Last Login
: 2019/9/15 5:46
From Czech Republic
Group:
Registered Users
|
@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 :)
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/18 8:05
#17
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@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 ?
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/18 9:19
#18
|
Just popping in 
Joined: 2018/12/16 8:42 Last Login
: 2019/9/15 5:46
From Czech Republic
Group:
Registered Users
|
@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 :)
|
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/2/20 17:17
#19
|
Quite a regular 
Joined: 2008/10/29 10:20 Last Login
: 5/14 15:53
From Uppsala, Sweden
Group:
Registered Users
|
Looks like a fun game and i m eager to play it asap when its ready.
|
AmigaOne X5000 Radeon HD 7700
|
|
|
Re: DevilutionX - Diablo 1
|
Posted on: 2019/8/18 10:35
#20
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@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/masterI 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.
|
|
|
Currently Active Users Viewing This Thread:
1
(
0 members
and 1 Anonymous Users
)
|
|
|