SDLPoP; David's open-source port of PoP

[segra]

- Clean it up completely / migrate functions out of the generic seg* files ?

Maybe, but it's not urgent.

- POP2 Support?

PoP2 is very different from PoP1, so that would be a separate project.
The current status of PoP2 disassembly is here: viewtopic.php?p=14786#p14786

yeah i did see that ... was thinking, if your interested.... i have no issue taking a chunk of dis-assembley, and giving you a block of C code back if it can help such a project...

- Apple / Amiga data support?

Amiga graphics is identical to the DOS, so why?
Apple: It makes sense, but is it worth?

Alright good... if we clean up POP1 enough... it could be made into a single engine (or perhaps i spent too long with ScummVM... )

I was wondering more about sound data from the Amiga (already checked the graphics comparing with WinUAE and noticed its identical...).. we can improve the current graphics slightly by using SDL2 Scaler (slightly anyway, it depends on your res... my final output is 2560x1440.. so it looks blocky no matter what -:) )

and, cool.. I'm very interested in helping out where I can, POP has been a big interest of mine since i was young (ive got an original POP2 box somewhere that was a 9th birthday present)... but was playing it on the Amiga long before that (POP1 that is)...
and am happy to help out whenever I can (not sure if you looked through my GitHub profile or not, but I've a lot of experience in reverse engineering / re implementing software on multiple platforms.. C64/Amiga/Dos)

[David]

not sure if you looked through my GitHub profile or not

I looked at it now: https://github.com/segrax/
I see you added SDLPoP to Open Source Game Clones.

[segra]

yeah.. hope you dont mind

seemingly, i had a rather large amount of Jack Daniels last night, and am now suffering from the after the effects... opps

[David]

I'm currently working on the quicksave/quickload (since yesterday).

- Time keeps running out when you quickload, similar to dying or pressing CTRL+A.

So remaining time would not be saved.
But what if someone does a quicksave, and then restarts the game (and the time), and does a quickload?

Update: I uploaded the new version with quicksave/quickload.

[Falcury]

But what if someone does a quicksave, and then restarts the game (and the time), and does a quickload?

I suppose a solution could be to save the remaining time anyway, but then only read this value when the quicksave is loaded from a "foreign" (i.e. not the same) game session. This would also apply when the player has reached a higher level during the same session but quickloads back to a lower level. We might then want to penalize "foreign" quickloads by subtracting a minute or so.

Alternatively, it might make sense to simply remember quicksaved game states only for the duration of one level. So we never write it out to disk at all.

Or, we could save the remaining time anyway and accept that people will cheat the timer...

Edit:
I just tested the new version with quicksave. It works really well!

I have also pushed some new changes to GitHub. I have tweaked the timer system a bit - it's not perfect though. A "modern" game loop implementation would probably give more consistent results. Using vsync might be useful too, but I'm not sure how that could be done properly.

- added the SDL_RENDERER_ACCELERATED creation flag to the SDL renderer
- the SDL_Texture is now RGB24 instead of RGB8888
- removed some redundant screen updates
- flashes (potion, hurt etc.) are now displayed more consistently
- timer tweaks; timer 1 now tries to finish slightly before the 16.7 ms frametime has fully elapsed; hopefully gameplay is now consistently fluid on most systems
- added a named enum for timer ids
- added a short delay timer after the SHIFT+L cheat so that players can choose to view the cutscene if they wish
- is_shift_pressed and is_ctrl_pressed are now global variables (Edit: although now that I think about it, just storing the key modifier bitfield globally is indeed probably better)
- added the guard .DAT files to circumvent png images not loading correctly with SDL on Mac OS X
- added some missing sound enum values
- made load_sound() check for ogg files before mp3
- updated CMakeLists.txt to more consistently use the -mwindows option when compiling with MinGW on Windows

[David]

I suppose a solution could be to save the remaining time anyway, but then only read this value when the quicksave is loaded from a "foreign" (i.e. not the same) game session.

...and then people will always press ctrl-R before F9 to regain time.

I just tested the new version with quicksave. It works really well!

Thanks!

I have also pushed some new changes to GitHub.

https://github.com/NagyD/SDLPoP/pull/5/files

A "modern" game loop implementation would probably give more consistent results.

What do you mean by "modern game loop implementation"?

- timer tweaks; timer 1 now tries to finish slightly before the 16.7 ms frametime has fully elapsed; hopefully gameplay is now consistently fluid on most systems

So the time between SDL_AddTimer and the callback is sometimes not exactly what I asked for?
(But SDL_Delay() is exact?)

- added a short delay timer after the SHIFT+L cheat so that players can choose to view the cutscene if they wish

Yes, someone reported this problem: viewtopic.php?p=15030#p15030

Code: Select all

SDL_TimerID timer;
timer = SDL_AddTimer(delay, skip_cutscene_callback, &timer);

I don't think it's a good idea to pass the address of a local variable, because the callback will be called after process_key() returns.

- is_shift_pressed and is_ctrl_pressed are now global variables

But nothing reads these variables?

(Edit: although now that I think about it, just storing the key modifier bitfield globally is indeed probably better)

Do you mean WITH_SHIFT and the like?

- updated CMakeLists.txt to more consistently use the -mwindows option when compiling with MinGW on Windows

I don't know much about CMake, but:
The comment says "Only do this in debug mode".
But the flag is added only when CMAKE_BUILD_TYPE is *not* "Debug".

[Falcury]

...and then people will always press ctrl-R before F9 to regain time.

Hence a penalty of a minute or so for this way of quickloading?

What do you mean by "modern game loop implementation"?

Hm, I think I meant this: currently the game updating is managed by play_level_2() whereas the timer specifics are implemented elsewhere. Bringing the two together could perhaps give more consistent frametimes.

Code: Select all

while(1) {
    // this may be a naive approach!
    (handle events)
    ..
    if (wait_time == 0) {
        (game update)
        ..
        (display new frame)
    }
    ..
    (add appropriate delay until the next loop iteration)
}

So the time between SDL_AddTimer and the callback is sometimes not exactly what I asked for?
(But SDL_Delay() is exact?)

I don't know; I measured inconsistent frametimes on my system and thought that SDL_AddTimer must be the cause after I read this: " The granularity of the timer is platform-dependent, but you should count on it being at least 10 ms as this is the most common number. This means that if you request a 16 ms timer, your callback will run approximately 20 ms later on an unloaded system. If you wanted to set a flag signaling a frame update at 30 frames per second (every 33 ms), you might set a timer for 30 ms (see example below)."
Mind you, I am still measuring variable intervals within a range of approximately 5 milliseconds when using SDL_Delay()... This has been trial and error. Perhaps I should make a proper test case.

I don't think it's a good idea to pass the address of a local variable, because the callback will be called after process_key() returns.

Ah, you're right. Also, I just figured out that the timer will be cancelled if the callback returns 0 instead of the next interval, so fortunately passing the timer id to params is unnecessary anyway.

- is_shift_pressed and is_ctrl_pressed are now global variables

But nothing reads these variables?

Oops, I totally glossed over the previous changes (WITH_SHIFT etc) when I synced my fork, sorry about that! My change is indeed unnecessary.

- updated CMakeLists.txt to more consistently use the -mwindows option when compiling with MinGW on Windows

I don't know much about CMake, but:
The comment says "Only do this in debug mode".
But the flag is added only when CMAKE_BUILD_TYPE is *not* "Debug".

I will fix the comment.

[Norbert]

A Twitter shout-out to some of the folks who recently contributed to SDLPoP.

[David]

I reported the bug in the SDL Bugzilla: https://bugzilla.libsdl.org/show_bug.cgi?id=2986

They accepted my patch.

[David]

I merged the pull request.
Is there any reason for checking residual_wait_time <= 40?

By the way, I see some people starred the project: https://github.com/NagyD/SDLPoP/stargazers

[Falcury]

Is there any reason for checking residual_wait_time <= 40?

Feel free to take it out... I put it in because I wasn't brave enough to assume that nobody else would modify target_time (e.g. by calling start_timer() again before the timer was finished). If that really were to happen though, this check is not an adequate solution anyway. Perhaps using the target_time variable like this was just not the safest pattern in hindsight.

Some thoughts about the quicksave system:
- Would it be an idea to add a visual cue for quickloading? This may help to make the transition to the loaded state a bit less abrupt. For example, we could display a black screen for a short amount of time:

Code: Select all

in quick_load(): (seg000.c)
    stop_sounds();
+   start_timer(timer_0, 5); // briefly display a black screen as a visual cue
+   draw_rect(&screen_rect, 0);
+   screen_updates_suspended = 0;
+   request_screen_update();
+   screen_updates_suspended = 1;
    ...
    draw_hp();
+   do_wait(timer_0);
+   screen_updates_suspended = 0;
+   request_screen_update();
    ...

- Should quicksaving be allowed after the kid has died? (I was unfortunate enough to do this by accident...) Similar for quicksaving midjump/midfall/on a loose tile/while weightless/entering an exit door/drinking a potion
- Quickloading while executing certain movements, such as running jumps, may cause the kid to start moving immediately after the quickload has completed. Can this be prevented?

[Falcury]

I had a burst of madness and created a potion that temporarily changes the kid into the shadow.
See the attached experimental build. It includes a recent version of a custom level set of mine - I added the potion to level 6. You can quickload to the relevant part of the level to see the potion in action.
For the duration of the shadow effect, the kid can pass through gates, the kid does not get hurt from falling and loose tiles will not fall.
As a side effect, the max HP is reduced and the current HP is set to 1.
The potion uses tile modifier 7.

I also found the cause of a bug where leveldoors continue to slide open indefinitely under some circumstances (multiple exit doors, visiting the shadow room in level 6, or anything else that sets leveldoor_open to something other than 0 or 2).

Code: Select all

in animate_leveldoor(): (seg007.c)
// opening
++curr_modifier;
if (curr_modifier >= 43) {
	trob.type = -1; // do this regardless of the status of leveldoor_open
	stop_sounds();
	if (leveldoor_open == 0 || leveldoor_open == 2) {
		leveldoor_open = 1;
		if (current_level == 4) {
			// Special event: place mirror
			get_tile(4, 4, 0);
			curr_room_tiles[curr_tilepos] = tiles_13_mirror;
		}
	}
}

[Norbert]

I added the potion to level 6. You can quickload to the relevant part of the level to see the potion in action.

Are you sure?
When I use F9 to quickload the only potion nearby is a red one that doesn't seem to have any special effects.
I do see an unusual potion somewhere, but then you're really making us work for it...

[Falcury]

Well, yes. You can of course also make your own quick test level.

Edit: the quicksave file attached takes you directly to the potion.

[Norbert]

Well, yes.

Okay. It doesn't work for me. Maybe because I compile/link it myself to be able to run it on Linux, that not all changes are in the source files?