Would "Raid on Bungeling Bay" be feasible on Atari 8-bit?

[+slx]

I stumbled over "Raid on Bungeling Bay" (for the C64) and played it on a C64 emulator (installed for the purpose as even in emulation I'm mostly loyal to Atari It certainly looks like something I would have enjoyed in my teenage Atari 800 years.

 

While my Atari programming skills are rusty at best and certainly not up to a task like this, I wondered if an Atari 8-bit port / recreation of this game would be technically feasible. It features a 10x10 screen wraparound map (reportedly programmed with tiles on the C64 to keep it within available memory).

 

Any guesses?

[+JAC!]

In fact that is exactly the type of game the Atari hardware can do more easily than any other (bidi scroll with pure hardware scrolling).

I have War Copter (1986, Red Rat) still on Tape and remeber I found it quite nice.

[+slx]

Thanks for the tip. I was not aware of war copter but it looks at least "inspired by" Bungeling Bay. Would it be possible to fit a bidirectionally scrolling map of 10x10 screens into memory using a "tiling" technique like on the C64 or would that require loading from disc (as in e.g. Seven Cities of Gold)?

Edited October 16, 2012 by slx

[TMR]

Would it be possible to fit a bidirectionally scrolling map of 10x10 screens into memory using a "tiling" technique like on the C64 or would that require loading from disc (as in e.g. Seven Cities of Gold)?

 

Theoretically at least, if it works on a C64 it should work on an Atari 8-bit - the only problem might be memory.

 

[Creature XL]

Thanks for the tip. I was not aware of war copter but it looks at least "inspired by" Bungeling Bay. Would it be possible to fit a bidirectionally scrolling map of 10x10 screens into memory using a "tiling" technique like on the C64 or would that require loading from disc (as in e.g. Seven Cities of Gold)?

Without calculation, I would say yes. Mighty Jill Off of has around 100 screens.

These use around 17Kb. And you can be sure that I used 2x2 char tiles. Using tiles is not that uncommon and not a speciality of the C64 game.

Maybe it was in the early 80s (TMR could comment on that ) but certainly not nowadays.

 

And I did not use any RLE or some such. So thre is potential for even more

At least when you go for 62Kb machines not 48Kb, which most developers did back in the day.

[+JAC!]

Well 10x10 screens (40x25) divided by 2x2 chars per tile = 100/4= 25k without packing. Not really a problem.

[+Philsan]

I think it would be a nice game for A8.

[andym00]

On 10/16/2012 at 6:18 PM, JAC! said:

Well 10x10 screens (40x25) divided by 2x2 chars per tile = 100/4= 25k without packing. Not really a problem.

Well, there's a lot more blocks in there than I imagined, which are going to need >8bits each block index.. And you missed out the amount of storage for the blocks themselves..

 

Had a boring afternoon today at work, so thought I'd do some conversion of the actual map, just to see..

So... There's 244 chars in the map.. 

2x2 Blocks = 2945 blocks..  Memory = 61780 bytes (blocks=11780, map=50000)
4x4 Blocks = 1695 blocks..  Memory = 39520 bytes (blocks=27120, map=12400)
8x8 Blocks =  662 blocks..  Memory = 45468 bytes (blocks=42368, map= 3100)

Those sizes aren't ringing true for me, doesn't seem plausible, and too big, bar the 4x4 one.. Lets try other some sizes..

3x3 Blocks =  2404 blocks.. Memory = 43714 bytes (blocks=21636, map=22078)
5x5 Blocks =  1213 blocks.. Memory = 38325 bytes (blocks=30325, map= 8000)
6x6 Blocks =  1026 blocks.. Memory = 42348 bytes (blocks=36936, map= 5412)
7x7 Blocks =   890 blocks.. Memory = 47600 bytes (blocks=43610, map= 3990)
10x10 Blocks = 393 blocks.. Memory = 41300 bytes (blocks=39300, map= 2000)

They're all a metric shitload of memory because of the need for 16bit block indices..

 

Given the amount of blocks generated here, I can't help but feel some other system might be in use, some kind of direction reversible RLE, or simply compressing large blocks, or possibly even sonic style blocks of blocks kind of thing..

 

Maybe he did just go with 4x4 or 5x5 blocks, can't tell without looking at the memory.. But after looking at the generated character maps, they look very very compressible..

 

Either way, you're looking in the ball park of 40K for your map and blocks, not including any character sets.. The C64wiki in RoBB does mention the maps came in at 34KB, but I don't quite see how.. That would only make sense if it was 5x5 blocks, and only an 8 bit block index, which doesn't seem possible..

 

Oh god, I must resist urge to write stupid things 

 

[Heaven/TQA]

Yeah sometimes we fall into

rabbit holes

[R.Cade]

I always figured this was one of those games that originated on the Atari 8-bit... 

[VladR]

On ‎9‎/‎5‎/‎2019 at 9:52 AM, andym00 said:

Well, there's a lot more blocks in there than I imagined, which are going to need >8bits each block index.. And you missed out the amount of storage for the blocks themselves..

 

Had a boring afternoon today at work, so thought I'd do some conversion of the actual map, just to see..

So... There's 244 chars in the map.. 

2x2 Blocks = 2945 blocks..  Memory = 61780 bytes (blocks=11780, map=50000)
4x4 Blocks = 1695 blocks..  Memory = 39520 bytes (blocks=27120, map=12400)
8x8 Blocks =  662 blocks..  Memory = 45468 bytes (blocks=42368, map= 3100)

Those sizes aren't ringing true for me, doesn't seem plausible, and too big, bar the 4x4 one.. Lets try other some sizes..

3x3 Blocks =  2404 blocks.. Memory = 43714 bytes (blocks=21636, map=22078)
5x5 Blocks =  1213 blocks.. Memory = 38325 bytes (blocks=30325, map= 8000)
6x6 Blocks =  1026 blocks.. Memory = 42348 bytes (blocks=36936, map= 5412)
7x7 Blocks =   890 blocks.. Memory = 47600 bytes (blocks=43610, map= 3990)
10x10 Blocks = 393 blocks.. Memory = 41300 bytes (blocks=39300, map= 2000)

They're all a metric shitload of memory because of the need for 16bit block indices..

 

 

 

Using 16-bit indices is great for an initial prototype phase. The version that you can always get back (via #ifdef flags) to (your reference rasterizer) when you spent too much time in your optimized version and it's getting hazy over the weeks how exactly did it work in the first place. But, it's lazy for a final release.

 

Figure out a way how to group the blocks into categories/areas/subdivisions - some kind of hierarchy.

 

Then, you need just 1 index of the category per certain amount of 8-bit data. If you used rows, then it's 1 byte per row, which is 25 Bytes per screen. That's a considerable saving.

 

If you could design the maps so that you'd have 3 rows of data from within area, then you'd need just ~8 additional Bytes per screen.

 

You get the idea.

[VladR]

On ‎9‎/‎6‎/‎2019 at 3:58 PM, Heaven/TQA said:

Yeah  sometimes   always we fall into rabbit holes

FTFY!

[andym00]

On 9/10/2019 at 4:39 AM, VladR said:

Using 16-bit indices is great for an initial prototype phase. The version that you can always get back (via #ifdef flags) to (your reference rasterizer) when you spent too much time in your optimized version and it's getting hazy over the weeks how exactly did it work in the first place. But, it's lazy for a final release.

 

Figure out a way how to group the blocks into categories/areas/subdivisions - some kind of hierarchy.

 

Then, you need just 1 index of the category per certain amount of 8-bit data. If you used rows, then it's 1 byte per row, which is 25 Bytes per screen. That's a considerable saving.

 

If you could design the maps so that you'd have 3 rows of data from within area, then you'd need just ~8 additional Bytes per screen.

 

You get the idea.

 

I get what you're saying, just thought I'd see what the magic numbers would be.. I had a good look through the map to see if there was some logic to it, but if there is it passed over me.. I did also take a look through the SimCity source code to see how he handled the maps in there, see if there was some magic that maybe saw inspiration in RoBB.. Couldn't see any there, in fact came away from trawling the SimCity source code amazed at how simple it all is, which reinforces my feeling that RoBB is dead simple..

 

It did occur to me almost immediately after posting that that with the 4x4 or 5x5 block you could just store the blocks as 12bits without much additional complexity, or even 11bits with a little more fiddling of bits, and then essentially at the 34KB figure mentioned in the wiki.. Watching some videos of it, I think its 5x5 blocks, judging by the way some things are animated on it when you blow stuff up.. Could be wrong, feels like a lot of the tiles are designed with a centre character in the tile in many cases..

 

I also wonder if the 'sea pixels' are drawn automagically on top.. I didn't try removing them from the map, but they probably bloat the block count substanially, maybe even getting it down to less than 1024 blocks on the 5x5 block size map..

 

It's one of my favourite games on the 64, and I'd love have time to get something running, but it's not going to happen form me, life is dominated by little human beings at the moment.. Another 14 years or so, and ship him off to Uni and then hopefully can get back into some 2030's retro programming

 

Edited September 12, 2019 by andym00

[+slx]

I'm intrigued by this detailed thoughts but have to admit I don't fully get it. Are all those 2x2, 5x5, etc. block sizes you mention referring to pixels or characters? Wouldn't anything but 8x4 pixel 4-color characters be immensely impractical to handle?

 

 

[Alfred]

yeah, I've been thinking about this too, and I don't get how you would do this. 10x10 is 100 screens is 96000 bytes. Ok, so you use tiles, but you still need the map of how to draw the "rooms" as it were. Now simple RLE will save you a lot with all that ocean space, but there look to be a lot of unique tiles as well. Disk access seems like a must or else a damned large cartridge.

 

Animating the jets seems problematic with a charset based background. It looks like you might need at least three, maybe all four players to animate the helicopter, which means a lot of duplicate characters to use a ground overlaid with jets. I wonder if bitmap mode wouldn't be a better method for the background; jets etc are then just an exercise in XOR.