SDL2 desktop port

[singalen]

This project is such a great news, thank you for all your work! I looked into building it on Mac. SDL1 is holding me back, as it is known to be broken on the latest MacOS. SDL2 would be great to have.

[dbeef]

Hello @singalen, thanks for the compliments!

It so happens that I got my hands on an M1 very recently, but I did not tinker with SpelunkyPSP on it until now. I did some adjustments to the build system to support Darwin and it does build and run, here's a pull request with the changes:

https://github.com/dbeef/spelunky-psp/pull/121/files

There's some problem with input being captured by the terminal window and the viewport is downscaled for some reason - will get back to this in the evening.

Please try it and tell me whether it does solve the issue. As a note, I got SDL and SDL mixer through homebrew.

Cheers, Daniel

[dbeef]

I agree SDL1.2 will be more and more obsolete as the time progress and moving to SDL2 is definitely a good point.

As of now, Android build utilises SDL2, while all the other platforms use SDL1.2, so the sources that use SDL2 are already available, only the build system & build scripts & readme sections would require adjustments.

[singalen]

It does build and run, thanks a ton! I tried to do the same thing, but at the same time switch to SDL2. But I got blocked by SDL2 implementation being tied to GL ES, and I know approximately nothing about graphics initialization. SDL1 works. Now I remember, it's SDL_Image that has problems on modern MacOS versions.

I reproduced the problem with the main window being non-focusable (or, rather, not getting keyboard input - it does go into the foreground). The viewport seems fine (on Intel Mac, MacOS 10.15).

[singalen]

I tried SDL_INIT_EVERYTHING, it didn't help.

I'm getting a curious error in the output:

Unable to obtain graphics context for NSWindow (Mojave behavior)

This: https://github.com/gnuradio/gnuradio/issues/3669 is a hint that maybe it needs SDL2 after all. Source of the message: https://bugzilla-attachments.libsdl.org/attachments/4288/macosx-new-support.patch.txt

I'm running on Catalina, 10.15.7, Intel, MacPorts' version of SDL1. This is probably why it follows the Quartz code path.

[singalen]

...OK, it was trivial. Define SDL_main instead of main on Darwin (or, at least, with MacPorts).

[dbeef]

...OK, it was trivial. Define SDL_main instead of main on Darwin (or, at least, with MacPorts).

Nice, worked for me too, now window input does work, but the viewport problem remains - I suspect moving to SDL2 and passing SDL_WINDOW_ALLOW_HIGHDPI to SDL_CreateWindow will help. I'm going to try it tomorrow, let me know in case you work on it too.

[dbeef]

...and it did fix the viewport indeed.

Check out the comment I provided under the PR: https://github.com/dbeef/spelunky-psp/pull/121#issuecomment-986224203

Leaving the issue opened until I merge the follow-up that enables audio on Darwin.

[dbeef]

Audio is back on Darwin: https://github.com/dbeef/spelunky-psp/pull/122

As of now there's support for Darwin on the master branch, using SDL2.

Thanks for coming by, always nice to add support for a new platform.

[singalen]

Thanks to you!

Should I submit a pile of bugs for missing game logic, or just implement some when I feel like it? I see a number of issues with the basics.

BTW, what is your approach - do you translate original GameMaker code to C++ or reimplement it anew, or combined - reuse the same logic but in a new program structure?

[dbeef]

Should I submit a pile of bugs for missing game logic, or just implement some when I feel like it? I see a number of issues with the basics.

Yeah, please post an issue (or issues) so to keep track of what's being done right now.

BTW, what is your approach - do you translate original GameMaker code to C++ or reimplement it anew, or combined - reuse the same logic but in a new program structure?

When implementing some functionality it was always easier to do it in a "close enough" way, maybe sometimes running the original game to observe some AI behaviour in practice (i.e noticing that shopkeeper starts following main-dude when he grabs something, then trying to implement it in my codebase), but in general, logics I re-implemented were simple enough, and I have this notion that attention to details can be left for the days when the game is overall feature-complete ;)

Note - I want to re-work damage system internals some day (but before end of year) as it is right now overly complicated to use with each damage type being a separate component, just in case you feel distaste in how it's currently implemented.

[dbeef]

Just to finish my thoughts on the second question - when setting up the framework around which the game is implemented, designing systems and components (as in ECS), I didn't try to mimic the design/structure/abstraction of original sources. With different language and tools to use, it's more practical doing it from scratch, not looking back how it's done there.

When implementing specific logics of some AI - original sources actually could be useful, but see the comment before.

[singalen]

Got it, thanks! Brace for an influx of issues.