[A]tari [G]ame [T]ools - 2D prototyping engine for STE

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1409
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by TheNameOfTheGame »

Seriously impressive stuff!

User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 166
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by LaceySnr »

Think I'm going to have to get back on this bandwagon!

User avatar
dma
Atari God
Atari God
Posts: 1044
Joined: Wed Nov 20, 2002 11:22 pm
Location: France
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dma »

Seriously huge sprites, amazing!

User avatar
AtariCrypt
Captain Atari
Captain Atari
Posts: 400
Joined: Fri Mar 14, 2014 5:04 pm
Location: Lancashire, England
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by AtariCrypt »

Man this is jaw-dropping stuff!! Great work :cheers:
AtariCrypt game website
https://ataricrypt.blogspot.com

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 689
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by Anima »

Great improvement! I would like to check it out as soon as there are some samples. ;)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3510
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

To explain - the 'slab' method was updated to cope with multiple spans per scanline. It is good for big shapes with a small number of large holes. Less so with large numbers of small holes. With the right shapes, it is the fastest method because long spans are not interrupted and only endmasks are used.

The sprite (EMS = data preshifts / EMX = codegen preshifts) method was updated to decompose bigger sprites into multiple components with a (blitter) destination width no greater than 48 pixels or 3 words (for the 3 endmasks). The main trick here, aside from finding the best decomposition, is making sure the 'waste' for the scrolled word remains constant even if the number of sprite components increases. i.e. don't overlap masks at the seams - use FISR to continue the scanline without masking.

This gets you an 80 pixel sprite for roughly equivalent cost of two 32 pixel sprites. You gain 16 pixels from amortization.

Some other optimizations are used to get NFSR active as often as possible, by looking at the rounded source/dest pixel width difference (good if the sprite is e.g. 24 pixels wide - you get 8 pixels of scroll with NFSR enabled) and there are some mask sourcedata optimizations.

Since the colour plane data is shared across all scroll preshifts, it becomes necessary to skip source lines in some of the components, some of the time. With a single component (or where all components agree), the colour data can omit the skipped lines entirely.

The EMS format can be clipped on the y axis. The EMX format cannot. But at the expense of more ram, EMX can optionally embed some EMS-shaped data to permit clipping on y, if the sprite crosses the guardband. This is up to the user. All x-clipping is now guardband based (it used to be physical clipping as well but I decided to simplify things). The guardband is now configurable.

There are still some good improvements which I think could be made to this and I might return to it - but for now I need to finish upgrading the collision system etc. :)

User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 166
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by LaceySnr »

Guess I'll pull the latest and see if I can get Dave building again. I can't remember the state I was in now, feel like it was working in Hatari but not on the STE or something like that. Of course, that's not to say it was your code rather than mine causing the problems :D

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3510
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

LaceySnr wrote:
Thu Jul 02, 2020 10:46 am
Guess I'll pull the latest and see if I can get Dave building again. I can't remember the state I was in now, feel like it was working in Hatari but not on the STE or something like that. Of course, that's not to say it was your code rather than mine causing the problems :D
Great! :)

TBH You would probably have to make some minor changes after recent updates. But if you are happy to zip it up and forward to me, I can probably do that for you and send it back.

The sprites will definitely need rebuilt because the format has changed but at least it now checks the format revision and gives you errors at loadtime.

I have been editing the wiki tutorials to match any changes but I'm not quite done with it yet, about half way through.

User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 166
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by LaceySnr »

Sweet. I'll give it a crack myself first when I find some time and see how I go, hopefully can at least give the tutorials some testing for you.

Need to stop playing in 3d first :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3510
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

LaceySnr wrote:
Thu Jul 02, 2020 12:55 pm
Need to stop playing in 3d first :)
;) I know what you mean!

Post Reply

Return to “Coding”