SDLPoP; David's open-source port of PoP
Re: David's open-source port of PoP (pre-release)
Thanks for confirming guys. I know it's minor but hopefully David can figure out a fix.
Say, is it right to term an engine recreation using disassembled code a "port"?
Say, is it right to term an engine recreation using disassembled code a "port"?
Re: David's open-source port of PoP (pre-release)
About the black rectangles around the moving objects:
(Note that this happens with all kinds of flashing in the game, but it's more visible with bright flashes.)
The flash is done (in my version) by filling thew onscreen buffer with the color of the flash, and then drawing the offscreen buffer onto it. (see set_bg_attr() in seg009.c)
The problem is that the moving objects (drects) are drawn *after* this (non-transparently). One solution would be to change their order.
Flashing is called from two places:
1. play_level_2() in seg003.c (through flash_if_hurt())
2. proc_cutscene_frame() in seg001.c
Update: I moved the flashing after the redraws in both places. This seems to solve the problem.
Note: I had the opposite problem with guard colors: The images have to be recolored *before* they are drawn.
The DOS version has it easier: Just change the hardware palette registers, and the color changes *immediately* and *everywhere*.
Perhaps "conversion"?
(Note that this happens with all kinds of flashing in the game, but it's more visible with bright flashes.)
The flash is done (in my version) by filling thew onscreen buffer with the color of the flash, and then drawing the offscreen buffer onto it. (see set_bg_attr() in seg009.c)
The problem is that the moving objects (drects) are drawn *after* this (non-transparently). One solution would be to change their order.
Flashing is called from two places:
1. play_level_2() in seg003.c (through flash_if_hurt())
2. proc_cutscene_frame() in seg001.c
Update: I moved the flashing after the redraws in both places. This seems to solve the problem.
Note: I had the opposite problem with guard colors: The images have to be recolored *before* they are drawn.
The DOS version has it easier: Just change the hardware palette registers, and the color changes *immediately* and *everywhere*.
What are they called usually? Are there any examples?Andrew wrote:Say, is it right to term an engine recreation using disassembled code a "port"?
Perhaps "conversion"?
http://popc64.blogspot.hu/2011/10/prince-of-persia-for-commodore-64128.html wrote: The C64 conversion of Prince of Persia, based on the original Apple II code by Jordan Mechner has been released today.
Re: David's open-source port of PoP (pre-release)
I found what was wrong.Norbert wrote: I'm testing here and there, and I think it's not possible to do this trick?
http://www.youtube.com/watch?v=zYF3OMJeWms#t=372
It's so subtle that it's worth a longer discussion.
Here is the relevant part of the disassembly: (function bumped_floor)
Code: Select all
seg004:0526 cmp char_sword, 2
seg004:052B jz loc_586D
seg004:052D mov al, char_curr_row
seg004:0530 cbw
seg004:0531 mov bx, ax
seg004:0533 shl bx, 1
seg004:0535 mov ax, (y_land+2)[bx]
seg004:0539 mov cl, char_y
seg004:053D sub ch, ch
seg004:053F sub ax, cx
seg004:0541 cmp ax, 15
seg004:0544 jb loc_586D
seg004:0546 push cs
seg004:0547 call near ptr bumped_fall
seg004:054A jmp return
Code: Select all
if (char_.sword != 2 && y_land[char_.curr_row + 1] - char_.y >= 15) {
But the two sides of the comparison are signed. (y_land[...] is short, char_.y is byte, so integer promotion converts both to (signed) int.)
We need to force the comparison to be unsigned.
So the code should look like this:
Code: Select all
if (char_.sword != 2 && (word)(y_land[char_.curr_row + 1] - char_.y) >= (word)15) {
(Though one might say that the new version has a bug, and the older version of the code was the "fix". )
Two things helped me:
1. I debugged both versions (SDL and DOS) with a breakpoint placed in bumped_sound().
Then I looked at the backtrace of both, and noticed a difference:
The SDL stacktrace was: bumped -> bumped_floor -> bumped_sound
The DOS was: bumped -> bumped_floor -> bumped_fall -> bumped_sound
That is, bumped_floor has to call bumped_fall in this case. But that call is inside this if-statement, therefore the condition might be wrong.
2. That I already saw this assembly trick elsewhere in the disassembly.
At other places, this seems to be an abbreviation of two comparisons, for example:
(word)distance < (word)90 means distance < 90 && distance >= 0 (by interpreting the two's complement signed numbers as unsigned)
But at this place, it might as well be a bug, perhaps y_land was unsigned originally?
y_land is treated as unsigned in check_hang() and do_fall() (*), but not in sub_70B6().
(*) I will have to rewrite those two as well.
Re: David's open-source port of PoP (pre-release)
It is also possible to do using SDL: you can create an 8-bit offscreen surface, use SDL_SetPalette to change the colors and then blit it to the onscreen surface. Alternatively, you may declare the screen as an 8-bit surface with the SDL_HWPALETTE flag and then you don't need any extra blits.David wrote: The DOS version has it easier: Just change the hardware palette registers, and the color changes *immediately* and *everywhere*.
I would recommend the first approach unless there is a huge difference in performance. My experience is that doing more things on the hardware level makes your program less stable/portable. By the way, your current implementation has the advantage that bitmap resources can be replaced with true color images, which you will lose if you transition to 8-bit surfaces, so again it's up to you to weigh the pros and cons.
Re: David's open-source port of PoP (pre-release)
Nice, looking forward to the next release!David wrote:Update: I moved the flashing after the redraws in both places. This seems to solve the problem.
That sounds fine to me but anyway it is inconsequential. Was just me thinking out loud. Who cares what it's called as long as it works, right?David wrote:What are they called usually? Are there any examples?Andrew wrote:Say, is it right to term an engine recreation using disassembled code a "port"?
Perhaps "conversion"?http://popc64.blogspot.hu/2011/10/prince-of-persia-for-commodore-64128.html wrote: The C64 conversion of Prince of Persia, based on the original Apple II code by Jordan Mechner has been released today.
BTW, we need to have a better way of naming/releasing the updates than naming them all PORT_PoP.zip and attaching to subsequent posts. Perhaps PORT_PoP_v1.0α.zip and so on, or with the date or something? Or maybe just keep replacing the one in the first post with the latest release?
Re: David's open-source port of PoP (pre-release)
@htamas:
I know that SDL supports paletted surfaces. But I don't think that I should switch to them.
I could make the various palette tricks work with RGB, so the switching wouldn't give anything extra; but as you wrote, modders would lose the ability to use truecolor images.
@Andrew:
Hm... yes, currently we're using this same topic for both releasing and discussing.
So people who only want to download the newest version have to scroll through our descriptions of various bugs. -- Assuming that they look further than the first post.
So either we need a separate place just for releases, or replace the attachment in the first post. (Do we want to keep old versions?)
Naming: I could use the date, or, as Norbert said, use version numbers. They could be 1.00, 1.01, 1.02 to emphasize the smallness of the changes.
I tried the level 7 trick on various (accurate) platforms, and it seems that it's not possible everywhere.
Doable: Apple II, DOS, SNES (had to edit the level on SNES)
Not doable: Amiga, Mac, X68000
Maybe just a coincidence, but all platforms in the second row use the 68k CPU.
I know that SDL supports paletted surfaces. But I don't think that I should switch to them.
I could make the various palette tricks work with RGB, so the switching wouldn't give anything extra; but as you wrote, modders would lose the ability to use truecolor images.
@Andrew:
Hm... yes, currently we're using this same topic for both releasing and discussing.
So people who only want to download the newest version have to scroll through our descriptions of various bugs. -- Assuming that they look further than the first post.
So either we need a separate place just for releases, or replace the attachment in the first post. (Do we want to keep old versions?)
Naming: I could use the date, or, as Norbert said, use version numbers. They could be 1.00, 1.01, 1.02 to emphasize the smallness of the changes.
I tried the level 7 trick on various (accurate) platforms, and it seems that it's not possible everywhere.
Doable: Apple II, DOS, SNES (had to edit the level on SNES)
Not doable: Amiga, Mac, X68000
Maybe just a coincidence, but all platforms in the second row use the 68k CPU.
Re: David's open-source port of PoP (pre-release)
I've updated your first post to include a link to your post with the latest version.David wrote:So either we need a separate place just for releases, or replace the attachment in the first post.
I'll keep updating that link and will make sure it always points to the latest release, even if you start another thread about a newer release.
This should solve the problem for now.
-
- Calif
- Posts: 553
- Joined: August 27th, 2011, 2:04 am
Re: David's open-source port of PoP (pre-release)
This open source contains all the game graphics, effects and sounds, and where can i get it???
Check my Prince in C# https://github.com/salvadorc17/Prince-Monogame
Re: David's open-source port of PoP (pre-release)
download/file.php?id=546salvadorc17 wrote:This open source contains all the game graphics, effects and sounds, and where can i get it???
-
- Calif
- Posts: 553
- Joined: August 27th, 2011, 2:04 am
Re: David's open-source port of PoP (pre-release)
Hope that you will be able to do some extra stuff in this pop open source, like fighting two guards in same room, and different trigger events, this is possible in the net version im using...
Check my Prince in C# https://github.com/salvadorc17/Prince-Monogame
Re: David's open-source port of PoP (pre-release)
This is an interesting point to consider. Would people prefer a version that will work on modern OSes but maintain fidelity and be faithful to the original as far as possible (i.e. bugs and all), or one that fixes known bugs (and no doubt introduces new ones!) and also adds new features?salvadorc17 wrote:Hope that you will be able to do some extra stuff in this pop open source, like fighting two guards in same room, and different trigger events, this is possible in the net version im using...
If at all new features are to be added then personally I'd prefer two separate branches because the original experience is something unique and should be maintained IMO. If you've ever played and appreciated Chocolate Doom as opposed to the numerous other enhanced source ports of the game, you'll know exactly what I mean.
Re: David's open-source port of PoP (pre-release)
Shouldn't be too difficult to add a command line option that allows users to fix bugs.
The default - when not using the command line option - could then be as the original (official) game.
The default - when not using the command line option - could then be as the original (official) game.
-
- Calif
- Posts: 553
- Joined: August 27th, 2011, 2:04 am
Re: David's open-source port of PoP (pre-release)
But you can add new ingame features??? for improve gameplay...
Check my Prince in C# https://github.com/salvadorc17/Prince-Monogame
Re: David's open-source port of PoP (pre-release)
Sure, it's just a matter of investing time and energy.salvadorc17 wrote:But you can add new ingame features??? for improve gameplay...
I may dive into David's code at some point, for example to add game controller support.
Lots of fun things possible.
-
- Calif
- Posts: 553
- Joined: August 27th, 2011, 2:04 am
Re: David's open-source port of PoP (pre-release)
What do you used to compile this port??? is purely c++???
Check my Prince in C# https://github.com/salvadorc17/Prince-Monogame