Arkanoid [WIP]

[+mksmith]

Holy cow, what an amazing first 7800 project post. mksmith, between Atari Dev Studio and this, you're on fire!

 

 

Do all the backgrounds tile like the screen you've captured? You could store the character indexes in a 4x4 rom table, and use that to restore tiles. For hit tables, I tend to use the characters themselves, but that means you'll either need a single tile counter variable to check when they're all gone, or you need to scan the characters to check that condition - this can be spread across a few frames, for minimal CPU impact.

 

 

You can do one of two things here. #1.Don't plot the background tiles on the lines with score info, since they're empty anyway. #2.Manipulate the background characters to draw the letters and digits you want.

 

#1 is the easiest. #2 is the hardcore way to minimize the number of objects you're updating in a frame. Salvo uses #2, but I'd say only use that method if you're pushing the number of moving objects hard.

 

 

Not sure. Certainly 7800basic can display sprites at the bottom of the screen. Here you might consider using characters and updating the background directly, since the code isn't that complicated.

 

 

Yeah, this is an outstanding bug. There's a rounding error somewhere I need to track down.

 

Double buffering would only help if you're dropping frames and getting object glitching as a result.

The background is an 8x4 tile area (4x8 pixels each) which is repeated across and down the screen (using a small index table). I then take the area where the bricks will be located and transfer that into ram and once I determine the offset of the brick I restore the tile (I'm storing the tile index). Certainly could go the other way and have another data table (like the background) to reference against.. As for the hittable most tiles require just the 1 hit, some 2 and some are indestructible so something dynamic is certainly easier to work with (I used a similar process for my Tower of Rubble on the 2600 with DPC+ ram). Is it recommended to maybe not use ram tables?

 

This is the code I came up with to build the background (I did just think overnight I can get back a couple of rows at the top as that brick area will always be blank)

initialiseGamePlayfield
 rem prepare
 gosub initialiseDataPointers

 rem copy playfield into screenram
 memset screenram 0 962
 memcpy screenram playfield 962 ; (37*26)

 rem copy background into backgroundram and screenram
 rem store the background (33x18) under the bricks allows us to restore it when we remove a brick
 memset backgroundram 0 594

 rem background area (33x25) - tile area (8x4) repeated
 indexY = 0
 for offsetY = 0 to 24
   indexX = 0
   for offsetX = 0 to 32
      rem find offset and get tile
      offset = indexX+(indexY* : tile = background[offset]
      tileX = offsetX : tileY = offsetY
      rem store in backgroundram?
      if (offsetY < 18) then pokechar backgroundram tileX tileY 33 18 tile
      rem adjust for actual screen location
      tileX = tileX + 2 : tileY = tileY + 1
      pokechar screenram tileX tileY 37 26 tile
      rem increment x
      indexX = indexX + 1 : if indexX > 7 then indexX = 0      
   next
   rem increment y
   indexY = indexY + 1 : if indexY > 3 then indexY = 0
 next

 rem bricks (11x18) - tile area (3x1)
 totalTiles = 0
 for offsetY = 0 to 17
   for offsetX = 0 to 10
      rem prepare
      offset = offsetX+(offsetY*11) : value = levelpointer[[offset]]

      rem store color in brickram
      brickram[offset] = value
      rem store hits in brickhitram
      brickhitram[offset] = 0
      if value = 0 then goto _skipAddBrick 
      if value > 0 && value < 9 then brickhitram[offset] = 1 :  ; single hits
      if value = 9 then brickhitram[offset] = 2           ; greys take 2 hits, 
      ;if value = 10 then then brickhitram[offset] = 0          ; yellow is unbreakable
    
      rem increment total count
      if value < 10 then totalTiles = totalTiles + 1
      
      rem reduce to get tile offset (actual) and add
      value = value - 1
      for index = 0 to 2
         rem get offset for brick data (3 tiles per brick)
         offset = (value*3)+index : tile = bricks[offset]
         rem adjust for actual screen location
         tileX = (offsetX*3)+index+2 : tileY = offsetY+1
         pokechar screenram tileX tileY 37 26 tile
      next

_skipAddBrick
   next
 next

 rem finalise (37x26) - convert original value to image value
 for tileY = 0 to 25
    for tileX = 0 to 36
        rem get tile and convert from tiled to image
        tile = peekchar(screenram,tileX,tileY,37,26) : tile = (tile-1)*2
        pokechar screenram tileX tileY 37 26 tile
    next
 next

 rem render
 clearscreen
 rem backgound
 characterset tiles_background1
 plotmap screenram 0 6   2 32 26  0 0 37
 plotmap screenram 0 134 2  5 26 32 0 37
 rem store
 drawscreen
 savescreen

As for the text it's a strange one as it fall off a cliff once it gets around 2/3 across a row especially further down the screen like where the ready and game over message is displayed. I think the full background is defiantly stealing away time. Certainly a great suggestion to plot those into background directly to help with that (or I could use a sprite image...). I'm always overly anal about presentation and spend way too much time on it!

 

Same suggestion with the lives - plot those directly into the background is a great idea as well!

 

Certainly 7800basic (and bB) are great for making your games come alive - thanks to people like yourself Mike for putting in the effort to provide this great platform. Really enjoyable!

Edited May 29, 2019 by mksmith

[+mksmith]

Oh for any coders out there - anyone got any suggestions on how I can minimise/pack a level table which I could 'unpack' whilst building the display to reduce rom use?

Some examples:

 data level1
 0,0,0,0,0,0,0,0,0,0,0
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0
 9,9,9,9,9,9,9,9,9,9,9
 5,5,5,5,5,5,5,5,5,5,5
 6,6,6,6,6,6,6,6,6,6,6
 2,2,2,2,2,2,2,2,2,2,2
 7,7,7,7,7,7,7,7,7,7,7
 4,4,4,4,4,4,4,4,4,4,4
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0 
end
 data level4
 0,0,0,0,0,0,0,0,0,0,0
 0,0,0,0,0,0,0,0,0,0,0
 0,0,0,0,0,0,0,0,0,0,0 
 0,0,0,0,0,0,0,0,0,0,0
 0,9,2,4,7,0,2,4,6,9,0
 0,6,4,2,5,0,4,2,9,6,0 
 0,4,7,5,2,0,6,9,2,4,0
 0,2,5,7,4,0,9,6,4,2,0
 0,5,2,4,6,0,2,4,7,5,0 
 0,7,4,2,9,0,4,2,5,7,0
 0,4,6,9,2,0,7,5,2,4,0
 0,2,9,6,4,0,5,7,4,2,0 
 0,9,2,4,7,0,2,4,6,9,0
 0,6,4,2,5,0,4,2,9,6,0
 0,4,7,5,2,0,6,9,2,4,0 
 0,2,5,7,4,0,9,6,4,2,0
 0,5,2,4,6,0,2,4,7,5,0
 0,7,4,2,9,0,4,2,5,7,0 
end

Edited May 30, 2019 by mksmith

[PacManPlus]

You now have awesome paddle control. They work wonderfully on the real thing.

Just so you know, the joystick left and right directions are the paddle 0 and 1 buttons, respectively.

So, to check for the paddle 0 button in the right port, you would see if the right 'joystick' is being pressed left.

Likewise, to check for the paddle 1 button in the right port, you would see if the right 'joystick' is being pressed right.

 

I like the effect when you pause the game as well. It turns black & white until you un-pause it. Nice touch.

[RevEng]

Is it recommended to maybe not use ram tables?

Nothing of the sort. The only reason I raised it was your RAM cart format was in your issues section.

 

But I forgot that blocks in Arkanoid have different durabilities, so you need to store that state somewhere.

 

It might also be possible to scrounge some memory back from the display list, and use that instead, if the DL is covering more objects than your game requires. But I wouldn't worry about that for now.

 

As for the text it's a strange one as it fall off a cliff once it gets around 2/3 across a row especially further down the screen like where the ready and game over message is displayed.

Not so strange on the 7800. Whenever you plot characters on top of characters, it blows through a lot of Maria's DMA rendering time.

 

That's why I was saying you can just move the background down 2 rows (and make it 2 rows smaller), so there's no background underneath them. Or do the direct character manipulation thing.

 

 

Certainly 7800basic (and bB) are great for making your games come alive - thanks to people like yourself Mike for putting in the effort to provide this great platform. Really enjoyable!

Glad you're making the most of it.

[+mksmith]

You now have awesome paddle control. They work wonderfully on the real thing.

Just so you know, the joystick left and right directions are the paddle 0 and 1 buttons, respectively.

So, to check for the paddle 0 button in the right port, you would see if the right 'joystick' is being pressed left.

Likewise, to check for the paddle 1 button in the right port, you would see if the right 'joystick' is being pressed right.

 

I like the effect when you pause the game as well. It turns black & white until you un-pause it. Nice touch.

Awesome thanks Bob not only for your code but your testing! And for the button mapping too - will look to get that into the next build. So hard to check this stuff when you cannot test it on actual hardware!

 

The pause mode I cannot take credit for (which does look great!) - I think Mike did that as part of 7800basic + you can override it with your own configuration!

[+mksmith]

Think we may have hit our render limits??

 

With both the paddle (all ball attached) the pill is totally clipped in that same zone. If I release the ball I get generally some partial clipping instead. I've tried removing the background and double buffering to no eval... but...

 

The good news is if I don't render the full width then the clipping disappears My playfield is 37 tiles across (you can do a max of 32 tiles across in one plotmap but I also need to do an additional 5 tiles with another plotmap for the remainder). Might need to scale things back a little...

 

The joys of programming

[RevEng]

Definitely looks like you're running out of DMA time there. With everything at 160B, you're throwing twice as many bytes at Maria as 160A.

 

You've already hit on squeezing the background a bit, which should be effective.

 

Some alternate thoughts, which you can discard if you like... You could also do 160B for the background of the bricks area, but use 160A for the areas above and below the brick area. You could still have the nice shaded 160B borders by plotting them with sprites instead, prior to your savescreen. All of that would give you back tons of DMA time, for more moving objects or less CPU time stolen by Maria. Multiple objects still might clip in the 160B area, but the sprites in that area should be smaller and move through the area quickly.

[gambler172]

On my Concerto,it does not work....i can move the player,but i do not see the playfield...it is black

[RevEng]

Are you using the a78 file or the bin? If you used the bin, try the a78 file instead.

 

My guess is that Concerto isn't correctly providing the RAM@4000.

[+mksmith]

Definitely looks like you're running out of DMA time there. With everything at 160B, you're throwing twice as many bytes at Maria as 160A.

 

You've already hit on squeezing the background a bit, which should be effective.

 

Some alternate thoughts, which you can discard if you like... You could also do 160B for the background of the bricks area, but use 160A for the areas above and below the brick area. You could still have the nice shaded 160B borders by plotting them with sprites instead, prior to your savescreen. All of that would give you back tons of DMA time, for more moving objects or less CPU time stolen by Maria. Multiple objects still might clip in the 160B area, but the sprites in that area should be smaller and move through the area quickly.

 

Thanks Mike. I'll have a play around with trying to change all the playfield to 160A - it's really the required brick colors that make everything a little more difficult. If i can arrange palettes 0-3 in 160A that can still give me the brick colors that should be a huge benefit then. The main part of the background is only one color also. The frame is the 3 shades of white (which I can use for the grey brick as well). I'd still like to try and keep 160B for sprites if I can. Going off to have a play!!

[RevEng]

If you don't mind going under the hood a bit, you could use 11x 160A sprites for each row of bricks. By modifying the line's DL structure, you can change any brick X position (ie. disappear it by moving it off-screen), it's palette, and its graphic.

[+mksmith]

If you don't mind going under the hood a bit, you could use 11x 160A sprites for each row of bricks. By modifying the line's DL structure, you can change any brick X position (ie. disappear it by moving it off-screen), it's palette, and its graphic.

 

Will see how this goes first - some basic assembly is about my limits Fingers crossed!!

[+mksmith]

So cannot go back to 160A for the background as plotmap appears to select 160A/160B based on the first tile and if you do 160A you can only use one palette. If using plotmapfile you can get the required colors but as that is stored in rom you can't change what is drawn. Even plotmap'ing 32 across (plotmap max) will occasionally still clip. If I go down that route then we are looking at only 9 bricks across (11 for NES and 13 for the Arcade). I think i'm locked into 12x8 (3 tiles of 4x8) per brick as 8x8 (2 tiles) would look too square and I can't go smaller height wise as the zones are 8 or 16.

 

I'll try plotting sprites down the sides next and see if that will help. I might also look at straight 160A for all sprites as well. The game requires too many colors!

 

The other option is look at keeping what I have and doing something different rather than a straight 'Arkanoid'...

Edited May 31, 2019 by mksmith

[RevEng]

So cannot go back to 160A for the background as plotmap appears to select 160A/160B based on the first tile and if you do 160A you can only use one palette.

Yeah, I was thinking you could tackle it in strips, with some duplicate graphics for 160A and 160B background sections. But that would still result in clipping when extra stuff is in the brick area.

 

If using plotmapfile you can get the required colors but as that is stored in rom you can't change what is drawn.

plotmapfile works with ROM or RAM. You'd just need to copy the ROM to your RAM buffer using memcpy first.

 

But you may run into disappointing results with that, for this game. Some of the Arkanoid levels have different brick colors on any one row. If you use plotmapfile to build such a level, under the covers it means each brick will have a single character buffer object with a single character in it, which means you'll blow through DMA time again.

 

This is why I was leaning toward the bricks-as-sprites implementation. I believe this game can be done with 160A background, 160A sprite bricks, and 160B sprites for the rest, pretty much as your screenshot, without DMA issues. You might even be able to do 13 bricks. Anyway, I'm open to helping with it, either here or PM. If you want to follow your muse in another direction, that's good too.

[PacManPlus]

I never did get to ask Propane13 how he was doing it: http://atariage.com/forums/topic/154267-something-else-im-working-on/page-1

 

I think making the bricks sprites might be the best option. I was (a while back) going to change the Space Invaders enemies to sprites (they are tiles right now) so that they can move in a 'wave' like the arcade does, but I decided to leave well enough alone.

[gambler172]

Are you using the a78 file or the bin? If you used the bin, try the a78 file instead.My guess is that Concerto isn't correctly providing the RAM@4000.

I used the a78 file

And yes,i know Concerto is not perfect.

greetings Walter

[+mksmith]

Yeah, I was thinking you could tackle it in strips, with some duplicate graphics for 160A and 160B background sections. But that would still result in clipping when extra stuff is in the brick area.

 

plotmapfile works with ROM or RAM. You'd just need to copy the ROM to your RAM buffer using memcpy first.

 

But you may run into disappointing results with that, for this game. Some of the Arkanoid levels have different brick colors on any one row. If you use plotmapfile to build such a level, under the covers it means each brick will have a single character buffer object with a single character in it, which means you'll blow through DMA time again.

 

This is why I was leaning toward the bricks-as-sprites implementation. I believe this game can be done with 160A background, 160A sprite bricks, and 160B sprites for the rest, pretty much as your screenshot, without DMA issues. You might even be able to do 13 bricks. Anyway, I'm open to helping with it, either here or PM. If you want to follow your muse in another direction, that's good too.

 

Mike,

 

thanks mate will give that a go over the next day or so (kids have basketball/sport all weekend so will try and squeeze it in). So to clarify should I pre-draw the sprites over the background (maybe even not draw any background under the brick at all??), save (and restore that) and then to remove the brick, redraw the background again over the top of the sprite? I think I tried drawing that many bricks each frame and it was a no go...

 

With the background I could go straight 160A and cut the shading down to two colors (white + 1 gray instead of the current white + 2 grays) for the border and use the 3rd color to do the main background (which for the NES graphics is 1 color). The remaining palette area (1-3) I can use for the sprites as well.

 

Once I do this we can see where were at. Also more than happy for you to take a look through the code too!

 

Sorry about my occasional lack of understanding - trying to figure my way through it!

Edited June 1, 2019 by mksmith

[RevEng]

Hi Matt,

 

No worries on the timetable. And you're coping remarkably well with a lot of new 7800 architecture info.

 

The order of operations would be to clearscreen, draw the 160A background, then draw 160A transparent/blank block sprites at every conceivable block position, and then savescreen.

 

At that point I'd sanity check that you can draw all of the moving elements you need in within one row of the block area without pooching DMA.

 

The plotting in 7800basic creates DL memory structures that Maria reads to draw the screen. We'll whip up a routine that will allow you to change a block's graphics/palette/x-coordinate in the DL structure. This will be much quicker than plotting sprites on the fly.

[+mksmith]

Hi Matt,

 

No worries on the timetable. And you're coping remarkably well with a lot of new 7800 architecture info.

 

The order of operations would be to clearscreen, draw the 160A background, then draw 160A transparent/blank block sprites at every conceivable block position, and then savescreen.

 

At that point I'd sanity check that you can draw all of the moving elements you need in within one row of the block area without pooching DMA.

 

The plotting in 7800basic creates DL memory structures that Maria reads to draw the screen. We'll whip up a routine that will allow you to change a block's graphics/palette/x-coordinate in the DL structure. This will be much quicker than plotting sprites on the fly.

Sounds good! Will let you know once we get to that point. Much appreciated ?

[DracIsBack]

Wow, excellent start on the port! Someone tried this like 8 years ago, but didn't get that far.

 

I think it was John Harvey. Also did some others like a Zelda type demo, and an adventure game called get lost, I think.

 

Edit: for historical purposes, heres the thread:

.

 

http://atariage.com/forums/topic/154267-something-else-im-working-on/

 

When I get out of the hospital and back to my 7800, cant wait to try this new Arkanoid build. Looks terrific!

Edited June 1, 2019 by DracIsBack

[DracIsBack]

Oops .. missed PacManPlus’s link.

 

I wish I had more technical know how to contribute. It’s fascinating to me to watch developers collaborate on solving specific technical challenges. Love just being a fly on the wall and learning. This version looks great MKSMITH!

[Jinks]

Hey Drac.

Make sure you gtfo of the hospital and back to your Atari!

[DracIsBack]

Hey Drac.

Make sure you gtfo of the hospital and back to your Atari!

 

Thanks Man. Looking like Tuesday for out of hospital and weekend for back to Atari 7800 haha

[+Mitch]

 

Thanks Man. Looking like Tuesday for out of hospital and weekend for back to Atari 7800 haha

 

Sorry to hear about that. I know what it is like, I was in the hospital for almost two weeks last month after my heart attack and it is definitely no fun.

 

Mitch

[DracIsBack]

Sorry to hear about that. I know what it is like, I was in the hospital for almost two weeks last month after my heart attack and it is definitely no fun.

 

Mitch

Oh my gosh, Mitch ... so sorry to hear this. Hope your recovery is going well! That’s got to be extremely scary.

 

Looks like mksmith has given two 7800 enthusiasts just what’s needed for recovery ... a new version of a favorite game on the platform!

 

Rest up, heal well! Love watching the discussion on how to piece this game together. Put in many hours playing this on the A8.