+mksmith Posted May 29, 2019 Author Share Posted May 29, 2019 (edited) 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 savescreenAs 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 3 Quote Link to comment Share on other sites More sharing options...
+mksmith Posted May 29, 2019 Author Share Posted May 29, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted May 30, 2019 Share Posted May 30, 2019 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. 7 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 30, 2019 Share Posted May 30, 2019 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. 5 Quote Link to comment Share on other sites More sharing options...
+mksmith Posted May 30, 2019 Author Share Posted May 30, 2019 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! 4 Quote Link to comment Share on other sites More sharing options...
+mksmith Posted May 30, 2019 Author Share Posted May 30, 2019 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 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 30, 2019 Share Posted May 30, 2019 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. 2 Quote Link to comment Share on other sites More sharing options...
gambler172 Posted May 30, 2019 Share Posted May 30, 2019 On my Concerto,it does not work....i can move the player,but i do not see the playfield...it is black Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 30, 2019 Share Posted May 30, 2019 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. Quote Link to comment Share on other sites More sharing options...
+mksmith Posted May 30, 2019 Author Share Posted May 30, 2019 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!! Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 30, 2019 Share Posted May 30, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
+mksmith Posted May 31, 2019 Author Share Posted May 31, 2019 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!! 1 Quote Link to comment Share on other sites More sharing options...
+mksmith Posted May 31, 2019 Author Share Posted May 31, 2019 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 31, 2019 Share Posted May 31, 2019 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. 4 Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted May 31, 2019 Share Posted May 31, 2019 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. 4 Quote Link to comment Share on other sites More sharing options...
gambler172 Posted May 31, 2019 Share Posted May 31, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
+mksmith Posted June 1, 2019 Author Share Posted June 1, 2019 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 1, 2019 Share Posted June 1, 2019 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. 3 Quote Link to comment Share on other sites More sharing options...
+mksmith Posted June 1, 2019 Author Share Posted June 1, 2019 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 ? Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted June 1, 2019 Share Posted June 1, 2019 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted June 1, 2019 Share Posted June 1, 2019 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! 3 Quote Link to comment Share on other sites More sharing options...
Jinks Posted June 1, 2019 Share Posted June 1, 2019 Hey Drac. Make sure you gtfo of the hospital and back to your Atari! 3 Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted June 2, 2019 Share Posted June 2, 2019 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 3 Quote Link to comment Share on other sites More sharing options...
+Mitch Posted June 2, 2019 Share Posted June 2, 2019 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 Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted June 2, 2019 Share Posted June 2, 2019 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. 3 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.