Super Mario on the BBC?

[tricky]

Well, I'm not promising the rest of the game to go with it

[Commie_User]

[algenon_iii]

I'd prefer a Sonic port if someone thought of adapting a console game to the Acorn 8 bits. I've never been a fan of the Mario games.

Rant: It seems that the NES always has to have a prominent place in the histories of computer and console games that are published on mainstream sites dedicated to gaming. It's like the comfort blanket for a generation of US gamers and even with some UK gaming types, though I can't help feeling that there were precious few people actually playing NES games in the UK when the console was still current. I understand that it was an influential console but I think it gets a disproportionate amount of attention now.

Well the NES sold some 60 million units, the best selling home computer (the C64) sold around 12 million despite both being released at roughly the same time (although the NES remained in production for around twice as long as the C64).

[Rich Talbot-Watkins]

I think I can scroll up to 8 mode 4 pixels per frame in under half a frame

Don't quite get what you mean by that! Anyway, it looks as if it's just relying on levels being very sparse and overdrawing the level features at increasing pixel offsets (much in the way you did in Jeltron I guess). Either that or it is actually scrolling rectangular blocks of the screen one pixel at a time, but just drastically limiting the scope of what needs to be scrolled by not having so much on screen at once. By the looks of the rapid flickering (which seems to be a 'feature'?), it looks like it's actually updating the whole screen each time. I guess you'd need 8 copies of the sprites at each pixel alignment for this to work at any decent speed.

Personally I'd favour a hardware scrolled approach in a more colourful mode, but using the method I suggested earlier (not continuous scrolling when the player's movement is slower than one character block per screen, but starting a slightly faster scroll once they reach a margin position).

[Commie_User]

Well the NES sold some 60 million units, the best selling home computer (the C64) sold around 12 million despite both being released at roughly the same time (although the NES remained in production for around twice as long as the C64).

Oh no no no...

https://en.wikipedia.org/wiki/Nintendo_ ... ent_System

...DISCONTINUED 2003?!?


Also, I don't think the Commie or BBC got their own breakfast cereal, cartoons, action figures and all what else. That's what kids want!

[tricky]

Yes Rich,
redraw everything and hope the screen is sparse. I do agree that for most games hardware scroll when you get close to an edge would work nicely.
By scroll at up to 8 pixels, I just mean that the scrolling could be at any speed.

This is the "slowest" part of the level to draw and is under 16 characters rows (less than half the visible screen) to redraw.

First pass is about 6K for sprites, 6K for Map, 8K for screen, 1.25K for unrolled draw code, this is for a map biased to creating draw code quickly and easily. Hardware scrolling characters would also be good.

There are a few obvious savings to be had:
* clouds could be programmatic and not mapped (they could also scroll at a different rate).
* The "floor" could be a special case, saving map space and drawing more quickly.

It would also be nice to use the full width 320 instead of 256, taking 1/4 longer to draw, code space and screen memory.
I'm not sure how far to take this "mental" exercise, but it has been fun so far.

[tricky]

Was feeling ill tonight, so had a go at implementing the code.
It doesn't go out of the initial character and leaves the sky black so that you can see what is redrawn each frame.
The drawing starts with vsync and finishes just below the flag (spot the slightly wobbly flag top).

As I mentioned it would be quicker if I treated the ground as a special case and drew the clouds separately.
The code provided (with the .ssd) actually draws left to right, which isn't the best choice for chasing the raster

[Commie_User]

Jer-jer-jiggle it a bit!

I like the Game Boy feel. How difficult or time-consuming is it to do this kind of stuff?

Get well soon.

[Kecske Bak]

Fascinating demo. The thing about your work is that it never feels like it's running on a BBC - it's odd to see a background scroll so smoothly so quickly after decades of being used to the effect on the screen edges when Repton or Ravenskull scroll. I had a look in the asm to see what you were doing too - wonderful to see the huge unrolled loop and you putting the cycles in the comments. You're really squeezing the machine till the pips squeak.

[Rich Talbot-Watkins]

Very nice work Richard! I wonder how this approach could translate to a full game, as opposed to a single hardcoded screen as per your demo?

I'd wondered how you'd handle the masking of scenery tiles being plotted unaligned, but here it seems like you've stored unaligned versions with their adjacent tiles included to the left and right, so no masking required. Obviously that makes it as fast as it can get, but I don't know if this really scales well in a proper level, where a particular tile can be preceded or followed by any other tile. It'd be interesting to know exactly how many combinations of adjacent tile numbers there are in a real Mario level, to get some idea of exactly how much sprite data would be required.

I guess one approach would be to actually construct the unaligned data on the fly, i.e. as new parts of the level are about to become visible, build 8 copies of all the tiles about to be scrolled on, with different versions depending on their neighbour tiles. Basically some kind of sprite cache which you can throw away once the tile has gone offscreen again. If you were to split the work over many, many frames, I can see this being feasible. The map would need to be stored sparsely in any case (e.g. an array of {xpos, tile_num} for every y position), rather than as a 2d array, so you could easily determine what's coming a long way in advance when building sprite data. That'd also present the data in the simplest possible way for refreshing the screen quickly.

Hope you get better soon mate!

[Rich Talbot-Watkins]

So, I decided to look into this myself, using this Level 1 map from here:


We have level blocks made up of 2x2 basic tiles, which can be reused within multiple blocks, so I figured that 'tiles' were probably the best primitive to get started with. What I wanted to know was how many different tiles would be necessary to represent this level at any horizontal scroll position. So, as well as the basic tiles, we would need to generate tiles at 7 possible scroll positions which contain some of tile A + some of tile B (where A and B are adjacent in the map).

I wrote a little program (here) to count the adjacent tile numbers, and here's what I got:

Code: Select all

Number of tiles: 57
Number of blocks: 31
Number tile pairs: 129
Map size: 2116

So there are 57 distinct tile defs in Level 1 (currently counting the middle of clouds as distinct from blank tiles, and also treating clouds and bushes as different tiles). There are 129 unique pairs, i.e. consecutive tiles which can be scrolled one into the other (including a blank tile into scenery).

If we were to store all of those in memory at once, we'd need:

129 * 7 scroll positions * 8 bytes
+ 57 * 8 bytes
= 7680 bytes (&1E00)

which isn't impossibly large, but I still wonder if generating them dynamically would be a win.

The map (in an arbitrary format, storing runs of tiles over 24 lines, with a RLE for repeated tile pairs) would be 2116 bytes. If this stored blocks instead of tiles, it would be shorter, but then we couldn't prebake the special tile numbers for adjacent pairs and it'd have to be calculated at runtime.

Animated sprites would definitely need 8 copies, so keeping the tile graphics size down would be pretty crucial!

[Rich Talbot-Watkins]

Also, I don't really know how well it would run without doing clever optimizations to plot the same tile multiple times from a single load. The floor would almost certainly need to be done separately. I'm not sure if it'd be worth trying to batch identical tiles somehow - you'd lose raster chasing, but I feel like the saving would be worthwhile in complex bits of maps with multiple blocks of the same type. How would you do it?

[tricky]

The map I built is for that whole level, but I changed the things that I thought were showing what would be popped out from a floor block into floor blocks (these would need some care later).
The draw code is what I would generate from the map, but is just the "worst case" screen as a test (dumped from the mapper).
It considers all tile pairs and then stores only the left one with the right one shifted in (maybe backwards). I will have to check if the source I posted had the double width tiles (considering 3 and storing 2) or 8 byte tiles (consider 2, store one) data in the map.
The map is supposed to store vertical strips so that the draw code can be moved around and have the new tiles from either end slotted in in the middle.

Code: Select all

.loop
lda:sta:sta:sta
...
jmp rest
...
.rest
lda:sta:sta:sta
...
dex...
bpl loop

so the lda:sta code is like a circular buffer where you can slot in the new tiles at the beginning or end and then jmp the gap as there are different numbers of tiles on screen.
Doing it like this you only get multiple stores for one load when the same tile (8x8 pix) is repeated in the same column, but the cost of scrolling is cheap; this also assumes hardware scrolling.
Software scrolling would work, but all the store addresses not replaced would need adjusting (only low byte so not too bad).
I did start writing up the process I went through to generate this demo, but got a bit tired of typing on my phone and saved it as a draft for later.
I would have given this idea up, but doing the maths it looked like you could actually draw a lot (8K max, 2K is more realistic) per frame and so I thought it was worth seeing where it might lead.
If you did go mode 5, you could half the copies of sprites and still have something scrolling at arcade game rates.

EDIT: I see I didn't include the map data, that would explain why RichTW thought I didn't have one
The map is 3,569 bytes for the level as described and shown in the image and has 106 (not counting blank) 8x8 pixel char/tile pairs (only storing left one).

PS Forgot to mention that the software scrolling after 8 pixels as opposed to hardware after 8 pixels would require 9 copies of each tile requiring 7,632 instead of 6,784 bytes but no extra drawing.

[Rich Talbot-Watkins]

Ah, sounds like you're much further along than I'd thought!

Seems like you're thinking about this really differently to me - I imagined storing horizontal spans, including a blank tile on either side in order to get auto-erase. I definitely hadn't contemplated hardware scrolling - I figured that keeping it at a 6k screen was beneficial memory-wise, and also not especially necessary when every update needs a redraw anyway. That's also more raster-chasing friendly!

I can see how holding vertical spans is more conducive to single load / multiple store, which is probably what would make your method better ultimately. I think I can also see how hardware scrolling would be advantageous in this case as well, as (assuming leftwards scrolling) you wouldn't need to plot the trailing blank to erase everything. Essentially you just keep track of the active columns, plotting rotated data in each. Actually, that's very clever!

I don't quite understand this though:

Forgot to mention that the software scrolling after 8 pixels as opposed to hardware after 8 pixels would require 9 copies of each tile requiring 7,632 instead of 6,784 bytes but no extra drawing.

Why 9 copies?

Also, I'm slightly puzzled that we didn't get the same tile pair count, though perhaps you were building the 2x2 blocks differently to me, or with a slightly different tile set. I treated bushes as different from clouds, and the 'insides' of clouds to be distinct from blanks.

Would be great to see your write up of this! And indeed any tools code you have for processing this stuff!

[tricky]

For software, I wasn't going to blank the right hand side of a span, I was going to draw the 9th frame, so for the right hand side of a block, the would still be 1 pixel their on the 8th shifted image, but by adding a 9th where it has been completely shifted out, I wouldn't need to remember it and blank it. Just a memory vs complexity vs time choice, but it does mess up the nice 64 bytes per 8x8 tile.
So software scrolling would be f1, f2, f3, f4, f5, f6, f7, f8, f9, move f2, f3, f4, while the other direction would be f8..f1,f8..f1.

My tiles are 2x1, that is 16x8 mode 4 pixels and where there is a floating floor with a mushroom on it, I painted over it with floor as I assumed that the mushroom would pop up when you jump into the under side of the floor, I guess I should play it and find out.

The inside of the clouds just fall out if the gaps have 2 consecutive empty 8x8s.

The tool is very basic, mostly add a for loop, dumping stuff and then comment it out again, but I am planning on publishing it with the write up. I would have done it tonight, but wanted to get a proper scrolling demo working - but time has run out as the misses is calling (not for the first time!).

[Rich Talbot-Watkins]

Sounds good! Looking forward to seeing what can come of this, even though it sounds like memory will be tight, particularly once animated sprites are added. I was thinking about it with purely 8x8 tiles (since there's often repetition, e.g. the brick blocks which are the same tile in a 2x2 block); I hadn't yet done the tests to see if it was actually advantageous to work with 16x8 (or indeed 16x16).

I definitely think MODE 4 is the right way to go with this - I don't think MODE 5 offers enough colours to make it worth losing the resolution. Now MODE 1 with colour interrupts every tile line would be interesting though, hmmmm...

[tricky]

OK, got a bit more time so added the hardware scrolling version, but rather than try and get the circular buffer of lda/sta working, I just re-decode all 32 columns every hardware scroll!
When it gets to the part that I said was the slowest to draw (and probably a few other places) it doesn't manage to fit in a frame and you get a few frames of jumping, there are also a few flickering bits in the clouds, but that would be easily fixable and as I say, it is doing 32 times too much map decoding.
I've only tried this on the emulators, but as it doesn't do anything fancy with the 6845 and doesn't even use a timer, it should be OK.
I'd also forgotten about blanking the last column when hardware scrolling, so bodged in a complete column clear just to slow it down a bit more!
I definitely prefer the idea of completely software scrolling and may give that a try over the weekend.
.ssd and updated source attached.

Now MODE 1 with colour interrupts every tile line would be interesting though, hmmmm...

Your turn
PS Off to have another look at R-Type

[tricky]

...How difficult or time-consuming is it to do this kind of stuff?...

To answer that and by way of a write up, here is a little story

It was about five hours, including half an hour going mad trying to work out why there was nothing on screen; it turned out that I had set both colours to black!
In that time, I:
- Hacked tga2equb to read in the map, convert it to 8x8 tiles and write them out again.
- Converted each tile to b/w in paint shop pro.
- Changed the program to find the tiles and generate a grid of which tile was used where.
- Used the grid to read in the tiles and write out the full mono image to check it worked.
- Then I started reading the mono map, which saved a couple of tiles.
- Tried out 16x8 tiles, but decided that with hardware scrolling, it would be fiddly as I would have to play 6845 tricks to hide a column and I wasn't ready to go that far for a demo.
- Tried the pairs of tile export (one displayed and the other the one immediately to the right of it.
- Wrote the code to export the single screen demo.
- Faffed around wondering why black on black looks like it isn't working.
That was about it for the first two evenings.
Last night, I started on the hardware scrolling code.
I just wanted to make it work, not be optimal as I really wanted to prove it viable before I got distracted by something else shiny!
After about 2 hours, the hardware scrolling was nearly working, but I had to go and spent time with the family
I got another hour session later and managed to get the hardware scrolling working. It is supposed to have a circular buffer of columns of lda/sta code where you overwrite the column just scrolled off with the new one, but to simplify the code, I just decode all 32 columns every time!
Once this was working, I noticed what RichTW had mentioned earlier that when something scrolls off that doesn't have its place on the screen overwritten with something scrolling on, it just pops its way across the screen; time for another bodge to clear the whole column each scroll - this could be optimised, but again, I just wanted it working.
So, with a bit of flicker and a section where it is just too slow, the demo was working and uploaded last night.

I have included all the code I used for image manipulation and mapping etc, it is in tga2equb and is the same program I use for converting all images and sprites for everything I do (except the map editor for the vertically scrolling demo). Each project gets a copy of this code that just reads a palette and image and iterates over it (basically a skeleton game folder that I just copy and paste before starting) - it just gets over that blank page "where do I start?" feeling.
I tend to add a section to generate some data and then comment it out and start on the next - it works for me!
I have added some comments to tga2equb.cpp, something I rarely do, except to note the source of information or an algorithm.
The config, os and tga files rarely change, but I did an a Tga copy constructor for this one to make using std::map easier!
The #define for ... is from the days when I wrote this (late nineties - VS6) and hasn't really changed for 20 years.
Why use TGAs? Well, because the code to load them is small and simple - this version only supports 24 and 32 bit uncompressed non-palletised but that is enough for me

I had a go at converting to mode 5, but I think RichTW is correct (as usual) that the loss of resolution isn't made up for by colour.
Don't worry about the (C), it is my company, please feel free to use my code for anything you like except selling it and don't blame me if it does bad things - I only wrote it.

[oss003]

Hi Tricky,

I like the Mode4 software scroll very much because it's easier to convert to the Atom .....

https://www.youtube.com/watch?v=DefWhE9_zz0

PS The video is really bad ... the original is better.

Greetings
Kees

[Commie_User]

Hmm, that's what I got as well, viewing Tricky's SSD on Beeb-EM (see video attachment).

That's fantastic on its own, given the Beeb was never built for Mario. No wonder there are some hair-raising long hours described above! (Wouldn't have his job for a fortune!) But will that long map scroll by in the next attachment? It's attached as a graphic and I can't wait to see it.

[tricky]

oss003, nice conversion , the only way to get good video playback on youtube is to upload at 1280x720+ 50/60p and then watch it back in "HD" to keep the 50/60 hz.
Commie_User, I didn't bother encoding the mode 5 map, but 4 posts up is the full mode 4 one

Watch in "HD" for 50fps https://youtu.be/wIpGNqCUgoY
The video is even more jumpy than the demo and that is bad enough!

[tricky]

Felt like 10 minutes (probably actually about half an hour!) to convert to full SW scrolling.
Still decoding 32 times too much, although updating the addresses wont be free.
Drawing takes from 16 scan lines off the bottom of the screen until about the top of the clouds and then about 2-8 scanlines to decode a column (currently every 8 frames).
I still think bidirectional scrolling will need 9 copies of a tile instead of 8 (nobody said it wouldn't), but this only slows the map decode down a bit.
Doing the floor separately and starting at the top of the floor would give plenty of time to draw, race the beam with the sprites, update the floor and update+decode the map.

Watch in "HD" for 50fps https://youtu.be/KCgjy3mtLBQ
The pauses in the video are due to the capturing process.
zip with .ssd and .asm attached, oss003, you could port now or wait until I have done the update code

PS Sorry for so thoroughly swamping this thread!

[Rich Talbot-Watkins]

On my phone at the moment so can't really look properly, but the video looks great! It's a shame you can't plot row by row as this would give you far time to get the job done without flicker - you could even start plotting when the raster is much higher up (assuming that it moves down more quickly than you're able to plot).

Still don't quite get the 9 copies thing. Either the tile is in its base position, or it's scrolled to offset 1-7 with a second tile on its way in. At offset 8, it's moved one position to the left and handled as part of a different column in its base position. When I was considering this, I was making a special case of the base position, to save duplicating the tile data in every tile which starts with the same tile number in the pair.

[tricky]

I don't plot an empty tile to the right of things, so when the right of something scrolls of the left hand side, there will be 8,7,6,5,4,3,2,1 pixels showing and then the last pixel will be left forever.
In my demo, I think I have 7,6,5,4,3,2,1,0 pixels showing which means 8 are enough, but scrolling the other direction, would leave one on the left.
I haven't tried it, so I may be wrong, but in my head, it is the same as leaving one blank pixel on the side of a self erasing sprite, which would be a better option if you were making your own level.
On phone too!

[oss003]

Great job Tricky, the software scrolling looks very good

oss003, you could port now or wait until I have done the update code

Almost there ........ just have to catch one bug ....
https://www.youtube.com/watch?v=rcbqY1X ... e=youtu.be

After that, I have to optimize the code because I now just write to the screen without concerning vsync or other timing.

Greetings
Kees

[tricky]

I'm not sure about the best way to update the addresses when the character scroll happens.
Inplace or moving the loads and stores and adding the new ones on the end.
Anyone up for the elk port

[oss003]

Ok, the bug has been killed ....
The demo is running fine now.



Greetings
Kees

[tricky]

Nice.

[Commie_User]

Yabba-dabba-Doo, mate!

That is FANTASTIC! Perfect scrolling. This CUB shot doesn't even do it justice:

MOV00121.MPG

(2.73 MiB) Downloaded 140 times

I know what to have up in the background for any fresh BBC snap or movie from now on. I'm just going to leave that rolling all night!

All it needs now is some music..

[Commie_User]

Yeah. I never thought the BBC had it in it to be so smooth. Doubtless with Mario and the rest chucked in, we'd have some jerkiness.

All the same, that smooth scrolling, those crisp graphics.. almost hypnotic. As a Commie guy, I've often loaded a micro just to sit and watch, or listen. So I really admire the crack programming to bring such to the humble Acorn.

I've seen how boringly long and tedious the machine can often take to draw a scene. Tape loading often has to literally halt until the loading screen is completed! And those things are static!