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

GFA, ASM, STOS, ...

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

Post Reply
User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1426
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: 184
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: 1108
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: 411
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: 763
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: 3578
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: 184
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: 3578
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: 184
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: 3578
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!
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3578
Joined: Sat Jun 30, 2012 9:33 am

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

Post by dml »

While I haven't been posting much, a lot has been happening with this project in the background.

I have been reworking parts and adding new features, based on input from active projects and some recent experiments.

This also means the source is undergoing changes which require small updates to projects based on it - so if anyone has been tempted to play with this, it's probably best to wait until things settle down again. :)

I'll post some info on the more interesting changes soon.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2352
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

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

Post by calimero »

So there are few active projects using AGT? :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3578
Joined: Sat Jun 30, 2012 9:33 am

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

Post by dml »

While I can't say if/when they will be done, it does seem like more are on the way.

At least two of the existing mini-projects are still being worked on.

Some were started and paused for various reasons. Part of the problem has been documentation or updates not keeping up on my side (I didn't upload the first collision tutorial until very recently). Maybe we'll see more from those in future too.

It does take time to make even the smallest game and most people have limited free time to work on these things continuously. But can be a lot of fun to dip into it now and again :-)
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 184
Joined: Wed Jun 26, 2013 5:00 am
Contact:

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

Post by LaceySnr »

calimero wrote: Mon Jul 20, 2020 6:46 am So there are few active projects using AGT? :)
So mine was one of the ones that got paused (mostly because of work and kids), but it's not exactly abandoned either. Currently distracted with the Falcon but I'd love to get back into this for sure. Last progress was 3 years ago according to YouTube!
https://youtu.be/PZCgRPFrGDs
(buggered if I can work out how to embed this. Write code, sure. Use forums...not so much).
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3578
Joined: Sat Jun 30, 2012 9:33 am

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

Post by dml »

Wow.

I do still have an early working prototype of your 'Dave' code but I don't think I saw it this far along - definitely a big thumbs up from me!
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 184
Joined: Wed Jun 26, 2013 5:00 am
Contact:

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

Post by LaceySnr »

It was feeling pretty good in terms of the jumping etc. Once I've sorted out these BSP trees (almost there) I'll have to give compiling Dave a go again.
User avatar
Richard
Atari freak
Atari freak
Posts: 64
Joined: Sun Mar 09, 2003 3:47 pm
Location: UK
Contact:

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

Post by Richard »

Any further tips for settings up the environment? I thought I had followed the instructions, got cygwin installed, cygwin crossmint, copied the bin to my home folder and added the bin path to my bash profile. But following the instructions for how to compile tutor0, all I get is bash: make: command not found.

Any tips? I am useless at setting up these dev environments... not done it since trying to use a really old version of ansi C for doing some coding for a Prosoft ADM module.

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

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

Post by dml »

Hi Richard,

I think it is because the native GCC compiler tools are not installed under Cygwin by default (which provides the 'Make' tool).

If you install the 'gcc c++' package - any version - you should end up with make. (You can probably install it with less than that - but I know it works, so...).

I should add something about this on the wiki - I'm so used to make just being there :-)
User avatar
Richard
Atari freak
Atari freak
Posts: 64
Joined: Sun Mar 09, 2003 3:47 pm
Location: UK
Contact:

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

Post by Richard »

Ah ok, that makes sense. Will try that, I did search for the make and couldn't find it. Will add it to my cygwin install.

Many thanks!
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3578
Joined: Sat Jun 30, 2012 9:33 am

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

Post by dml »

The next thing you may run into is not finding 'agtcut' or 'rmac' or one of the other tools - so make sure the AGT bin/ directory is on your PATH env variable when the cygwin shell is started.

I think I did put that on the wiki - but it is worth a mention while I remember.
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 184
Joined: Wed Jun 26, 2013 5:00 am
Contact:

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

Post by LaceySnr »

FWIW Richard, while Cygwin does work, I find WSL to be a much more enjoyable solution for running *nix type stuff under Windows these days. It's pretty easy to get Vincent's toolchain up and running with that, and you can launch the windows hatari binary from the WSL prompt too. Maybe I'll setup again and write a blog post or something.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3578
Joined: Sat Jun 30, 2012 9:33 am

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

Post by dml »

It does make sense to move it away from Cygwin & Windows generally to get it working natively on Mac & Linux. It wouldn't be a lot of work at my end. But I do want to get some features and fixes finished first.

[edit]

I mean working on Mac & Linux without WINE - it can be used with WINE currently but would be preferable to have all native tools.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3578
Joined: Sat Jun 30, 2012 9:33 am

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

Post by dml »

I'll start posting feature update announcements here, prefixed with:

[UPDATE]


The first of which is: compressed assets

It is now possible to load compressed versions of tilesets, sprites & slabs and they'll be automatically decompressed at load time.

This one is obviously not a huge change, but it is very useful when testing on real machines with FDC emulators and only 720k of disk space!

Currently decompression happens at load-time but there are changes planned later which should allow packed assets to be configured as memory-resident / cached until needed when there is free memory to do so.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3578
Joined: Sat Jun 30, 2012 9:33 am

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

Post by dml »

[UPDATE]

The next small improvement is: dual-field sprites

It has always been possible to draw scrolling backgrounds using 2 colour fields in AGT (2 images with opposing dither, interlaced @ 50hz to simulate extra colours). But sprites were limited to 1-field, unless you swapped assets manually every frame. Which of course is silly.

Now you can cut EMS or EMX sprite format using '-ccf 2' for 2 colour fields and they will automatically be drawn in dual-field colour, if the playfield/arena is already configured for dual-field backgrounds.

If the sprite is cut with default settings (or -ccf 1) it will be single-field. If the playfield/arena is configured single-field, a dual-field sprite is drawn using only 1 field, dithered.

Easy! :)

I have updated the isoscroll & abreed demos to use this mode on the sprites since the BGs are already dual-field. However this isn't the best way to show it off so I'll probably create a separate sample for it fairly soon.


The cost of storing dual-field sprites is higher than single field of course. There are 2 copies of the 4-plane colour data. But masks are shared, along with any codegen involved (.EMX uses codegen, .EMS currently does not) so the increase in size for these in dual mode is relatively low.


Lots more to come.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3578
Joined: Sat Jun 30, 2012 9:33 am

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

Post by dml »

[UPDATE]

Might as well get this one out of the way - since I already posted a sample video...

It is now possible to draw EMS/EMX (fast) blitter sprites using widths greater than 32 pixels.

These formats are AGT's adaptations of Anima's fast blitter sprite method (not the very latest stuff, but quite close).

EMS supports vertical clipping (also horizontal clipping - but this has recently been turned off - more on that in a separate update) at moderate RAM cost.

EMX uses code generation, is the fasted method but with higher RAM cost. It is best for smaller sprites but can also be good for boss sprites with limited animation frames (too expensive to store otherwise).

The maximum width of these sprites is the display width (320) although other new features (more separate updates!) will impose a further limit of 240 pixels. Either way, sprites can be 'big'.

There are now two entity drawing paths for EMS & EMX in the engine. One is the standard path, which supports these big sprites and other extras. The second is a 'fast' path, intended for abundant, small sprites. These are still limited to 32 pixels and may be missing some features e.g. hitflash (still to be decided).

EntityDraw_EMSPR // feature path, big sprites
EntityDraw_EMSPRQ // fast path, small sprites

EntityDraw_EMXSPR // feature path, big sprites
EntityDraw_EMXSPRQ // fast path, small sprites


A 'blinky' mode has also been integrated with the existing hitflash feature, to support more Arcade flavour. This will probably see another minor update to make it more flexible, but is currently usable.
Post Reply

Return to “Coding”