In part one of this series, I gave a little background on Drop Rock, one of the games I wrote for RISC OS back in the early 1990s. The game saw a mid-1990s update for the RiscPC, and I am now looking at it again for newer systems. Today I’m going to quickly look at the first step in the process – probably the easiest step; getting it running at 1920×1080.
I noted in part one that the RiscPC version of the game runs in MODE 32, which is 800 pixels wide by 600 pixels high, and uses 256 colours. The RiscPC version of another of my old games, Escape from Exeria, also runs in that mode, and that has already seen an update for modern RISC OS systems, but I’ve decided to take a different approach with Drop Rock than I did for that.
In the case of Escape from Exeria from I opted to use a 1920×1080 full colour mode, but to keep the map size the same. It therefore needed new graphics at a suitably higher tile size and colour depth. For Drop Rock, however, I’ve decided to keep the existing graphics to start with (I may change them later) and instead give it a larger play area on the higher resolution screen.
As an aside, in hindsight it might be a good idea to write something about the Escape from Exeria update, so the next post after this one will be about that.
As a reminder, the RiscPC version of Drop Rock looks like this:
Within the program itself, which is written in BBC BASIC V, the screen mode is set with the command:
MODE 32
And that has to change to reflect the screen resolution I want to use. It needs to be:
MODE "x1920 y1080 c256"
Simply making that change, however, isn’t enough. Doing so will simply result in everything being plotted in the bottom left of the screen, as you can see from this screen grab:
In other words, the total 800×600 pixel screen is now taking up the bottom left 800×600 pixels of the 1920×1080 pixel screen.
As the longer term plan is to increase the play area, ultimately I will still want to be plotting everything from the bottom left. For now, however, to make it look reasonably sensible, the quickest fix is just to move what’s displayed to the centre of the screen.
If the screen’s horizontal resolution is 1920 pixels, and the game was designed around a width of 800 pixels, then to centre it horizontally, everything needs to be moved right by (1920-800)/2, or 560 pixels.
Similarly, if the screen’s vertical resolution is 1080 pixels, and the game was designed around a height of 600 pixels, then to centre it vertically, everything needs to be moved up by (1080-600)/2, or 240 pixels.
There is a further calculation to be considered in both cases, as well, which is how that translates into OS units. Acorn Computers used a virtual graphics resolution in the BBC Micro days whereby the screen was treated as having 1280×1024 virtual pixels, even if the actual resolution was lower, and all graphics plotting was done based on the virtual resolution. This was carried forward to the Acorn Archimedes range, but as actual screen resolutions got higher, so those original values became out of date. They were fine for resolutions up to 1280×1024, but not for greater resolutions.
For MODE 32, while the actual resolution is 800×600, the virtual resolution is 1600×1200 – and for 1920×1080 modes, the virtual resolution is 3840×2160; in both cases that’s a 2:1 ratio of virtual to actual pixels in both directions. This means that the two offsets above need to be doubled to get the offset figure needed to plot the game’s graphics in the middle of the screen – or to simplify even further, the division by two can be dropped in the initial calculations.
So the offset to be used is 1120 horizontally, and 480 vertically.
The simplest way to make this change is to change the graphics origin after changing the screen mode. That is to say, tell the system that 0,0 is somewhere other than the bottom left of the screen – and we’ve already worked out where that needs to be: 1120 pixels in from the left, and 480 up from the bottom. This can be done with a VDU command; VDU 29 sets the graphics origin:
VDU 29, 1120; 480;
Adding that line to the program after the MODE command does the trick, and results in this:
However, that simplistic approach assumes everything is going to stay as it is, other than the game being displayed in a different part of the screen – but that’s not the plan. The line will have to be removed again at some point, but for now it does the trick.
As noted above, by keeping the existing tile size, my plan is to take advantage of the higher resolution screen to provide a larger play area. The current play area map is 18×12 tiles. With a tile size of 32×32 pixels, it therefore covers a 576×384 pixel area, and the remainder of the screen is taken up with borders, the level name, the score/level number/remaining lives, and the title graphic.
If all of the game tiles (including the borders) remain at their current sizes, a change of resolution gives a greater available area to play with. Specifically, the change from 800×600 to 1920×1080 offers an increase of 1120 pixels horizontally, and 480 pixels vertically. Those figures can be divided by the tile size to indicate how much larger the play area could be: 1120/32 is 35, so the horizontal play area could be made 35 tiles wider (53 tiles), and 480/32 is 15, so the vertical play area could be made 15 tiles higher (27 tiles). In other words, a potential new map size of 53×27 – though whether that’s what I’ll eventually go for is another matter!
Something else to be thought about is the title graphic that is plotted to the right of the play area – with the change from a screen height of 600 pixels to one of 1080 pixels, it’s obviously now too small, and no longer fills the full height of the screen. There are a number of possible things I could do here:
- I could simply scale it up. This would increase it’s width as well as its height, and therefore reduce the horizontal map size from the possibility given above – but it will almost certainly look naff if I do.
- I could create a new one to match the new screen height, in which case how that affects the map size will depend on the width I give it. If it’s based on the existing graphic, it’ll be proportionally the same, so again will eat into the horizontal play area.
- I could do away with it altogether, and in doing so free up more horizontal screen space for the play area – and therefore increase that map size again.
- I could do away with it, and move the scores etc to the right of the play area. Doing this would probably have an effect on the horizontal size, depending on how I lay it out and how much space I want to give to that information – but by moving the scores from below the map, the map can also gain a little height.
- Another option that will allow me to increase the map size vertically would be to keep the title graphic, and put scores etc. at the side of the screen – perhaps below the graphic, or perhaps make slight modifications to make it look more appropriate.
This is a decision still to be made. The option I currently favour is the last one – keeping the title graphic (or a version of it) and putting the scores etc. to the side as well. However, other things will need to be looked at before I have to make a choice about that.
To be continued!