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

GFA, ASM, STOS, ...

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

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

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

Postby dml » Wed May 10, 2017 3:01 pm

Thanks Nicolas, that's helpful! I'll grab the new build before making any more changes.

I intend to add a WS detect notice on startup which should help make the whole thing more practical (at least until a 'perfect' version can be figured out, if its even possible!). Good news however that you're seeing similar results to myself so far.

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

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

Postby dml » Wed May 10, 2017 3:13 pm

MM41 wrote:STF-H-SHMUP tested with my MEGA1 and don't run normally sometimes (screen shifted), i don't control shuttle with keyboard.
When the demo loop the screen bug.

STF-ABREED not tested (sorry not enough memory)


Thanks for feedback.

The keyboard issue I saw in Steem already (didn't seem to affect Hatari so far) but it's very useful to know that it also affects real hardware. So it will need fixed next.

The horizontal demo doesn't loop properly - it can't scroll in reverse direction yet and the screen will show gaps or go black. That's just unfinished work (its expected).

I might attempt a 1mb version of the abreed demo so it can be tried properly on real machines. It can probably be made smaller especially if the overscan is dropped. It could easily be made smaller if the horizontal scroll rate is fixed at +/-1 pixel with no stops, or stops/turns on 16 pixel boundaries only - but it would change the behaviour of the demo quite a bit. A different demo is needed for that layout I think.

The screen will display shifted bitplanes in some power-on wakeup states on most (or maybe all) STFs but I'll add a splash screen to help identify which one is active and which are most reliable. I may eventually lock out one or more which prove too unreliable, or drift over time.

User avatar
troed
Atari God
Atari God
Posts: 1213
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

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

Postby troed » Wed May 10, 2017 4:20 pm

FWIW, the result of Paulo's research into this 4 pixel sync scroll was that:

*) One offset (sorry, don't remember if it was -4 or -12) will always fail in WS1
*) The same offset will sometimes fail in WS3

In other wakestates all four offsets should work all the time. However, since this has been tested with only 3-4 machines in total, I think, it's possible that it's not complete*.

My own take on this is that there's a Shifter instability needed for that offset which cannot happen in WS1, and might sometimes not happen in WS3. The wakestates describe a specific clock cycle offset between the GLUE and MMU, and while that affects the Shifter it's not a 1-1 match. I.e, there are other ways the Shifter can be offset from both the MMU (through LOAD) and GLUE (through resolution switches).

So for gaming, when the wakestate detection code sees WS1 it should really tell the user to power cycle the computer. When detecting WS3 it could scroll the screen and tell the user that if it's not looking ok they should power cycle as well.

/Troed

*) WS1/WS3 seem to be the most common wakestates on 8.02MHz STFMs. WS2 seem to be a bit more common on 8.01MHz STF/Mega. However, this is from my own notes and is based on quite a small sample of hw.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

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

Postby npomarede » Wed May 10, 2017 6:08 pm

troed wrote:FWIW, the result of Paulo's research into this 4 pixel sync scroll was that:

*) One offset (sorry, don't remember if it was -4 or -12) will always fail in WS1
*) The same offset will sometimes fail in WS3

I confirm, on my STF beescrn4.prg will always fail on the 1st shift in WS1 (the first time you press the alt key). All others scrolling combinations work in all WS, even WS3, but maybe it's just my STF which is being nice :)

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

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

Postby npomarede » Wed May 10, 2017 9:59 pm

dml wrote:The keyboard issue I saw in Steem already (didn't seem to affect Hatari so far) but it's very useful to know that it also affects real hardware. So it will need fixed next

Just to let you know that I had no keyboard issue on my STF, I was able to move the ship as usual. Either the problem is related to some specific STF/STE HW, or it's random (but in my case it always work) ?

ijor
Hardware Guru
Hardware Guru
Posts: 3138
Joined: Sat May 29, 2004 7:52 pm
Contact:

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

Postby ijor » Thu May 11, 2017 1:50 am

troed wrote:FWIW, the result of Paulo's research into this 4 pixel sync scroll was that:

*) One offset (sorry, don't remember if it was -4 or -12) will always fail in WS1
*) The same offset will sometimes fail in WS3

In other wakestates all four offsets should work all the time. However, since this has been tested with only 3-4 machines in total, I think, it's possible that it's not complete*.

My own take on this is that there's a Shifter instability needed for that offset which cannot happen in WS1, and might sometimes not happen in WS3. The wakestates describe a specific clock cycle offset between the GLUE and MMU, and while that affects the Shifter it's not a 1-1 match. I.e, there are other ways the Shifter can be offset from both the MMU (through LOAD) and GLUE (through resolution switches).


If the behavior is "stable", meaning that is constant until the next power cycle, then it is most likely caused by a Shifter wakeup.

*) WS1/WS3 seem to be the most common wakestates on 8.02MHz STFMs. WS2 seem to be a bit more common on 8.01MHz STF/Mega. However, this is from my own notes and is based on quite a small sample of hw.


My guess is that this probably depends on the specific version of GLUE and MMU.

User avatar
troed
Atari God
Atari God
Posts: 1213
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

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

Postby troed » Thu May 11, 2017 4:42 am

ijor wrote:If the behavior is "stable", meaning that is constant until the next power cycle, then it is most likely caused by a Shifter wakeup.


Indeed there "should" be two Shifter-MMU wakeups possible (and maybe four Shifter-GLUE with regards to resolution-changes). This might be hijacking the thread a bit - maybe we should continue separately :) I think the LOAD-wakeup (Shifter-MMU) would be the one responsible for either allowing the -4/-12 (still haven't checked, sorry .. ) persistent state in WS3, or not.

WS1, which from a programmatic view is the one that's most like STE (i.e, with GLUE-MMU perfectly in sync), likely cannot reach that state - regardless of which of the two speculated Shifter-MMU wakeups. One of the WS3 wakeups would then not either. This is related to your investigation into when clear-on-LOAD happens or not.

/Troed

ijor
Hardware Guru
Hardware Guru
Posts: 3138
Joined: Sat May 29, 2004 7:52 pm
Contact:

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

Postby ijor » Thu May 11, 2017 1:31 pm

troed wrote:Indeed there "should" be two Shifter-MMU wakeups possible (and maybe four Shifter-GLUE with regards to resolution-changes). This might be hijacking the thread a bit - maybe we should continue separately :) I think the LOAD-wakeup (Shifter-MMU) would be the one responsible for either allowing the -4/-12 (still haven't checked, sorry .. ) persistent state in WS3, or not.


There are four MMU-Shifter wakeups, not two. Shifter-GLUE wakeups are just another way to see the combination of MMU-GLUE and MMU-Shifter wakeups. That is, for a given GLUE-MMU (or as you sometimes like to call them CPU-GLUE) wakestate, WS1 to WS4, there are four possible Shifter wakestates. There are no additional GLUE-Shifter wakeups for a given GLUE-MMU WS.

As far as I know so far, that makes a total of 16 possible combinations.

... speculated Shifter-MMU wakeups.


I wouldn't use the term speculated. I measured them and, as you know, it is possible to see them, but not to detect them programmatically.

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

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

Postby dml » Fri May 12, 2017 2:33 pm

A quick update...

I have recently pushed out a preview version of AGT v0.3 with STF support and improvements for STE. It's not on the default branch yet but will be soon, once I'm more sure its all ok.

Only a few of the samples can be built currently for STF, and it currently requires VASM selected in the Makefiles (RMAC version of the source hasn't caught up yet as most of the base STF code was written earlier):

Working STF samples include:

demos/h-shmup
demos/abreed
tutorials/tutor3d
tutorials/tutor4g

I probably won't port all of the samples to STF - at least not just now - it's extra effort to maintain the files when something changes. Also not all features from STE are available for STF (e.g. blitter slab drawing used by demos/bosscore).

tonma
Retro freak
Retro freak
Posts: 14
Joined: Sun May 08, 2016 8:10 am

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

Postby tonma » Fri May 12, 2017 2:57 pm

Good news. With basic tutorials, we can already have fun and I think that's enough. I will not bother those waiting for a STE version. :-D
I'll test the new version when you'll push it (emulator only)

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

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

Postby dml » Fri May 12, 2017 3:22 pm

Great! You can get it now if you pull the 'arc-stf' branch. I'll merge it to 'default' soon.

[EDIT] Added a tag for v0.3 here: https://bitbucket.org/d_m_l/agtools/downloads/?tab=tags

Any existing home-made projects unfortunately do need edited to work with the new interfaces but the changes are very minor - delete some old calls from the mainloop, add a couple of new equivalents instead. Change a parameter on the playfield/arena defs. That's all I think. I'll detail the changes properly on the wiki - the repo demos/examples/tutorials all contain those changes already though so you can just compare old/new and see the diffs.

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

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

Postby Anima » Fri May 19, 2017 5:32 am

Just a short note: I've got an error on the post build event while compiling the "agtcut" tool. Copying the result to "C:\FalconVFS\share\N\AGTsource\bin\." fails.

tonma
Retro freak
Retro freak
Posts: 14
Joined: Sun May 08, 2016 8:10 am

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

Postby tonma » Fri May 19, 2017 8:15 am

Hi.
I reinstalled my cygwin to test.

I tested the stf with h-shmup but I have a compilation error. I changed in makefile: all: ste to all:stf
I checked on the github but not find the directory rmac/stf/

Code: Select all

    Il faut refabriquer la cible « ../../rmac/stf/pflib.o ».
make: ***  Aucune règle pour fabriquer la cible « ../../rmac/stf/pflib.o », nécessaire pour « stf ». Arrêt.

I cans send you all the debug info if you want.

The script "makedata-stf.sh" works well.

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

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

Postby dml » Fri May 19, 2017 8:24 am

Hi - sorry but you'll need to change the assembler type from RMAC to VASM at the top of the makefile, for the ST projects - I haven't ported the asm code yet to RMAC for the ST=specific code (not a huge job but I've been busy with other stuff too!).

tonma
Retro freak
Retro freak
Posts: 14
Joined: Sun May 08, 2016 8:10 am

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

Postby tonma » Fri May 19, 2017 9:10 am

:oops: Sorry, I forgot that you already said it

The compil works fine but I have glitch on emulator : I tried steem, steem sse and hatari for stf version
Image

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

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

Postby npomarede » Fri May 19, 2017 9:15 am

Hi
for Hatari, it won't work under Hatari 2.0, you will need to compile the latest dev version.

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

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

Postby dml » Fri May 19, 2017 9:16 am

tonma wrote::oops: Sorry, I forgot that you already said it

The compil works fine but I have glitch on emulator : I tried steem, steem sse and hatari for stf version
Image


I think the last version of Steem I tested as working ok was 3.9.1. Probably from 3.8.2 onwards is ok.

(I think I stated 3.8.0 earlier but that was wrong)

Also you need to make sure the WAKEUP state mode is configured to e.g. WS2 or something before starting the prg - it defaults to 'Ignore' and will not work that way.

tonma
Retro freak
Retro freak
Posts: 14
Joined: Sun May 08, 2016 8:10 am

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

Postby tonma » Fri May 19, 2017 9:42 am

Yep, thanks again with the WAKEUP state it's working fine.


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

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

Postby dml » Fri May 26, 2017 4:08 pm

I have added a number of useful new features recently but haven't posted much here. The WIki has however been updated with the most important changes.

A lot of it relates to debugging, diagnostics, logging etc. However some relate to game & AI features too. If I get time soon I'll post a summary.

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

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

Postby dml » Tue May 30, 2017 2:05 pm

Here's a summary of the (more significant) changes since the initial 'release'. Some are mentioned at the start of the thread but were new or just being completed at that time. The rest are new.

- entity tracking support, for missiles, chasing/revenge behaviours etc.
- entity lifespan/revision tracking for AIs left pointing at recently killed entities (e.g. hierarchy parents or targets)
- entities now have dynamic draw priority control, so draw order can be set in the dictionary or from within AIs
- entities can be spawned into levels 'dormant' using VISTRIGGER attribute, which wake up on contact with viewport edge
- support for 16x16 and 8x8 tilemaps
- support for single or two-layer maps, with 2nd layer masked on top of 1st
- support for live editing/animating of maps while tiles are being displayed (both layers)
- choose bounding-region or full-viewport refresh scanning of edited map tiles (edits are tracked individually with a bitmask, but scanning of the bitmask can be further optimised with a bounding region if edits are not being done in bulk)
- support for reading maps or arbitrary data from .CSV files
- support for parsing game objects/map placements etc. from .XML files
- support for defining maps using different data sizes (byte/word/long) e.g. for user-defined collision maps
- added basic support for STF platform (limited featureset vs STE - partly technical, mostly lack of time & demand!)
- some improvements and simplifications to common interfaces
- various optimisations
- much improved debugging tools:
+ builtin text console, displayed in lower border (limited to 6 text lines currently), accessed via TAB or toggled with SHIFT+TAB
+ console output additionally to Hatari natfeats or Steem Boiler (caution! Boiler log system works *ONLY* with Boiler - bus error on everything else)
+ builtin sampling profiler with user-defined profiling tokens. output goes to AGT console or Hatari/Steem log.
+ improved safety checks on entity management (spawning from dead objects, killing an object twice etc. etc.)
+ 'testing' builds produce 'release'-like optimised code but with safety checking and prints retained
+ 'release' builds now suppress most prints, debugging & dev functionality
- added standalone/static-linked version of PhotoChrome tool (no more DLLs needed!)
- agtcut updated to stitch multiple source images together when cutting 'page-flip' game maps
- agtcut updated to conduct palette and colour remapping review/summary when remapping assets, so you can see what gets remapped and how
- agtcut updated to extract map sub-rectangles while extracting all tiles, allowing tile index order to be 'fixed' or made stable outside of the active map area - mainly for animation, doors, placements & other coded fx which need to survive frequent edits to the art.

There are plenty of other, smaller changes but this gives a decent idea of what's been added. I'll post screenshots of various features working as I find the time...


User avatar
Ragstaff
Atari Super Hero
Atari Super Hero
Posts: 610
Joined: Mon Oct 20, 2003 3:39 am
Location: Melbourne Australia
Contact:

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

Postby Ragstaff » Wed May 31, 2017 11:03 am

Yet again, at the risk of just putting a half-hearted "nice work bro" in this thread, really, nice work! Imagine if we had this instead of STOS or SEUCK back in the day! The STE could have been a different platform (although I know the PC's to run the PC side of all this were nowhere near as powerful back then)


User avatar
mrbombermillzy
Atari maniac
Atari maniac
Posts: 98
Joined: Tue Sep 13, 2016 9:24 am

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

Postby mrbombermillzy » Wed May 31, 2017 8:38 pm

I know Ive said some sort of 'well done' before on the last AGT thread and it may be a while before I get to use this great tool, but;

Seriously Doug, like ragstaff said, this is awesome stuff. You have put so much effort into something that you have made free for others to use without 'black box' or obfuscated code... God, if only we had you, exxos and the other hardcore Atari elite here doing this stuff in 1987, the PC wouldnt have got a look in! (Dare I say it, but the other machine that begins with 'A' seems to have had its arse whipped by the STE too! ;) )

Keep up the amazing work!! :)


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 2 guests