SDLDevil 0.5 released!
This sounds odd...

are you trying to open the .hog file with devil or to play a .rl2 file in dxx-rebirth?

If yes: You have to extract the .rl2 (or rdl for d1) file from an existing hog using the "mission manager" (File > mission manager) to open it in sdldevil and you need to create a hog with a corresponding rl2 file (using the mission manager) to play it in dxx-rebirth.
sdldevil (currently) does not support handling the .hog container format directly.
rl2 - I didnt try to use hog at all. Opening any rl2's didnt work, but I could make new level (rl2) but couldnt open it with rebirth which gave me - Error reading fix in PHYSFSX_readFiDead)
Another thing (probably nothing) sdl.dll library which comes with sdldevil is a way bigger than same version which I used (from sdl website) - switching between them doesn't change anything.

edit: I was able to compile 0.3 (or 0.4 dont remember) a while ago with the same setup but this one gives me hard time.
Is there some kind of error message when you try to load a rl2? Or does the program just crash?
Can you do the following please?
- create a new level, just the standard cube, do not do any changes.
- try to play it / ensure that it is not working
- send me the non-working rl2 file or upload it anywhere and post the link that I can download it.

What's your os? Windows? 32 or 64 bit?
What version of Dev-C++ are you using?

I'll try to build SDLDevil using DevC++ the next days and check if I can reproduce the behaviour.
Maybe I'll also do some work on SDLDevil again after > 1 year abstinence ... Smile

Sure thing Wink
...oh.. it also has the same behaviour after using Code::Blocks...tried with few compilers.
There is some possibility I messed up something during 'fixing headers' to make it even compile but ... can't find it
Win 32 bit
Orwell Dev-C++ 5.5.3
mission :

Devil doesn't crash it just says 'can't open the level'
(12-16-2013, 12:07 AM)v66r link Wrote:I'll try to build SDLDevil using DevC++ the next days and check if I can reproduce the behaviour.
Maybe I'll also do some work on SDLDevil again after > 1 year abstinence ... Smile



I have been waiting for you to come back for soooo long, There are bugs that have been, for lack of a better term, bugging me, and I lost your 0.6 beta build.... Man, if you get back into this, Ima be SOOO happy. You have no idea. I almost lost hope that you were even going to come back to descent.
The levels your version contains 2 bytes of "garbage" - one between header and mine data and one between mine and game data.
You most likely removed the PACKED_ATTR from some of the structs? Without it the compiler aligns these structs to 32 bit. Unfortunately the saving routines save the complete struct and this way the bytes introduced by the compiler for alignment also get written to the file.

I already began rewriting the loading / saving stuff to get rid of aligned packed structs which also make alot of trouble on the ARM architecture where pointers need to be aligned to 32 bit, but I never finished that until now.

To verify this, it would be the best you post your modified structs.h - or you change it back to the original Wink
Sad I didn't make any changes in structs.h, I just compared it with fresh download.
OK, where did you make changes to get it compiled? And what did you change?
Relying on packed structures is a major problem in the core Descent code, too.  There was a bug related to loading resources that I tracked down to mingw32-gcc 4.7 and later not respecting the __packed attribute.  Other platforms and mingw32-gcc <4.7 were fine.  Adding -mno-ms-bitfields fixed the problem for >=4.7.

[Edit: the option is -mno-ms-bitfields, not -mms-bitfields as I originally said.  MS bitfields were enabled by default in 4.7, which was the cause of the problem.]
That's an interesting hint, thanks Kp.
I'll try to reproduce the problem with the compiler aqqman uses.

Forum Jump:

Users browsing this thread: 1 Guest(s)