SDLPoP; David's open-source port of PoP

[StaticReturn]

I trust me, but you shouldn't until I've earned that trust.

Now that's something that we don't hear often.

Well, it's a bit of a conundrum. There will be some people who want to play SDL Prince on their Macs but who will not be able to compile their own binary. So by giving them a binary to execute on their own computers I'm providing positive reenforcement for a bad habit, which is running programs from random internet sources. I hope to mitigate a little bit of the damage by reminding them to be cautious at all times, even here.

-SR

[StaticReturn]

David, on your path to disassembling the original prince.exe, what method did you use to unpack the executable? Some analytical programs I have are reporting that it is packed with EXEPACK v4.06. I've used two different unpackers to rebuild the EXE, but the result crashes when I try to run it.

-SR

[David]

what method did you use to unpack the executable?

I used UPackExe from here: http://www.popot.org/other_useful_tools ... ack_unpack

[StaticReturn]

Thank you for the information, but it seems my problem persists. I've got WinXP running in VirtualBox. When I run an unmodified prince.exe, PoP starts normally. If I try to unpack the exe and drop it in as a replacement, the new exe crashes on execute. Shouldn't the unpacked exe be the same as the packed version? (except, you know, the compression)

-SR

EDIT: Sorry, I'll try to stay on-topic of the thread.

[David]

(Maybe these posts should be moved to a new topic?)

So you're running PoP without DOSBox?
You should use DOSBox because it can run programs better than the built-in DOS emulation of Windows.
(Or you could install a real DOS inside VirtualBox.)
Without DOSBox, the unpacked exe crashes for me as well with an NTVDM error.
The packed (original) exe causes a Blue Screen Of Death(!) saying the error occurred in nv4_disp.dll (NVIDIA Windows XP Display driver, Version 307.83).

[StaticReturn]

The static prince binary I posted wasn't so static. It was still dynamically linked to a bunch of X11 libraries. I've created a new static binary for OS X, but I've noticed there's a crash bug on OS X that makes it useless. How I get the crash: Starting from the First Room -> Down Room -> Right Room -> CRASH! @ seg009.c: 499:: SDL_SetColors(image, colors, 0, 16); Loading that first guard is deadly.

I'm not sure why it is crashing. Does anyone have any ideas...?

-SR

[David]

Does this happen only with your newest binary, or with all OS X binaries of this game?
The first case would be strange, because all binaries should use the same libraries.

seg009.c: 499:: SDL_SetColors(image, colors, 0, 16);

That line is in decode_image(). It is called when an image is loaded from a DAT file.
But when you see the level, the loading is already done. If you're not using DAT files, then that line is not executed at all.

Loading that first guard is deadly.

Does it happen with other guards?

SDL_SetColors() is also called from set_chtab_palette(), and that is called from redraw_screen() to set the guard's colors.
Based on your steps to reproduce, this is a more likely crasher.
This function may quit the program if SDL_SetColors() returns something other than 1. (*)
In this case it also writes an error message to the console. Do you see such an error message? (It starts with "SDL_SetColors: ")
If you see it please post it here.

(*) According to the documentation (http://www.libsdl.org/release/SDL-1.2.1 ... olors.html), this may happen "If surface is not a palettized surface", that is, if the guard's image is not paletted; or "If not all the color entries were set exactly as given", I don't know how can this happen.

[StaticReturn]

Does this happen only with your newest binary, or with all OS X binaries of this game?

Using SDLPoP v1.10, I tried dynamically linking vs the SDL framework & the standard unix-style libraries and also statically linking. I also tried once on SDLPoP v1.09 and everything produced the same crash. On the first two occurrences of the crash I was playing normally, first retrieving the sword before coming back to fight that first guard.

That line is in decode_image().

Oops, my bad. It's actually in the same file on line 2345. I put in some debug fprintf statements and got confused.

Does it happen with other guards?

It happens with the other "hidden" guard in the level.

SDL_SetColors() is also called from set_chtab_palette()

Yeah... my bad. That's where the problem is. It doesn't make your life any easier if I don't properly report the problem. Please excuse me. Upon further investigation (since now I'm looking in the right place), SDL_SetColors returns 0, i == 0, n_colors==16, and it seems like colors == 0. That's probably the problem... OS X is probably not reading some image data correctly. I'll look at it more later.

-SR

[David]

Try removing the "quit(1);" statement. Then the game won't quit and you'll see if the guard's palette was really not set.
Also, do you get an error message starting with "SDL_SetColors: "? It should be displayed by sdlperror().

and it seems like colors == 0

Do you mean the "byte* colors" parameter?
If it was NULL, then the first loop would have caused a SIGSEGV. (At the *colors << 2 part.)

[StaticReturn]

I've got this to check the values:

Code: Select all

 get = SDL_SetColors(chtab->pointers[i], scolors, 0, n_colors);
 if ( get != 1 ) {
    if( colors == NULL ) fprintf( stderr, "NULL!! " );
    fprintf( stderr, "i=%d, n_colors=%d, colors=%d, colors=%s, get=%d\n", i, n_colors, *colors, colors, get );
    sdlperror("SDL_SetColors");
    quit(1);
}

The first result: "i=0, n_colors=16, colors=0, colors=, get=0" (i goes from 0 to 33). When I comment out quit(1); then the guard loads in gray scale, but everything else seems ok.

-SR

[David]

Note that "colors" is not a single byte or a zero-terminated string.
It points to an array of 3*n_colors bytes at the beginning, and the first loop advances "colors" through this array.

When I comment out quit(1); then the guard loads in gray scale, but everything else seems ok.

Yes, the images in data/GUARD.DAT/ are greyscale paletted images, and they should be colored by SDL_SetColors().
Maybe they are loaded as RGB images and this is why SDL_SetColors() can't set their palette?
Does sdlperror() print any error message? (You might want to replace "printf(" with "fprintf(stderr," in sdlperror() at the top of seg009.c.)

Try copying a GUARD.DAT file to the folder where the binary is. (Maybe you also need GUARD1.DAT and GUARD2.DAT.)
(With all-uppercase filenames if your filesystem is case-sensitive.)
decode_image() decodes images from DAT files into paletted images, so if the image format is causing the problem, then this should fix it.

[Falcury]

It's been a while since I've been around, but I have to say, this is really fantastic.
I'd love to contribute if I can. Would it be an idea to set up a GitHub or BitBucket repository for the project?

[StaticReturn]

Does sdlperror() print any error message? (You might want to replace "printf(" with "fprintf(stderr," in sdlperror() at the top of seg009.c.)

Did that. No errors were reported. OS X's default installation (which I have) is a non case-sensitive filesystem.

When loading from your unpacked .DAT folders
• When I copy G*.DATA into the my working directory of SDLPoP, that solves the palette issue.
• load_from_opendats_metadata():: At about line 1490, just above the fp = NULL; I put in some debugging code which printed "i=62, res_count=62".

When loading from a folder with only .DAT Files
• I get the message "Can't load sprites from resource 1000."
• After line 1493 ("// If it's a directory:") I put the following debug statement: "fprintf( stderr, "%s, %lu, %s, %d, %s\n", image_filename, sizeof(image_filename), pointer->filename, resource_id, extension );". The results are in the attached file.
• open_dat() tries to open a file named "font", then before the next call to open_dat(), load_from_opendats_metadata() gets a call to open a filename called "data/font/res1000.pal".

[David]

Did that. No errors were reported.

Wait. Did it at least print the text "SDL_SetColors" when you had the problem?
I have seen cases when the actual error message (as returned by SDL_GetError()) was an empty string. (But that happened with SDL_RemoveTimer().)
If this is the case then it should print a line containing only "SDL_SetColors: " and nothing else. Did that appear?

Maybe they are loaded as RGB images and this is why SDL_SetColors() can't set their palette?

This could be checked by inserting the following statement, just before sdlperror("SDL_SetColors");

Code: Select all

fprintf(stderr, "i=%d, BitsPerPixel=%d, palette=%p\n", i, chtab->pointers[i]->format->BitsPerPixel, chtab->pointers[i]->format->palette);

Please try that and show me what does it output. (Go to the guard and make sure it does not have the correct colors.)
(If you have the GUARD.DAT file in the folder, delete or rename it. I want to see what happens if the PNG images are used.)

• When I copy G*.DATA into the my working directory of SDLPoP, that solves the palette issue.

Right, so we found a solution (or workaround).

• load_from_opendats_metadata():: At about line 1490, just above the fp = NULL; I put in some debugging code which printed "i=62, res_count=62".

62 is the number of resources in PRINCE.DAT (the file, not the folder).
That part is executed when a resource is not found in a DAT file. (But it might exist in another DAT file.)

When loading from a folder with only .DAT Files
• I get the message "Can't load sprites from resource 1000."

I think you deleted the data/font folder. You shouldn't delete it, it is needed for displaying text.
(I think I should add a default font inside the exe, as the original PoP does it. So SDLPoP would start without data/font.)

• After line 1493 ("// If it's a directory:") I put the following debug statement: "fprintf( stderr, "%s, %lu, %s, %d, %s\n", image_filename, sizeof(image_filename), pointer->filename, resource_id, extension );". The results are in the attached file.

Did you get this at the same time as you got the error "Can't load sprites from resource 1000."?
Because in with.txt, I see that the font images 1032..1131 *could* be loaded, because these IDs are *not* searched in PRINCE.DAT. But 1001..1031 and 1132..1255 are searched in PRINCE.DAT.
(SDLPoP searches each ID in all currently open DAT files until it finds it. When the font is loaded, "font" and "PRINCE.DAT" are open.
So it first searches in "font", and if it's not there, it searches in "PRINCE.DAT".)

• open_dat() tries to open a file named "font", then before the next call to open_dat(), load_from_opendats_metadata() gets a call to open a filename called "data/font/res1000.pal".

This is just SDLPoP trying to find its font.

[StaticReturn]

Yes, I get one report of "SDL_SetColors:" and when I comment out the following quit(1); I get 34 sets of "SDL_SetColors:". Sorry for not responding to that question.

The result of your debug statement prints out 34 cases of the following, with "i" going from 0 to 33.

Code: Select all

i=0, BitsPerPixel=32, palette=0x0
SDL_SetColors: 

I think I should add a default font inside the exe, as the original PoP does it. So SDLPoP would start without data/font.

My own personal vote would be to make the SDLPoP executable work as a drop-in replacement for PRINCE.EXE.

Did you get this at the same time as you got the error "Can't load sprites from resource 1000."?

No. It looks like another of my mistakes. I think that bullet point should have been under "When loading from your unpacked .DAT folders".

After copying the fonts over to the directory with only .DAT files everything runs well. My bad. :/