SDLPoP; David's open-source port of PoP
Re: David's open-source port of PoP (pre-release)
Yes, 64-bit.
Bit more information on the segmentation fault:
- - - - -
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000040b9a2 in load_from_opendats_metadata (resource_id=1001,
extension=0x41b2b5 "png", out_fp=0x7fff86a1a320, result=0x7fff86a1a318,
checksum=0x7fff86a1a317 "", size=0x7fff86a1a31c) at seg009.c:1268
1268 for (i = 0; i < dat_table->res_count; ++i) {
- - - - -
- - - - -
#0 0x000000000040b9a2 in load_from_opendats_metadata (resource_id=1001,
extension=0x41b2b5 "png", out_fp=0x7fff86a1a320, result=0x7fff86a1a318,
checksum=0x7fff86a1a317 "", size=0x7fff86a1a31c) at seg009.c:1268
#1 0x000000000040bc62 in load_from_opendats_alloc (resource=1001,
extension=0x41b2b5 "png", out_result=0x7fff86a1a358,
out_size=0x7fff86a1a35c) at seg009.c:1331
#2 0x000000000040a12e in load_image (resource_id=1001, palette=0x7f4cf0038701)
at seg009.c:506
#3 0x0000000000409511 in load_sprites_from_file (resource=1000,
palette_bits=2, pack=0x0, shift=0) at seg009.c:216
#4 0x000000000040a4b1 in load_font () at seg009.c:667
#5 0x000000000040b6c7 in set_gr_mode (grmode=5 '\005') at seg009.c:1185
#6 0x000000000040f5a4 in parse_grmode () at seg000.c:992
#7 0x000000000040d82a in pop_main () at seg000.c:43
#8 0x000000000040176a in main (argc=1, argv=0x7fff86a1a5e8) at main.c:7
- - - - -
- - - - -
poll([{fd=4, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=4, revents=POLLIN|POLLOUT}])
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0i\0\3\0\240\7`\1\0\0\332\2562\33\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 224
writev(4, [{"<\2\2\0\0\0\240\7+\1\1\0", 12}, {NULL, 0}, {"", 0}], 3) = 12
poll([{fd=4, events=POLLIN}], 1, 4294967295) = 1 ([{fd=4, revents=POLLIN}])
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1k\0\0\0\0\0\16\0 \10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(4, 0x7fffc8176730, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, 0x7fffc8176730, 0) = -1 EAGAIN (Resource temporarily unavailable)
shutdown(4, SHUT_RDWR) = 0
close(4) = 0
futex(0x7f867d1769d0, FUTEX_WAIT, 13701, NULL) = 0
rt_sigaction(SIGSEGV, NULL, {0x7f8682a24650, [], SA_RESTORER, 0x7f868246d000}, 8) = 0
rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x7f868246d000}, NULL, 8) = 0
rt_sigaction(SIGBUS, NULL, {0x7f8682a24650, [], SA_RESTORER, 0x7f868246d000}, 8) = 0
rt_sigaction(SIGBUS, {SIG_DFL, [], SA_RESTORER, 0x7f868246d000}, NULL, 8) = 0
rt_sigaction(SIGFPE, NULL, {0x7f8682a24650, [], SA_RESTORER, 0x7f868246d000}, 8) = 0
rt_sigaction(SIGFPE, {SIG_DFL, [], SA_RESTORER, 0x7f868246d000}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {0x7f8682a24650, [], SA_RESTORER, 0x7f868246d000}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f868246d000}, NULL, 8) = 0
exit_group(1) = ?
+++ exited with 1 +++
- - - - -
Bit more information on the segmentation fault:
- - - - -
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000040b9a2 in load_from_opendats_metadata (resource_id=1001,
extension=0x41b2b5 "png", out_fp=0x7fff86a1a320, result=0x7fff86a1a318,
checksum=0x7fff86a1a317 "", size=0x7fff86a1a31c) at seg009.c:1268
1268 for (i = 0; i < dat_table->res_count; ++i) {
- - - - -
- - - - -
#0 0x000000000040b9a2 in load_from_opendats_metadata (resource_id=1001,
extension=0x41b2b5 "png", out_fp=0x7fff86a1a320, result=0x7fff86a1a318,
checksum=0x7fff86a1a317 "", size=0x7fff86a1a31c) at seg009.c:1268
#1 0x000000000040bc62 in load_from_opendats_alloc (resource=1001,
extension=0x41b2b5 "png", out_result=0x7fff86a1a358,
out_size=0x7fff86a1a35c) at seg009.c:1331
#2 0x000000000040a12e in load_image (resource_id=1001, palette=0x7f4cf0038701)
at seg009.c:506
#3 0x0000000000409511 in load_sprites_from_file (resource=1000,
palette_bits=2, pack=0x0, shift=0) at seg009.c:216
#4 0x000000000040a4b1 in load_font () at seg009.c:667
#5 0x000000000040b6c7 in set_gr_mode (grmode=5 '\005') at seg009.c:1185
#6 0x000000000040f5a4 in parse_grmode () at seg000.c:992
#7 0x000000000040d82a in pop_main () at seg000.c:43
#8 0x000000000040176a in main (argc=1, argv=0x7fff86a1a5e8) at main.c:7
- - - - -
- - - - -
poll([{fd=4, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=4, revents=POLLIN|POLLOUT}])
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0i\0\3\0\240\7`\1\0\0\332\2562\33\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 224
writev(4, [{"<\2\2\0\0\0\240\7+\1\1\0", 12}, {NULL, 0}, {"", 0}], 3) = 12
poll([{fd=4, events=POLLIN}], 1, 4294967295) = 1 ([{fd=4, revents=POLLIN}])
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1k\0\0\0\0\0\16\0 \10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(4, 0x7fffc8176730, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, 0x7fffc8176730, 0) = -1 EAGAIN (Resource temporarily unavailable)
shutdown(4, SHUT_RDWR) = 0
close(4) = 0
futex(0x7f867d1769d0, FUTEX_WAIT, 13701, NULL) = 0
rt_sigaction(SIGSEGV, NULL, {0x7f8682a24650, [], SA_RESTORER, 0x7f868246d000}, 8) = 0
rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x7f868246d000}, NULL, 8) = 0
rt_sigaction(SIGBUS, NULL, {0x7f8682a24650, [], SA_RESTORER, 0x7f868246d000}, 8) = 0
rt_sigaction(SIGBUS, {SIG_DFL, [], SA_RESTORER, 0x7f868246d000}, NULL, 8) = 0
rt_sigaction(SIGFPE, NULL, {0x7f8682a24650, [], SA_RESTORER, 0x7f868246d000}, 8) = 0
rt_sigaction(SIGFPE, {SIG_DFL, [], SA_RESTORER, 0x7f868246d000}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {0x7f8682a24650, [], SA_RESTORER, 0x7f868246d000}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f868246d000}, NULL, 8) = 0
exit_group(1) = ?
+++ exited with 1 +++
- - - - -
Re: David's open-source port of PoP (pre-release)
I attached a new types.h. Replace the old one with this one and recompile the game. (Run "make clean" first.)
I replaced occurences of "short" and "long" with "Uint16" and "Uint32".
To be extra sure, I also added some compile time asserts about the sizes of all types that are used in the DAT files.
If you get any errors (either compile-time or run-time), please tell me.
If the game seems to work correctly with this, I'll do a new release that includes this file.
I replaced occurences of "short" and "long" with "Uint16" and "Uint32".
To be extra sure, I also added some compile time asserts about the sizes of all types that are used in the DAT files.
If you get any errors (either compile-time or run-time), please tell me.
If the game seems to work correctly with this, I'll do a new release that includes this file.
- Attachments
-
- types.h
- (8.94 KiB) Downloaded 165 times
Re: David's open-source port of PoP (pre-release)
That types.h fixes the problem, it works now.
Re: David's open-source port of PoP (pre-release)
Good. Thanks for finding the bug.Norbert wrote:That types.h fixes the problem, it works now.
Here is the new version.
The only change is that it's compatible with 64-bit.
Note that this counts only if you're (re)compiling it yourself and you're using DAT files.
(That's why Eugene didn't run into crashes -- yet.)
- Attachments
-
- PORT_PoP_v1.04.zip
- (894.82 KiB) Downloaded 146 times
Re: David's open-source port of PoP (pre-release)
Readme.txt says "Name of program: David's open-source port of PoP".
Maybe it can also have an abbreviated name, similar to how Prince of Persia 1 is referred to as PoP1. "David's Open-Source" is DOS, as the operating system, which might be usable. "Port of PoP" is a recursive acronym, which might also be usable. The most obvious abbreviated name would be DOSPoP.
Maybe throw in another letter so it's clear it's not just PoP for DOS, like DOSNPoP (where N is Native, as in, a native port, if that's indeed what it is; I think so). Googling DOSNPoP gives 1 hit, so it would be very easy to find mentions of the conversion in the future. Makes me think of the Pinball Fantasies table Stones 'n Bones.
Or maybe PoPPED (or popped or Popped), short and snappy. Prince of Persia Port E... David/DOS, maybe "port emulation", but there must be something better, like a synonym for "by" (by David). Or maybe Poppy (or PoPPY), like the flowering plant, which also has the extra p for Port, just like Poppa. Others that I believe are free in the PoP context are popsicle (c for Conversion), lollipop and popular, but what to do with them.
Just some ideas. To me "David's open-source port of PoP" feels more like a description than a name.
Maybe it can also have an abbreviated name, similar to how Prince of Persia 1 is referred to as PoP1. "David's Open-Source" is DOS, as the operating system, which might be usable. "Port of PoP" is a recursive acronym, which might also be usable. The most obvious abbreviated name would be DOSPoP.
Maybe throw in another letter so it's clear it's not just PoP for DOS, like DOSNPoP (where N is Native, as in, a native port, if that's indeed what it is; I think so). Googling DOSNPoP gives 1 hit, so it would be very easy to find mentions of the conversion in the future. Makes me think of the Pinball Fantasies table Stones 'n Bones.
Or maybe PoPPED (or popped or Popped), short and snappy. Prince of Persia Port E... David/DOS, maybe "port emulation", but there must be something better, like a synonym for "by" (by David). Or maybe Poppy (or PoPPY), like the flowering plant, which also has the extra p for Port, just like Poppa. Others that I believe are free in the PoP context are popsicle (c for Conversion), lollipop and popular, but what to do with them.
Just some ideas. To me "David's open-source port of PoP" feels more like a description than a name.
Re: David's open-source port of PoP (pre-release)
Hello, fellows!
I compiled v1.04 in Centos 7 64-bit
Game is working correctly.
And, I deleted the library "SDLmain" in Makefile.
Now in my makefile:
If "SDLmain" is presented in makefile - gcc not finds this library.
And assembly process fails.
I compiled v1.04 in Centos 7 64-bit
Game is working correctly.
And, I deleted the library "SDLmain" in Makefile.
Now in my makefile:
Code: Select all
#LIBS = -l"SDLmain" -l"SDL" -l"SDL_image"
LIBS = -l"SDL" -l"SDL_image"
And assembly process fails.
Re: David's open-source port of PoP (pre-release)
Okay. Under Linux that doesn't work, at least not for me. I've recently implemented fullscreen support for apoplexy (not yet released), which uses SDL2, and it does work there. I think SDL2 has some improvements in this department, including SDL_WINDOW_FULLSCREEN_DESKTOP which doesn't change the videomode, allowing for Alt+Tab to be used and it doesn't grab the mouse by default. The Migration Guide also mentions in its overview of new features "Better fullscreen support".Andrew wrote:If I'm understanding your question correctly, yes, "prince.exe full" in this case does scale the image up instead of displaying the game as a small graphic in the middle of the screen.Norbert wrote:Already a short question, out of curiosity: in one of the text files you wrote "# stretch image to 2x, 3x (you can use fullscreen instead)"; does SDL_FULLSCREEN actually scale up the images under Windows?
One of the compiler warnings I'm curious about is "overflow in implicit constant conversion", for, for example, line 164 in seg006.c. Any ideas?
Re: David's open-source port of PoP (pre-release)
When I was playing Lost In The Forest I, I noticed that some of the sword sprites are drawn without mask (as in their transparent areas are being drawn in cyan).
- Attachments
-
- A screenshot of the bug
- bug.png (31.18 KiB) Viewed 6131 times
-- Michael, the boy who makes Shaw's Nightmare.
Visit here to download Shaw's Nightmare: http://shawsnightmare.ucoz.com
Visit here to download Shaw's Nightmare: http://shawsnightmare.ucoz.com
-
- Calif
- Posts: 553
- Joined: August 27th, 2011, 2:04 am
Re: David's open-source port of PoP (pre-release)
How to use those graphics in this port, youre using custom mod???musa wrote:When I was playing Lost In The Forest I, I noticed that some of the sword sprites are drawn without mask (as in their transparent areas are being drawn in cyan).
Check my Prince in C# https://github.com/salvadorc17/Prince-Monogame
Re: David's open-source port of PoP (pre-release)
Hopefully musa doesn't mind me answering your question.salvadorc17 wrote:How to use those graphics in this port, youre using custom mod???musa wrote:When I was playing Lost In The Forest I, I noticed that some of the sword sprites are drawn without mask (as in their transparent areas are being drawn in cyan).
Yes, Lost In The Forest uses custom graphics.
The graphics you saw in the screenshot are dungeon graphics called "SNES Level 8".
Custom dungeon and palace graphics can be downloaded here:
- Dungeon: http://www.popot.org/custom_levels.php? ... UNGEON.DAT
- Palace: http://www.popot.org/custom_levels.php? ... PALACE.DAT
You simply download the DAT file and copy it into the PORT_PoP/ directory.
Then play the game and you'll see custom graphics.
If you'd want to create custom graphics yourself, you can edit the images that are in the directories you find in PORT_PoP/data/.
For example, edit PORT_PoP/data/TITLE.DAT/res51.png to change the background image you see during the intro.
(There's room for improvement when it comes to the names of the PNG files. PR compatibility would be convenient.)
Re: David's open-source port of PoP (pre-release)
I looked into this, which might save David a tiny amount of time.musa wrote:When I was playing Lost In The Forest I, I noticed that some of the sword sprites are drawn without mask (as in their transparent areas are being drawn in cyan).
In Lost In The Forest, the PRINCE.DAT is LOSTFR.DAT.
The fighting/sword31.bmp inside that DAT file is (a horizontally flipped version of) the sword in the screenshot.
In the original image for that sword, the background color is 0x000000, the first color of the indexed palette.
However, the game ignores that palette and uses the first color of sword.pal, which is also black (0 0 0).
In the custom image of Lost In The Forest, the background color is 0x00fcfc, the first color of the indexed palette.
I'm guessing this is what David's conversion is using.
Does this mean that that color in the image palette is different from the first color of sword.pal, since the original game doesn't show a cyan background?
Surprisingly (to some; I've gotten used to it ) it is not: the first color in the PAL file is also cyan (0 252 252).
The reason the original game still shows the sword properly is that not only the PAL overrides the image palette, but the game itself overrides the first color of the PAL file. This is the - as I called it "tricky to explain" - #3 in my list of problems authors can run into when customizing the DAT files.
What does all this mean in normal English?
It means David's conversion does not yet replicate the original game's behavior when it comes to overriding certain PAL colors. It either uses the image background or the PAL color, both of which are set to cyan in your mod. (Why are they set to cyan? I don't know.)
Does David's conversion override image colors with PAL colors (one step back in the override list)? I don't know, but I'm sure David knows. It's not very difficult to change a PAL file and check.
Re: David's open-source port of PoP (pre-release)
By the way, note that this only works if you do not use (custom) DAT files in the main PORT_PoP/ directory.Norbert wrote:If you'd want to create custom graphics yourself, you can edit the images that are in the directories you find in PORT_PoP/data/.
For example, edit PORT_PoP/data/TITLE.DAT/res51.png to change the background image you see during the intro.
Just start with the default package that David created, or remove DAT files from PORT_PoP/ if you added these there.
Re: David's open-source port of PoP (pre-release)
So many questions to answer...
@fullscreen: Somehow SDL uses 640*480 instead of the 320*200 that I ask.
Does this mean that I should convert to SDL2? (Or at least *allow* using SDL2?)
@overflow: That part is the frame table.
Some fields are declared as a "sbyte" (signed byte, -128..127) -- namely the last three. (See frame_type in types.h .)
If those fields are given values like 0xFE (254), that does not fit into a sbyte, so the compiler does an automatic converson -- 0xFE will become -2. (As a two's complement signed number.)
I just copied that table out from the disassembly.
@transparency:
My version sets black as a color key when doing transparent draws. (See method_6_blit_img_to_scr() in seg009.c .)
But it seems that instead I should use color 0 in the palette.
I tried this on level 2 of that mod.
Hey... This seems to fix itself when the guard turns left. That is, when the image is drawn *without* flipping.
So the game *does* set color 0 as color key, but not when loading, only when drawing (but not before flipping).
I now added setting of the colorkey into load_image() and hflip().
What I don't know is what to do with the alpha channel of PNG images.
Currently the game sets color 0 as color key for those as well, and no alpha-blending is done.
It seems that "color 0" means color index 0 for indexed images, black for 24-bit images, and transparent black for 32-bit images.
Update: Now I made the output in hflip() the same format as the input.
And I also made possible to use semi-transparency while keeping compatibility.
I will upload the new version later.
Only PR adds the palettes to images, because indexed BMP images must contain the palette.
And upon importing, the palette of the BMP is just ignored.
@fullscreen: Somehow SDL uses 640*480 instead of the 320*200 that I ask.
Does this mean that I should convert to SDL2? (Or at least *allow* using SDL2?)
@overflow: That part is the frame table.
Some fields are declared as a "sbyte" (signed byte, -128..127) -- namely the last three. (See frame_type in types.h .)
If those fields are given values like 0xFE (254), that does not fit into a sbyte, so the compiler does an automatic converson -- 0xFE will become -2. (As a two's complement signed number.)
I just copied that table out from the disassembly.
@transparency:
My version sets black as a color key when doing transparent draws. (See method_6_blit_img_to_scr() in seg009.c .)
But it seems that instead I should use color 0 in the palette.
I tried this on level 2 of that mod.
Hey... This seems to fix itself when the guard turns left. That is, when the image is drawn *without* flipping.
So the game *does* set color 0 as color key, but not when loading, only when drawing (but not before flipping).
I now added setting of the colorkey into load_image() and hflip().
What I don't know is what to do with the alpha channel of PNG images.
Currently the game sets color 0 as color key for those as well, and no alpha-blending is done.
It seems that "color 0" means color index 0 for indexed images, black for 24-bit images, and transparent black for 32-bit images.
Update: Now I made the output in hflip() the same format as the input.
And I also made possible to use semi-transparency while keeping compatibility.
I will upload the new version later.
Norbert wrote:Does this mean that that color in the image palette is different from the first color of sword.pal, [...]?
In the DAT files, images themselves don't have palettes, only the "standalone" (.pal) palettes exist.Norbert at [url]http://forum.princed.org/viewtopic.php?p=15043#p15043[/url] wrote:[...] because the game ignores the palettes of images inside DAT files.
Only PR adds the palettes to images, because indexed BMP images must contain the palette.
And upon importing, the palette of the BMP is just ignored.
And PV.DAT is PW.DAT, VIZIER.DAT is WOLFST.DAT.In Lost In The Forest, the PRINCE.DAT is LOSTFR.DAT.
-
- Calif
- Posts: 553
- Joined: August 27th, 2011, 2:04 am
Re: David's open-source port of PoP (pre-release)
I do not make my questions for you, but thanks for the big answer, it gives me good information...
Check my Prince in C# https://github.com/salvadorc17/Prince-Monogame
Re: David's open-source port of PoP (pre-release)
Migrating is an investment of time and energy, so it could be shelved for now, but SDL2 is superior in many ways.David wrote:@fullscreen: Somehow SDL uses 640*480 instead of the 320*200 that I ask.
Does this mean that I should convert to SDL2? (Or at least *allow* using SDL2?)
The new Game Controller API and better fullscreen support will come in handy.
(PS: I don't understand what you mean by 640x480, for me it's just 320x200 and fullscreen doesn't scale up.)