Kyle22 Posted January 10, 2014 Share Posted January 10, 2014 ... the size is bigger than a disk as such.. It will fit on a hard drive 2 Quote Link to comment Share on other sites More sharing options...
popmilo Posted January 10, 2014 Share Posted January 10, 2014 Kudos for going the cartridge way, opens up lots of great possibilities, and 5200 support sure is a nice thing. 'Loose' sprite multiplexing is also rarely seen on Atari. Didn't matter much for NES it seems and look how many great games it has. With perfect sprites we would get x amount of new games. With little flicker tolerance we could get x*2 of new games GTIA Blast seems to belong in the second group. Wish you all the best! 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 10, 2014 Share Posted January 10, 2014 Thanks Popmilo! Yes, you only ever get 2 multicolour sprites in the same horizontal space in any one frame. The multiplexer divides the screen up so that every 8 scan lines there are two multiplexer slots available - one for the player 0/1 sprite, the other for the player 2/3 sprite. When an attempt is made to draw a sprite it first looks at the player 0/1 slots - if all the slots it needs are free then it books them and updates the sprite data. If the player 0/1 slots weren't available it then tries the player 2/3 slots. The multiplexer interrupt is run from a POKEY timer and whenever it finds a booked slot it writes to the h/w registers. Everything is double buffered so that it can be preparing the next frame while displaying the current. The bullets are all missiles. The players are missiles 0 & 1 and are simply multiplexed as they never clash. The enemy bullets are the remaining missiles and are not currently multiplexed. In modes with good missile visibility (GTIA 9, ANTIC 2) they are used independently, in other modes they are overlaid to get the OR colour from the sprite colours. In poor visibility modes the missiles also alternate each frame between normal player colours and fifth player colour as that seemed to give better results. Paul, understood... but the interesting part is... the multiplexer checks that there are all slots used and sprites need to be rejected? and these rejected sprites... you need to mark them? or are you prior entering the multiplexer shuffling the sprites via your random table around so sometimes it checks sprite 10 sometimes 5 etc? but on your zone... maybe sprite 10 would be not in range anyway? in my sprite multiplexor examples here done ages ago... I was going the c64 approach... means sorting all sprites via y position (as I started with random movement and positions) then running down the screen, setting DLI near vsprite #0 ypos. puting vsprite #0 into slot 0, vsprite #1 into slot 1, vsprite #2 into slot 2 and vsprite #3 into slot 3. now first check appeared... if vsprite #4 would overlap vsprite #0 in that DLI zone it would be rejected and the next vsprite #5 would proceed... if same overlapping appeared... rejected again.... and if the next sprite would be far away from #0 I set DLI and proceed like prior until all done... so basicly in worst case (all 16 virtual sprites on same y-position) only vsprite #0 - #3 were shown as these are mapped to the hardware sprites. but I never managed to get the rejected sprites to be displayed... never managed to get the ring buffer ("Konami approach") concept implemented... that's why I am asking, as there might be a better concept. Quote Link to comment Share on other sites More sharing options...
potatohead Posted January 10, 2014 Share Posted January 10, 2014 This is great! Of course, there are always improvements. Well done so far. I would jam on it for sure. 1 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted January 10, 2014 Share Posted January 10, 2014 I make it short: Love the PMG-multiplexing Love the parallex background (even animated) However, not a fan of the GTIA modes as main background. Same as for TMR's game. Is this still test gfx? Maybe with better artwork the GTIA modes can be put to good use. I hope you surprise me For the first two points and the idea of using GTIA for background in a game: Great Work! 1 Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 10, 2014 Share Posted January 10, 2014 Paul, understood... but the interesting part is... the multiplexer checks that there are all slots used and sprites need to be rejected? and these rejected sprites... you need to mark them? or are you prior entering the multiplexer shuffling the sprites via your random table around so sometimes it checks sprite 10 sometimes 5 etc? but on your zone... maybe sprite 10 would be not in range anyway? I don't do anything with the rejected sprites - each frame the multiplexer processes the sprites in the order as specified in the next sequence in the random table. E.g. if sprites 5, 7 & 9 have the same y coord: frame 0: .byte 0,10,1,4,9,13,15,6,7,3,12,5,8,2,14,11,16 --- 9 and 7 are displayed frame 1: .byte 0,14,7,16,15,6,5,1,2,10,9,13,8,3,12,4,11 --- 7 and 5 are displayed frame 2: .byte 0,10,13,9,3,1,12,7,4,14,8,11,15,2,6,5,16 --- 9 and 7 are displayed frame 3: .byte 0,11,4,15,5,13,12,6,14,8,10,2,9,7,1,3,16 --- 5 and 9 are displayed etc... This seems to work ok and of course I am trying to avoid clashes wherever I can. 3 Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 10, 2014 Share Posted January 10, 2014 One way I'm aiming to minimise flicker is in my path tool (for the sprites which follow a vector path) I've used the same multiplexer logic so I can see what it's going to look like before it gets anywhere near the 8-bit. You can see the tool here: http://www.playsoft.co.uk/path.swf You can click around and draw a path, grab a point to move it and press T to toggle test mode. The values on the right are step size, gap between sprites and number of sprites. I still have some work to do on this as the points are calculated using the straight line distance but the bezier curve can be significantly longer especially around tight turns - it makes it look like the sprites speed up when they go round corners. 6 Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 10, 2014 Share Posted January 10, 2014 I make it short: Love the PMG-multiplexing Love the parallex background (even animated) However, not a fan of the GTIA modes as main background. Same as for TMR's game. Is this still test gfx? Maybe with better artwork the GTIA modes can be put to good use. I hope you surprise me For the first two points and the idea of using GTIA for background in a game: Great Work! Well, we all have different tastes. I could not be more pleased with the graphics which Harvey has come up with - my favourite is GTIA 9! 1 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted January 10, 2014 Share Posted January 10, 2014 One way I'm aiming to minimise flicker is in my path tool (for the sprites which follow a vector path) I've used the same multiplexer logic so I can see what it's going to look like before it gets anywhere near the 8-bit. You can see the tool here: http://www.playsoft.co.uk/path.swf You can click around and draw a path, grab a point to move it and press T to toggle test mode. The values on the right are step size, gap between sprites and number of sprites. I still have some work to do on this as the points are calculated using the straight line distance but the bezier curve can be significantly longer especially around tight turns - it makes it look like the sprites speed up when they go round corners. Uh.. that is (was) exactly my cup of tea I spent some time as student here: http://www.welfenlab.de/en/ I have written a tool to use different kind of splines (Monom, Bezier, B-Splines, ...) to model 2d-pathes (about the same as you did in Flash) Of course I use it now to pre-calc pathes exactl yas you do So my question, do you know what you need to solve the speed problem but it takes some time ti implement, or do you have to search how to solve the problem? I guess what you need is the re-parametrization of your spline into arc length. Not sure on this though, as it was almost 10 years ago 1 Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 11, 2014 Share Posted January 11, 2014 Uh.. that is (was) exactly my cup of tea I spent some time as student here: http://www.welfenlab.de/en/ I have written a tool to use different kind of splines (Monom, Bezier, B-Splines, ...) to model 2d-pathes (about the same as you did in Flash) Of course I use it now to pre-calc pathes exactl yas you do So my question, do you know what you need to solve the speed problem but it takes some time ti implement, or do you have to search how to solve the problem? I guess what you need is the re-parametrization of your spline into arc length. Not sure on this though, as it was almost 10 years ago Wow, a fantastic place to study and such a stunning building and grounds. I imagine the course itself was hard work though. I have not got around to trying to fix it yet, so thank you for the suggestion. If that is too complicated for me I'll try calculating the points as I do now but use them to determine the approximate length of the curve - I can then calculate the points again using this. I began this project to try 6502 programming again but I've probably done more ActionScript so far! Quote Link to comment Share on other sites More sharing options...
Creature XL Posted January 12, 2014 Share Posted January 12, 2014 I'll try calculating the points as I do now but use them to determine the approximate length of the curve - I can then calculate the points again using this. Excellent! that was it Thank you very much for the enlightenment. Determining the arc length involves integrating the spline functions. And I thought way to much work and discarded it. What you have proposed is, as you might know, an approximation to the integration. Which is sufficient enough considering that the positions are mapped to the (low resolution) screen anyhow. So I implemented it today and it works. I quickly modified "HitCEE" for a test. You see an NPC on a path over the screen. Alternating the "old" time-based parametrization and the "new" arc-length-based one. HINT: press "m" to mute music I now stop the thread hi-jacking. Further talk, if needed, should be done in the programming section. pathtest.xex 4 Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 13, 2014 Share Posted January 13, 2014 So I implemented it today and it works. I quickly modified "HitCEE" for a test. You see an NPC on a path over the screen. Alternating the "old" time-based parametrization and the "new" arc-length-based one. HINT: press "m" to mute music I updated my path tool too - before and after: Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 14, 2014 Share Posted January 14, 2014 It will fit on a hard drive And here is the RAMBO 1088K version of the demo which should run on U1M when loaded from the FAT32 partition using the SIDE loader. Thank you Kyle22 for suggesting that I support it and for testing it. ab1088k.xex 3 Quote Link to comment Share on other sites More sharing options...
kiwilove Posted January 14, 2014 Share Posted January 14, 2014 Back in the day - I remember about the 512k Rambo memory upgrade - never would have guessed that I'll be working on a game project that would require 1088K of RAM... Now all we need is to have Atari's approval - or for all those who support the hardware required to run AB! to distribute AB! as well, showing what their hardware can do... Harvey Quote Link to comment Share on other sites More sharing options...
Aking Posted January 14, 2014 Share Posted January 14, 2014 Ab1088k works like a dream... Running from any media ! 2 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted January 14, 2014 Share Posted January 14, 2014 And here is the RAMBO 1088K version of the demo which should run on U1M when loaded from the FAT32 partition using the SIDE loader. Thank you Kyle22 for suggesting that I support it and for testing it. It was actually an Incognito in an Atari 800 that I tested it on, not a U1M. It should work on both. You're more than welcome to send new revisions for testing, the pleasure is mine 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 22, 2014 Share Posted January 22, 2014 Wow, just wow! The background themes just rock and build on each layer, I love it when a solid coder gets it together. I loved watching my favorite Atari games and themes scrolling by as I wailed on the colorful bad guys. I felt invincible, well er 'cause I was invincible! Nice! I wonder what else is going to be crammed in there when it's finished. Awsome job. 1 Quote Link to comment Share on other sites More sharing options...
Poison Posted January 22, 2014 Share Posted January 22, 2014 WOW! It works on real HW with SIO2SD and Ultimate 1Mb !! Great shooting game. I like it very much:) 1 Quote Link to comment Share on other sites More sharing options...
TwiliteZoner Posted January 22, 2014 Share Posted January 22, 2014 This is great. Thanks. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 22, 2014 Share Posted January 22, 2014 I finally got even with those pac man ghosts, I blasted em to bits. 1 Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 22, 2014 Share Posted January 22, 2014 The background themes just rock and build on each layer, I love it when a solid coder gets it together. Credit for the design and content of the backgrounds must go entirely to Harvey. I just wrote the display code and a tool for designing them. I was amazed when Harvey sent me the GTIA 9 robot design. I felt invincible, well er 'cause I was invincible! Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted January 22, 2014 Share Posted January 22, 2014 Hello, the game looks and plays great ! I will be very happy when "Atari Blast" gets available on cart. and as a big fileversion. (Dreaming: Maybe you could create a big cart./ROM version of "Hawkquest" also ?) Since not every Atarian has 1MB RAM available or will buy the cart. (like I do), here are two suggestions to make the game maybe work with less memory. When looking at the data-segments I saw, that you mostly used $6000-7FFF or just 8k of the available 16k rambanks ($4000-7FFF), WHY ?!? 1) if you use the full 16k of the extra rambanks the game could fit in 576k memory (the current file has a length of 456k so it should fit into 64k RAM + 512k XRAM = 576k total memory). Or is there a certain reason, why you use only 8k of the available 16k extra rambanks ?!? 2) if you pack the program and the levels and store the levels (in packed form) into XRAM and only unpack/decompress the levels when required, the game could maybe work with 320k memory (64k RAM + 256k XRAM). I made a short test with Superpacker/Exomizer and packed one level, the 8k were packed down to less than 1.5 kbyte (originally $6000-7FFF was packed down to $6000-65xx). Of course this means a lot of extra work for the file version - but a lot more Atarians could play the game then I guess. This is not meant as criticism, just two suggestions/ideas to make the game work with less memory. I am no programmer, so it could be that you programmed the game intentionally as it is -or- I simply overlooked something (did not think about a certain programming or memory aspect). Greetings, Andreas Koch. 1 Quote Link to comment Share on other sites More sharing options...
Greg2600 Posted January 22, 2014 Share Posted January 22, 2014 Is the 5200 version being updated concurrently? Quote Link to comment Share on other sites More sharing options...
+playsoft Posted January 22, 2014 Share Posted January 22, 2014 Is the 5200 version being updated concurrently? Yes all three versions build from the same source code... it's write one get two free. 1 Quote Link to comment Share on other sites More sharing options...
Greg2600 Posted January 23, 2014 Share Posted January 23, 2014 Ok, so you're updating file on the 5200 thread? Wasn't sure. http://atariage.com/forums/topic/217200-something-new-gtiablast-5200-wip-for-ultimate-sd-cart/ Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.