!Hopper running in different screen modes

I am still working from home and in a moment of rest (looking for an excuse not to do real work) happened to click on !hopper in the Diversions directory. I was surprised to see that !hopper would not run as standard on my Titanium as it needs mode 13 which is 320 × 256 256C I had downloaded the sources some time ago so I located !hopper for a quick look?.

What started out as a quick look soon became a quest :-)

Try it out and let me know if it works OK.

Anyway the end result is go to
www.mbelect.co.uk/RISCOS/progs/hopper.zip to download a replacement !runimage

This allows !hopper to run in mode 28 (640 x480 256) which seems to work on my titainium and PI400
I have included in the zip file the changes I have made to the source files I assume this will not upset anyone as the sources are available anyway. If this is not the case let me know and I will remove them.

If interested read below to what I changed.

Terry

Shift Double Click in !Hopper icon
Rename the original !runimage to !Runimage2
Copy the !Runimage from this zip file into the !hopper directory.

This will enable !hopper to run in 640 × 480 256c (mode 28)
This mode seems standard on most machines and is the close to the original.
I have tested this version on a Titanium and PI400

!hopper will run in almost any mode, you may see some colour font changes
but other than that it should work.

Once !hopper has been run once you can just double click !Deskimage
which runs in the current desktop mode you have selected.
You can change the matrix struct in graphics.c to change the scale.

I have included the files I have changed in the c and h directories.
search for my initials TDS and you will see any changes I have made.

How it works.
The original !Hopper was well written and used a back buffer to copy various
graphics to the main screen things that never updated much like the words
score, high etc.
It also used this back buffer to enable fading of graphics I have disabled
this because it caused problems when running in different modes.

I have changed the program to use a sprite and all screen output is now drawn
to this sprite, then the whole sprite is plotted to the screen this gives
the advantage that it will run in different screen modes but does take up
some processing power but this should not be a problem on newer machines.

I have not attempted to update the RISC OS sources and will leave this to
someone with more experience in this area if they think its worthwhile.

Terry

This allows !hopper to run in mode 28 (640 x480 256) which seems to work on my titainium and PI400

And ARMX6 as well.

Thanks Terry, can you arrange to look for excuses and be bored more often :-)

then the whole sprite is plotted to the screen

Could be worth investigating if a contemporary machine has low enough latency to allow it to render into a window so can be played within the desktop…?

I’d imagine, as long as it was co-existing with well-written apps, it ought to be pretty smooth on >=1GHz hardware.

@doug Good to know that it works on other hardware, thanks for the response, not sure about getting bored more often, this distracted me a bit longer than I expected :-)

@rick
My game !munchy works quite well in the desktop, perhaps when I feel brave I might have a closer look at hopper to tweak it into a desktop application.

Although hopper is well written its always a challenge looking at other peoples software and working out what’s going on, as always hopper threw up some unexpected hurdles to overcome but if it was easy it would be boring :-)

What started out as a quick look soon became a quest :-)
Anyway the end result […] allows !hopper to run in mode 28 (640 x480 256)

I took a look at Hopper back in 2017 though I can’t remember now where I put my changes. I figured going for 640×512 was safest because that’s just a straight power-of-2 scaling on 320×256 so no need to worry about losing 32 rows. While it worked I quickly concluded that shifting 4x the data around wasn’t workable (it should still run on a Risc PC, like it used to) and that the real task was to change the way the redraw was done to only plot the bits that are moving rather than the entire screen!

Even querying the available modes isn’t helpful, because you might have a platform with the mode available but not enough grunt to run the game.

Might I suggest that not having enough grunt to run the game shouldn’t really be considered a fatal problem if the alternative is “can’t run the game at all” due to the 320×256 being below the HDMI floor. I’ve tended to leave Hopper out of distributions simply because it fails to run on any modern hardware except Pi in non-default hardware-scaling mode. I’m really pleased to see Terry working on it, and would welcome any updates – esp if it can intelligently check to see what modes are available.

I have had added a desktop window to hopper and have the graphics drawing in the window, it may take a while to untangle the intro screens and the main game from the tight loops they are running in.

As you can see from the deskimage hopper can adapt to any screen mode,it runs OK ish on an iyonix I suppose we always have the original to run on older machines.

If people think it’s worthwhile I could attempt a desktop version?

I’m away for a couple of weeks, no computer access so I might have another go at hopper when I return if it’s of interest.