Jump to content

Photo

GTIA Blast update

GTIA Blast

158 replies to this topic

#26 Kyle22 OFFLINE  

Kyle22

    River Patroller

  • 4,007 posts
  • Call my BBS! telnet://broadway1.lorexddns.net
  • Location:McKees Rocks (Pittsburgh), PA

Posted Thu Jan 9, 2014 9:26 PM

... the size is bigger than a disk as such..

 

It will fit on a hard drive :)



#27 popmilo OFFLINE  

popmilo

    Stargunner

  • 1,573 posts
  • Location:Senta, Srbija

Posted Fri Jan 10, 2014 12:45 AM

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!

#28 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 11,209 posts
  • Location:Baden-Württemberg, Germany

Posted Fri Jan 10, 2014 1:44 AM

 

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.



#29 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,404 posts
  • Location:Portland, Oregon

Posted Fri Jan 10, 2014 1:50 AM

This is great!

 

Of course, there are always improvements.  Well done so far.  I would jam on it for sure.



#30 Creature XL OFFLINE  

Creature XL

    Dragonstomper

  • 904 posts
  • Location:Hannover.De

Posted Fri Jan 10, 2014 6:24 AM

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!



#31 playsoft OFFLINE  

playsoft

    Moonsweeper

  • 370 posts
  • Location:UK

Posted Fri Jan 10, 2014 11:48 AM

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.



#32 playsoft OFFLINE  

playsoft

    Moonsweeper

  • 370 posts
  • Location:UK

Posted Fri Jan 10, 2014 12:22 PM

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.



#33 playsoft OFFLINE  

playsoft

    Moonsweeper

  • 370 posts
  • Location:UK

Posted Fri Jan 10, 2014 1:17 PM

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!



#34 Creature XL OFFLINE  

Creature XL

    Dragonstomper

  • 904 posts
  • Location:Hannover.De

Posted Fri Jan 10, 2014 1:24 PM

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 :(



#35 playsoft OFFLINE  

playsoft

    Moonsweeper

  • 370 posts
  • Location:UK

Posted Sat Jan 11, 2014 12:49 PM

 

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 :thumbsup: 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!



#36 Creature XL OFFLINE  

Creature XL

    Dragonstomper

  • 904 posts
  • Location:Hannover.De

Posted Sun Jan 12, 2014 5:10 AM

 

 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.

Attached Files



#37 playsoft OFFLINE  

playsoft

    Moonsweeper

  • 370 posts
  • Location:UK

Posted Mon Jan 13, 2014 5:55 PM

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 :)

 

:thumbsup: I updated my path tool too - before and after:

 

diff.jpg



#38 playsoft OFFLINE  

playsoft

    Moonsweeper

  • 370 posts
  • Location:UK

Posted Mon Jan 13, 2014 6:03 PM

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.

Attached Files



#39 kiwilove OFFLINE  

kiwilove

    Dragonstomper

  • 954 posts
  • Location:Dunedin, New Zealand

Posted Mon Jan 13, 2014 7:09 PM

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



#40 Aking OFFLINE  

Aking

    Moonsweeper

  • 379 posts
  • RetroLover
  • Location:Nintendo Switch and Atari Land

Posted Mon Jan 13, 2014 7:14 PM

Ab1088k works like a dream...
Running from any media !

#41 Kyle22 OFFLINE  

Kyle22

    River Patroller

  • 4,007 posts
  • Call my BBS! telnet://broadway1.lorexddns.net
  • Location:McKees Rocks (Pittsburgh), PA

Posted Mon Jan 13, 2014 9:47 PM

 

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 :)



#42 _The Doctor__ OFFLINE  

_The Doctor__

    Flux Capacitor Master Craftsman

  • 6,708 posts
  • Location:10-0-11-00:02

Posted Wed Jan 22, 2014 12:18 AM

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.



#43 Poison OFFLINE  

Poison

    Moonsweeper

  • 393 posts
  • Location:Czech Republic

Posted Wed Jan 22, 2014 12:23 AM

WOW! It works on real HW with SIO2SD and Ultimate 1Mb !! Great shooting game. I like it very much:)



#44 TwiliteZoner OFFLINE  

TwiliteZoner

    Dragonstomper

  • 691 posts
  • Location:Atlanta, GA

Posted Wed Jan 22, 2014 4:22 PM

This is great. Thanks.



#45 _The Doctor__ OFFLINE  

_The Doctor__

    Flux Capacitor Master Craftsman

  • 6,708 posts
  • Location:10-0-11-00:02

Posted Wed Jan 22, 2014 4:38 PM

I finally got even with those pac man ghosts, I blasted em to bits.



#46 playsoft OFFLINE  

playsoft

    Moonsweeper

  • 370 posts
  • Location:UK

Posted Wed Jan 22, 2014 5:39 PM

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!

 

:)



#47 CharlieChaplin OFFLINE  

CharlieChaplin

    River Patroller

  • 3,088 posts

Posted Wed Jan 22, 2014 5:47 PM

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.

 



#48 Greg2600 OFFLINE  

Greg2600

    River Patroller

  • 3,131 posts
  • Location:NJ

Posted Wed Jan 22, 2014 5:52 PM

Is the 5200 version being updated concurrently?



#49 playsoft OFFLINE  

playsoft

    Moonsweeper

  • 370 posts
  • Location:UK

Posted Wed Jan 22, 2014 5:55 PM

Is the 5200 version being updated concurrently?

 

Yes all three versions build from the same source code... it's write one get two free.



#50 Greg2600 OFFLINE  

Greg2600

    River Patroller

  • 3,131 posts
  • Location:NJ

Posted Wed Jan 22, 2014 6:07 PM

Ok, so you're updating file on the 5200 thread?  Wasn't sure.

 

http://atariage.com/...timate-sd-cart/






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users