Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
57 user(s) are online (38 user(s) are browsing Forums)

Members: 0
Guests: 57

more...

Headlines

 
  Register To Post  

(1) 2 3 4 ... 7 »
DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
Hello friends!

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

Resized Image


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

Go to top
Re: DevilutionX - Diablo 1
Home away from home
Home away from home


See User information
@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

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: DevilutionX - Diablo 1
Quite a regular
Quite a regular


See User information
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)

Go to top
Re: DevilutionX - Diablo 1
Home away from home
Home away from home


See User information
@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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
@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

Go to top
Re: DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
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 :)

Go to top
Re: DevilutionX - Diablo 1
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
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 *pDecodeTochar *pRLEBytesint dwRLESizeint 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 ( 
)
                {
                    
v7 static_cast<unsigned char>(*v4++);
                    if ( (
v7 0x80u) == )
                        break;
                    
_LOBYTE(v7) = -(char)v7;
                    
v5 += v7;
                    
v6 -= v7;
                    if ( !
v6 )
                        goto 
LABEL_14;
                }
                
v6 -= v7;
                
v8 v7 >> 1;
                if ( 
v7 )
                {
                    *
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(v5v4v10);
                
v4 += v10;
                
v5 += v10;
            }
            while ( 
v6 );
LABEL_14:
            
v5 += -dwRLEWdt 768;
        }
        while ( &
v11[dwRLESize] != v4 );
    }
}


Thanks

Go to top
Re: DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
Resized Image

Go to top
Re: DevilutionX - Diablo 1
Site Builder
Site Builder


See User information
Looks nice... Well done.

Go to top
Re: DevilutionX - Diablo 1
Quite a regular
Quite a regular


See User information
Nice

AmigaOne X5000
Radeon HD 7700
Go to top
Re: DevilutionX - Diablo 1
Not too shy to talk
Not too shy to talk


See User information
@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
Go to top
Re: DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
@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? :)

Go to top
Re: DevilutionX - Diablo 1
Home away from home
Home away from home


See User information
@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

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
@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.

Go to top
Re: DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
@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 :)

Go to top
Re: DevilutionX - Diablo 1
Home away from home
Home away from home


See User information
@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 ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: DevilutionX - Diablo 1
Just popping in
Just popping in


See User information
@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 :)

Go to top
Re: DevilutionX - Diablo 1
Quite a regular
Quite a regular


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

AmigaOne X5000
Radeon HD 7700
Go to top
Re: DevilutionX - Diablo 1
Home away from home
Home away from home


See User information
@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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
(1) 2 3 4 ... 7 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project