Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Port to SDL 2? #2

Closed
petterreinholdtsen opened this issue Apr 14, 2024 · 18 comments
Closed

Port to SDL 2? #2

petterreinholdtsen opened this issue Apr 14, 2024 · 18 comments
Assignees
@kentdahl
Labels
enhancement

Comments

@petterreinholdtsen
Copy link
Contributor

petterreinholdtsen commented Apr 14, 2024 •
edited
Loading

Is there any plan to port the source to SDL 2, ref. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038073 ?
@kentdahl
Copy link
Owner

Hi. Short answer; No, there are no plans to port it to SDL2.

Longer answer; since it has been 5-10 years since I've looked properly at it, I cannot recall if porting to Gosu was looking to be the better option, nor what SDL2 changes gave me some major headaches. A JavaScript port (yikes) with the Phaser library was starting to look like the saner approach...

Very microscopic chance I get a "30th Year Anniversary Surge Action" and do something frantic in the fall, but I wouldn't hold my breath.

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented Apr 15, 2024 via email

@kentdahl
Copy link
Owner

kentdahl commented May 3, 2024 •
edited
Loading

I looked over the Debian patches;

  • 30_fix-game-pausing.patch

    • wierd bug (reproduced on Ruby 1.9.3), but see we've had issues with 'drawBlendedUTF8' before, so taking the work-around in.

  • 20_isabella_path.patch

    • already added several alternate locations for that file over time, so the patch should not be needed any more.

  • 10_use_FHS_paths.patch

    • the shebang / env change makes sense.
    • the FHS paths to assets; I'd have to figure out something clever for this, or optionally add a '--data-dir=' option perhaps. Not sure how this is normally handled for Debian packages.

Put up a preliminary release for reference since the diff from 1.4.x to 1.5.x has a lot of eclectic stuff:

https://github.com/kentdahl/magic_maze/releases

Tested briefly on MacBook using three Ruby versions:

  • ruby 1.9.3p385 (2013-02-06 revision 39114) [x86_64-darwin12.2.1]
  • ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18]
  • ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-darwin21]

I'll give it another stab or two over the summer and see if I can do anything sensible.

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented May 7, 2024 via email

@kentdahl
Copy link
Owner

kentdahl commented May 7, 2024

[Petter Reinholdtsen]

I did a test build without the Debian patches, and then the program crashed like this: /usr/lib/ruby/vendor_ruby/magicmaze/engine/sdl/graphics.rb:148:in `load': Couldn't load data/gfx/title.png: Couldn't open data/gfx/title.png (SDL::Error)

For now, I've gone for the --datadir approach and started refactoring so that there is only one place to make the change.

I'm testing with local development copy like this:

ruby -I . ./mm.rb --datadir tmp/deb/usr/share/magicmaze/

There are several different ways to handle this. A simple way is to look for the files in several places, and use the first one it find, perhapd first look in data/gfx/ and next in /usr/share/magicmaze/gfx/.

I was considering this, but thought it too hackish. Then it dawned on me that I cannot seem to find where the game is started in the Debian package git repo, so I wouldn't know where to add the datadir argument there.

So a separate start_debian_magicmaze.rb script where the default datadir is set to /usr/share/magicmaze/ might be the cleanest and avoid needing a patch. (Cleaning up the command-line option handling to allow for this.)

Put up a preliminary release for reference since the diff from 1.4.x to 1.5.x has a lot of eclectic stuff:
Will this also move to a newer sdl version?

The 1.5.x versions will move to / add a SDL2 version sometime during the summer if I don't run into any major show-stoppers. I've gone through my old sdl2-port branch and have a vague idea of why I got stuck last time, so I'm fairly optimistic I'll figure it out this time around. :)

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented May 7, 2024 via email

@kentdahl
Copy link
Owner

kentdahl commented May 7, 2024

[Petter Reinholdtsen]

As far as I can tell, the XDG desktop file calls /usr/games/magicmaze which is a copy of mm.rb from the source.

Then making a separate mm.rb script for Debian to copy from makes sense. I'll give it a gander tonight.

You might want to move the desktop file upstream and include a Appstream metainfo XML file too. I can prepare a patch if you are interested.

Please do, as I'm not sure where to start on that.

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented May 7, 2024 via email

@kentdahl
Copy link
Owner

kentdahl commented May 7, 2024

[Petter Reinholdtsen]

The XDG desktop file assume a binary magicmaze is available in the PATH.

Looked closer at the https://salsa.debian.org/debian/magicmaze.git repo and found where the script is copied in the rules file:
https://sources.debian.org/src/magicmaze/1.4.3.6%2Bdfsg-4/debian/rules/

override_dh_install:
  dh_install
  cp -a mm.rb $(CURDIR)/debian/magicmaze/usr/games/magicmaze

So the Ruby script is copied in like any binary would, but to games instead of bin directory.

The mm.rb here should be changed to copy the start_debian_magicmaze.rb instead going forward.

I have no idea how Ruby normally install its stuff on a system, so I did not try to add such mechanism.

In install file at: https://sources.debian.org/src/magicmaze/1.4.3.6%2Bdfsg-4/debian/install - where you find the line:

magicmaze/    usr/lib/ruby/vendor_ruby/

means all the Ruby source code in MagicMaze is copied in for any Ruby program to use. That is why we don't need an explicit include-path for the MagicMaze source code. (The Ruby-SDL dependency is a slightly different ball of wax, but is probably put the same place too.)

@kentdahl kentdahl self-assigned this May 7, 2024
@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented May 8, 2024 via email

@kentdahl
Copy link
Owner

kentdahl commented May 9, 2024

I've done an initial SDL2 port (#10) and put it in a preliminary release: v1.5.1-alpha0

Most of the stuff mostly works, but a lot is less than ideal and neither as polished or tested as the SDL1 version. (I'd say the port is about 30% complete at this point.)
Doing some cleanup next (#11) and plan for polish and proper testing at a later time.

Tested briefly on Mac with:

  • ruby 2.5.9p229 (2021-04-05 revision 67939) [x86_64-darwin21]
  • ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-darwin21]

The main Ruby versions in Debian according to: https://wiki.debian.org/Ruby

  • MRI 2.7.4
  • MRI 2.5.5

I recall that Debian was fairly conservative on taking in new major Ruby version (hence we all used RVM back in my day), but if you have any specific Ruby versions I should prioritize my testing on, that would be good. As far as I can tell, 'bookworm' (Debian 12) is going for Ruby 3.1.2 and 'sid' is on Ruby 3.2.3

P.S.: I noticed the icon-not-found hint on appstream: https://appstream.debian.org/sid/main/issues/magicmaze.html
and then remembered that for the OLPC XO version we created an SVG icon / logo, which I've put in data/gfx/logo.svg for now. Perhaps that is a better fit?

Magic Maze SVG logo

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented May 10, 2024 via email

@kentdahl
Copy link
Owner

After a fair amount of testing back and forth, I've put up two official releases:

Stable v1.5.0.0 is old SDL version, but all other updates since 2010, including the latest Debian package-related changes.

SDL Upgrade Release v1.5.1 (a.k.a. SUR) is upgraded to SDL2 and has had a major cleanup.

So SUR for sid, and Stable for stable, I recon... depending on the priorities on your end.

Closing this issue now. Please open a new issue for tracking further changes we'd want related specifically to Debian packaging and what makes sense to put into upstream. (SVG logo, fonts (#14), etc)

I've looked at the Salsa repo and put the things I know of in this suggested patch:
https://gist.github.com/kentdahl/d7a8204ae599dff9bc09e2debedf2888

(P.S.: I've got about a week left now in May before I enter my yearly CorporateTaxReturnsPanicMode, so anything you need from me fairly urgently, please let me know before May 17th.)

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented May 12, 2024 via email

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented Jun 11, 2024 via email

@kentdahl
Copy link
Owner

I ran it from the source in salsa and I cannot see that it loads old SDL version.
Checked with lsof and vmmap and I only get references to SDL2.

Tried these two tagged versions on salsa:

  • upstream/1.5.1+dfsg (on upstream branch)
  • debian/1.5.1+dfsg-1 (on experimental branch)

Can you provide more details on how you are seeing it pulling in SDL 1.2?

Details from lsof and vmmap on mac:

$ ps | grep ruby

65547 ttys031    0:00.00 grep ruby
64969 ttys037    0:04.05 ruby -I . ./mm.rb --datadir=./data/

$ lsof -p 64969 | grep -i sdl

ruby    64969 kent  txt      REG                1,4   130920           162352658 /usr/local/Cellar/sdl2_image/2.8.2_1/lib/libSDL2_image-2.0.0.dylib
ruby    64969 kent  txt      REG                1,4    91392           158146617 /usr/local/Cellar/sdl2_ttf/2.22.0/lib/libSDL2_ttf-2.0.0.dylib
ruby    64969 kent  txt      REG                1,4   162984           159250292 /usr/local/Cellar/sdl2_mixer/2.8.0/lib/libSDL2_mixer-2.0.0.dylib
ruby    64969 kent  txt      REG                1,4   262040           169683184 /Users/kent/.rvm/gems/ruby-3.3.1/gems/ruby-sdl2-0.3.6/lib/sdl2_ext.bundle
ruby    64969 kent  txt      REG                1,4  1569952           169600122 /usr/local/Cellar/sdl2/2.30.3/lib/libSDL2-2.0.0.dylib

$ vmmap 64969 | grep -i SDL

__TEXT                      10d060000-10d078000    [   96K    56K     0K     0K] r-x/rwx SM=COW          /usr/local/Cellar/sdl2_image/2.8.2_1/lib/libSDL2_image-2.0.0.dylib
__DATA_CONST                10d078000-10d07c000    [   16K     8K     4K     0K] r--/rwx SM=COW          /usr/local/Cellar/sdl2_image/2.8.2_1/lib/libSDL2_image-2.0.0.dylib
__LINKEDIT                  10d080000-10d084000    [   16K     8K     0K     0K] r--/rwx SM=COW          /usr/local/Cellar/sdl2_image/2.8.2_1/lib/libSDL2_image-2.0.0.dylib
__TEXT                      10d084000-10d090000    [   48K    48K     0K     0K] r-x/rwx SM=COW          /usr/local/Cellar/sdl2_ttf/2.22.0/lib/libSDL2_ttf-2.0.0.dylib
# [...snipped for brevity...]
__TEXT                      10febb000-10fedb000    [  128K   124K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/sdl2_ext.bundle
# [...snipped for brevity...]
__TEXT                      1100fb000-110223000    [ 1184K   920K     0K     0K] r-x/rwx SM=COW          /usr/local/Cellar/sdl2/2.30.3/lib/libSDL2-2.0.0.dylib
# [...snipped for brevity...]
__DATA                      11022b000-110237000    [   48K    48K    48K     0K] rw-/rwx SM=COW          /usr/local/Cellar/sdl2/2.30.3/lib/libSDL2-2.0.0.dylib

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented Jun 11, 2024 via email

@kentdahl
Copy link
Owner

kentdahl commented Jun 11, 2024 •
edited
Loading

Seems to me this is a packaging issue, not a loading issue.

If I'm reading this correctly, the Debian package ruby-sdl is for the Ruby gem rubysdl, currently at version 2.2.0

The 2.2.0 version for ruby-sdl does not relate to the SDL version. The gem that wraps SDL2 is an entirely different gem ruby-sdl2, currently at version 0.3.6 - compare:

So I am not sure how one would solve this without adding a Debian package for ruby-sdl2 separately from the ruby-sdl one. (And SDL3 is right around the corner...)

Originally when Magic Maze was added to Debian, the dependency was handled by libsdl-ruby which Joe described as a dummy package, so I assume that the ruby-sdl package at some point took over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kentdahl kentdahl

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@petterreinholdtsen @kentdahl