search

kentdahl / magic_maze

Magic Maze - Ruby/SDL2 port - Magic Maze is a simple and low-tech monster-bashing maze game. - It was originally inspired by playing Gauntlet II on the Atari ST.
GNU General Public License v2.0
4 stars 2 forks source link

Port to SDL 2? #2

Closed petterreinholdtsen closed 6 months ago

petterreinholdtsen commented 7 months ago

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

kentdahl commented 7 months ago

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 commented 7 months ago

[Kent Dahl]

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...

I see. In any case, if you do consider a new release, you might want to also consider the patches used by the Debian package, available via the 'Debian patches' link in <URL: https://tracker.debian.org/magicmaze >.

The game is still used by Debian users. According to collected statistics (popcon), five computers ran it last week. :)

-- Happy hacking Petter Reinholdtsen

kentdahl commented 7 months ago

I looked over the Debian patches;

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:

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

petterreinholdtsen commented 7 months ago

[Kent Dahl]

I looked over the Debian patches;

Great to hear. :)

  • 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.

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) from /usr/lib/ruby/vendor_ruby/magicmaze/engine/sdl/graphics.rb:148:inblock in load_background_images' from /usr/lib/ruby/vendor_ruby/magicmaze/engine/sdl/graphics.rb:147:in each' from /usr/lib/ruby/vendor_ruby/magicmaze/engine/sdl/graphics.rb:147:inload_background_images' from /usr/lib/ruby/vendor_ruby/magicmaze/engine/sdl/graphics.rb:45:in initialize' from /usr/lib/ruby/vendor_ruby/magicmaze/graphics.rb:69:innew' from /usr/lib/ruby/vendor_ruby/magicmaze/graphics.rb:69:in get_graphics' from /usr/lib/ruby/vendor_ruby/magicmaze/game.rb:57:ininit_graphics' from /usr/lib/ruby/vendor_ruby/magicmaze/game.rb:42:in initialize' from /usr/games/magicmaze:119:innew' from /usr/games/magicmaze:119:in `

'

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/.

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?

-- Happy hacking Petter Reinholdtsen

kentdahl commented 7 months ago

[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 commented 7 months ago

[Kent Dahl]

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.

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

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.

-- Happy hacking Petter Reinholdtsen

kentdahl commented 7 months ago

[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 commented 7 months ago

[Kent Dahl]

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

https://github.com/kentdahl/magic_maze/pull/9 should do it. The XDG desktop file assume a binary magicmaze is available in the PATH.

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

-- Happy hacking Petter Reinholdtsen

kentdahl commented 7 months ago

[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.)

petterreinholdtsen commented 7 months ago

[Kent Dahl]

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

OK.

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:

In non-ruby source packages, there are normally installation rules provided by the upstream project (in setup.py, Makefile, CMakeLists.txt, Makefile.am, configure.ac, etc) copying the files into the appropriate location for the program at hand. This ensure files end up in the same place across all Linux distributions. I have no idea if a simliar approach exist for Ruby packages. For the Debian packaging, files in debian/* take care of it. In the situation where the installation rules are provided by the upstream project, it is normally done using the dh_auto_install script calling the appropriate build rule to install files.

-- Happy hacking Petter Reinholdtsen

kentdahl commented 6 months ago

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:

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

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 commented 6 months ago

[Kent Dahl]

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

I do not pay much attention to roby, but in general the version in unstable/sid is the one to prioritize, as it is the one used to build the package and the one that will be in the next stable release.

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?

Yes, a vector logo is better than a bitmap one.

-- Happy hacking Petter Reinholdtsen

kentdahl commented 6 months ago

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 commented 6 months ago

[Kent Dahl]

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

Great to hear. :)

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

I doubt I will get any update past the stable release team, but uploaded the 1.5.0.0 version to unstable and will wait for it to propagate to testing to make it possible to provide it as a backport, if someone is so included. Once this version reaches testing, I plan to upload the 1.5.1 version to unstable for wider testing.

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)

OK. The only relevant change seem to be the repacking to drop data/gfx/fraktmod.*.

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

Thanks. I will have a new look at it for the 1.5.1 release. I included most relevant changes in the 1.5.0.0 release, where the build rules were rewritten.

-- Happy hacking Petter Reinholdtsen

petterreinholdtsen commented 5 months ago

[Petter Reinholdtsen]

I doubt I will get any update past the stable release team, but uploaded the 1.5.0.0 version to unstable and will wait for it to propagate to testing to make it possible to provide it as a backport, if someone is so included. Once this version reaches testing, I plan to upload the 1.5.1 version to unstable for wider testing.

I seem to have messed something up with the 1.5.1 upload to experimental in Debian, as it seem to still use SDL 1.2. Any idea what went wrong?

<URL: https://tracker.debian.org/magicmaze >

-- Happy hacking Petter Reinholdtsen

kentdahl commented 5 months ago

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:

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 commented 5 months ago

[Kent Dahl]

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

The details I got are in <URL: https://bugs.debian.org/1038073 >.

kentdahl commented 5 months ago

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.