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

GFA, ASM, STOS, ...

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

junosix
Captain Atari
Captain Atari
Posts: 224
Joined: Sun Jul 08, 2007 3:22 pm
Location: Plymouth

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

Postby junosix » Thu Apr 27, 2017 8:05 pm

Dave the Dragon looks ace!

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12004
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

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

Postby wongck » Thu Apr 27, 2017 10:50 pm

LaceySnr wrote:I've been meaning to post about this for ages, but I've started working on a platformer using AGT. Stalled a little recently but will try and get back into it over the next couple of weeks. It's going to be called Dave the Dragon :) Here's an out of date screenshot, might post a quick test build at some point (there's not much to do right now apart from jump around and shoot ineffective fireballs :roll: )

Image


Awesome looking !! :thumbs:
My Stuff: FB/Falcon CT63+CTPCI_ATI_RTL8139 14+512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

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 Apr 28, 2017 2:04 pm

Over time I have been applying a lot of fixes and improvements to the agtcut tool - which was being updated in the repo source and bin/ directory. However the usage.txt documentation was lagging and the downloads area was stale. This has now been fixed.

penguin
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 109
Joined: Tue Dec 24, 2013 10:43 am

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

Postby penguin » Fri Apr 28, 2017 7:45 pm

I wrote about your engine in ST-Computer 02/16. A very exciting project - I wish I could send you (and a couple of other developers) back to the 80's :wink: There were just so many games that could've been better...

Anyway, if there are any game projects, I'll be happy to cover them in my magazine.
You do not have the required permissions to view the files attached to this post.
AtariUpToDate - Atari ST/TT/Falcon software database and version tracker: http://www.atariuptodate.de
st-computer magazine - http://st-computer.atariuptodate.de/

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 » Sat Apr 29, 2017 8:02 am

penguin wrote:Anyway, if there are any game projects, I'll be happy to cover them in my magazine.


That's great news! Thanks for following progress :cheers:

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 » Mon May 01, 2017 3:08 pm

So STF support was not only broken - but I hadn't added most of the files to the main repo. This caused it to go extra stale.

After a bit of editing & fixage to the engine at lunchtime i got tutorial #4 working on STF with minimal changes to the main program and some tweaks to the makedata config. I'm not sure that the startup code is fully clear of STE/blitter stuff but it should be - works in Steem at least. It doesn't exit cleanly though.

https://www.dropbox.com/s/j9d2d11fbk16w ... f.zip?dl=0

Tutorials 1-3 will need more specific fixes since they use low-level display/draw routines, where the later ones are all high-level and need fewer edits. Some of the demos use horizontal or multiway scrolling and will involve more work so those probably will be STE-only for a while longer.

I'll check in the current fixes soon though so at least the main tutorials will be ok on STF...

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 02, 2017 4:57 pm

Have added support this evening for entity layers (i.e. draw priority control).

None of the provided samples use it yet but they have been updated (minor) to work with the latest changes. The wiki docs have also been updated to cover this and other more recent changes in the entity system.

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 05, 2017 6:48 pm

I've been really busy recently but have made some progress on STF support while fixing various things for STE in the process.

Here are a couple of samples - STF versions of two of the STE game demos.

https://www.dropbox.com/s/5m4kferhzpoym ... d.zip?dl=0
https://www.dropbox.com/s/i049d7bxeoiw1 ... p.zip?dl=0

stf1.png

stf2.png


The abreed demo requires 2mb+ to run. The other one requires 1mb+. They will also explode most emulators, except recent Steem SSE versions (from about 3.8 onwards). Haven't tried Hatari 2.0x so can't say if that works or not.

Both use the LJBK hardscroll technique (see: 'beeshift') and therefore a 'bit' experimental. If you do get a smashed display, power cycle the ST and try another waitstate. For Steem, make sure you have chosen a real waitstate (i.e. not the default 'ignore' setting). I haven't had a lot of opportunity to test on HW so YMMV - however at least the software side is good for now.

Both demos are difficult tests for the AGT playfield system - one of them uses fractional/fixedpoint multiway scrolling with direction changes and scroll pauses - that's a bit of a nightmare for STs. O_o
The implementation is not final but i'll probably have to return to it when I have more time to do the last few improvements. The other one uses a less involved method for forced hscroll - but still not exactly straightforward. Obviously vertical scrollers are less complicated and cost less.

Both demos use 4 planes and 240 scans for everything (including the abreed sprites which do look <= 8 colour just because of the way they converted). No tile preshifting is used. No sprite preshifting is used. No generated sprites. So this is a performance 'worst case'.

Both run at 25-50hz depending on sprite count but I have locked the abreed demo to 25hz.

That's all for now.
You do not have the required permissions to view the files attached to this post.

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

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

Postby troed » Fri May 05, 2017 7:02 pm

dml wrote:Haven't tried Hatari 2.0x so can't say if that works or not.

Both use the LJBK hardscroll technique (see: 'beeshift') and therefore a 'bit' experimental. If you do get a smashed display, power cycle the ST and try another waitstate. For Steem, make sure you have chosen a real waitstate (i.e. not the default 'ignore' setting). I haven't had a lot of opportunity to test on HW so YMMV - however at least the software side is good for now.


A quick test on my devel version of Hatari 2.0+ (recent HEAD) indicates it does not work as intended (lots of bitplane shifts). Since Hatari does support the LJBK 4 pixel scroll [edit: It turns out I was completely wrong about this. Age is beginning to show ... :)] this surprises me a bit. If anyone tests this on real hw please report success rate.

Awesome to see someone making use of Paulo's hard work in that area!

/Troed
Last edited by troed on Sat May 06, 2017 8:14 am, edited 1 time in total.

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 907
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

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

Postby Frank B » Fri May 05, 2017 7:08 pm

That's seriously amazing! +1

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 05, 2017 7:13 pm

troed wrote:
dml wrote: Since Hatari does support the LJBK 4 pixel scroll this surprises me a bit. If anyone tests this on real hw please report success rate.
/Troed


TBH, it's easily possible I screwed something up - however It's not a 1:1 version of Paulo's synscroll. I had to modify it for overscan so maybe that has something to do with it? In any case I'll get a chance to retest later on my MegaST (it did used to work on that).

:cheers:

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 05, 2017 10:13 pm

dml wrote:
troed wrote:
dml wrote: Since Hatari does support the LJBK 4 pixel scroll this surprises me a bit. If anyone tests this on real hw please report success rate.
/Troed

Hi Hatari doesn't fully support all LJBK 4 pixels mode in all wakestates, this should be fixed one day (as it sometimes fails even on my STF for some WS I considered LJKB 4 pixel as "work in progress" and never really finished it for Hatari)

TBH, it's easily possible I screwed something up - however It's not a 1:1 version of Paulo's synscroll. I had to modify it for overscan so maybe that has something to do with it? In any case I'll get a chance to retest later on my MegaST (it did used to work on that).

:cheers:

Well, 2 news here : good news is that Hatari is right in not correctly displaying those 2 demos, emulation seems correct :D
Which means that bad news is that those 2 demos don't work on my 1 MB STF (I only tested h-shmup due to RAM limitation) :(

To sum it up on my STF :
WS4/WS2 : planes will shift sometimes by 2/4/6 bytes, maybe every 3 sec or so, but hard to tell which h-pos this represents
WS3 : planes are shifted much more often, but whole screen is also sometimes shifted by 160 bytes or so, some hardscroll combinations are clearly not good

Under Hatari, results are similar for WS2/WS4 (except the shifts happen much more often, so sthg should be improved in Hatari). Same for WS3, Hatari will also shift by 160 bytes but much more often too.

Doug, maybe you could provide a smaller test program where screen would scroll only on a key press and display the correspond h-pos ? This way I could tell you at which pos planes are shifted and this should point to the failing hardscroll values (a smaller program with just 1 tite repeated everywhere should be enough, and also much faster to test for me as it takes ages to write 400 KB on a floppy and then read it on the STF :) )

Nicolas

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 05, 2017 10:53 pm

Thanks for trying it. Well I gambled that I hadn't upset anything while reworking display code but looks like I have broken it. I recently added stabilising scans because code underneath uses movem and some muls so padding is needed to stop it flickering. Probably I moved something off and didn't notice. Will be easier to tell once I set up the actual machine again.

Unfortunately I think my CRT is still missing a cap - I was replacing them when I had to clear up the mess. I'll probably need to finish that next!

I'll make a separate test program for checking HW more properly after that's solved.

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 » Sat May 06, 2017 12:52 am

I discovered that I had accidentally removed the wakestate detect while looking for a IKBD issue :-/ so that might explain why it flaked on the STs.

However when I restored this, it still does exactly the same thing in Hatari. :-\

When I force the waitstate to each of the 4 values in my code (bypassing the detect), it does not react- as if the wakestate detection has no effect on the syncscroll. If I do this with Steem, however it reacts as you'd expect = wrong WS = broken display.

So I get the same result from Hatari no matter what patch state I apply to the code - or what waitstate I configure Hatari with. So I downloaded the latest snapshot, and got the same. This seems a bit suspicious - I should get different patterns of smashed bitplanes depending on WS configuration and syncscroll patching.

Playing with the code gives a bit more information - of the 4 shift offsets (0, 4, 8, 12) only 0 works properly. The other 4 produce an incorrect bitplane offset. It always seems to be the same bitplane offset for a given shift. It's very consistent.

So I tried the reference LJBK programs - beescn4 / beeshift - and they break in the same way with Hatari. Only 1 of 4 offsets works properly, in both programs.

Anyway I still can't vouch for the fixed code until I do test it properly - but it looks like 2 different things are going on here. A mistake on my part, and some problem with the LJBK sync tricks in Hatari generally. (?) I probably won't get to play with it much over the weekend but will see what happens.

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 » Sat May 06, 2017 8:03 am

dml wrote:So I get the same result from Hatari no matter what patch state I apply to the code - or what waitstate I configure Hatari with. So I downloaded the latest snapshot, and got the same. This seems a bit suspicious - I should get different patterns of smashed bitplanes depending on WS configuration and syncscroll patching.

Playing with the code gives a bit more information - of the 4 shift offsets (0, 4, 8, 12) only 0 works properly. The other 4 produce an incorrect bitplane offset. It always seems to be the same bitplane offset for a given shift. It's very consistent.

So I tried the reference LJBK programs - beescn4 / beeshift - and they break in the same way with Hatari. Only 1 of 4 offsets works properly, in both programs.

Anyway I still can't vouch for the fixed code until I do test it properly - but it looks like 2 different things are going on here. A mistake on my part, and some problem with the LJBK sync tricks in Hatari generally. (?) I probably won't get to play with it much over the weekend but will see what happens.

Hi
as I wrote earlier, Paulo's 4 pixel scroll is not correctly supported in Hatari at the moment (only 4 pixel working is the method used in "punish your machine" by ST Connexion). Note also that on my STF it works correctly only in WS2 and WS4.
Now that Paulo's 4 pixel scroll is used in "real" prod, I will give it another look, fixing it in Hatari should be rather easy.

So, don't expect your programs to work in Hatari at the moment :(

But still, there was an error in the "non 4 pixel" part of the hardscroll of your demos even on my STF ; having heavily improved Hatari to support all the tricks in "Closure" by Sync, I'm pretty sure that Hatari gives the same results as an STF on this part, which means that if you can test your demos using only 16 pixel horizontal increments, then hardscroll should be OK under Hatari in all WS, if not, this could show you which offsets give a bad result as on my STF.

Nicolas

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 » Sat May 06, 2017 8:31 am

Hi, thanks for the explanation. I thought all shifts were supposed to work in at least one waitstate. So that makes more sense then.

npomarede wrote:But still, there was an error in the "non 4 pixel" part of the hardscroll of your demos even on my STF


Are you referring to these recent 2 demos or the (much) earlier ones from a year or more back? I discovered last night that the recent two are missing wakestate detect so they will configure for (I expect) WS1 always. I'll update the zips for a retest soon and maybe it will start behaving better on the same machine.

Other than that - it is known not to be perfect anyway - the original bee screens do break on some waitstates on some STs (i've seen occasional glitches on my MegaST also). Opening the top/bottom border on top of that *might* make matters worse - although so far on my ST it seems to be equivalent. I'm sure we'll find out more later.

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 » Sat May 06, 2017 8:37 am

dml wrote:Are you referring to these recent 2 demos or the (much) earlier ones from a year or more back? I discovered last night that the recent two are missing wakestate detect so they will configure for (I expect) WS1 always. I'll update the zips for a retest soon and maybe it will start behaving better on the same machine.

I just tested those 2 recent demos, I think earlier ones worked, but I must admit I didn't check them recently, some regression sometimes happen in Hatari.

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

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

Postby troed » Sat May 06, 2017 8:39 am

dml wrote:Other than that - it is known not to be perfect anyway - the original bee screens do break on some waitstates on some STs (i've seen occasional glitches on my MegaST also). Opening the top/bottom border on top of that *might* make matters worse - although so far on my ST it seems to be equivalent. I'm sure we'll find out more later.


Yes, Paulo's scroll will unfortunately always fail for one shift in WS1 and sometimes in WS3. It's partly but not completely related to the GLUE/MMU wakestate though, since it's really a Shifter issue and the ways in which the Shifter can become desynced towards the MMU and GLUE seem to be much more complicated. (Which I found out when releasing Closure as well .. ). Besides the unreachable shifts, the "banded" (every other 16 pixels border color) state is very unstable as well.

However, top and bottom border openings are very "clean", only using a frequency shift which will not affect the Shifter. Only resolution switches do. While it still would depend on the implementation, there's nothing about Paulo's scroll which would prevent it from working fine with opened top/bottom borders :)

In some unspecified time when I find time for more in-depth research into this, and hopefully with Ijor's decap findings included, maybe improvements can be found. Or Paulo will surprise everybody with new findings as usual ;)

/Troed
Last edited by troed on Sat May 06, 2017 9:34 am, edited 1 time in total.

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 » Sat May 06, 2017 9:19 am

Ok I updated the zips with the fix - hopefully this will improve matters (?)

https://www.dropbox.com/s/i049d7bxeoiw1 ... p.zip?dl=0
https://www.dropbox.com/s/5m4kferhzpoym ... d.zip?dl=0

Any more than this will need to wait until I fix my CRT.

(only the tos/prg has changed)

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 » Sat May 06, 2017 10:21 am

dml wrote:Ok I updated the zips with the fix - hopefully this will improve matters (?)

https://www.dropbox.com/s/i049d7bxeoiw1 ... p.zip?dl=0
https://www.dropbox.com/s/5m4kferhzpoym ... d.zip?dl=0

Any more than this will need to wait until I fix my CRT.

(only the tos/prg has changed)

h-shmup in WS3 now works correctly, no more plane shift on my STF.
but on WS1/WS2, I still get the plane shifts from time to time as it was before (ie only max 6 bytes, not some 80 bytes or so)
I wasn't able to test WS4, seems my STF wasn't in the mood of reaching it today :)

Under Hatari, non-4 pixel part of the scrolling is now correct too, there's no more big shift. The remaining errors under Hatari are due to the missing support for Paulo 4 pixel-shift part.

Nicoolas

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 » Sat May 06, 2017 11:17 am

Thanks for the update. Is that after applying changes to Hatari today, or with yesterday's head revision?

And do I need to set anything specifically in hatari UI (other than WS3)

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 » Sat May 06, 2017 11:45 am

dml wrote:Thanks for the update. Is that after applying changes to Hatari today, or with yesterday's head revision?

And do I need to set anything specifically in hatari UI (other than WS3)

Sorry, I was not precise : both demos are still broken under Hatari dev, but at least now only the 4 pixel scroll is broken (so vertical part in alien breed should work the same under STF and Hatari in all WS), but for game using hscroll I still need to add support for Paulo's method. But the 2 bytes hardscroll in all WS should be the same under real STF and Hatari (as used in "Closure")

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 » Sat May 06, 2017 12:05 pm

Ok all is clear now.

What's extra weird is that SteemSSE 3.9.1 loses all keyboard input after the waitstate detect, where Hatari is ok with it. That's also going to need dug into :-/

...and it appears Steem displays the demos correctly even with the wrong WS value is forced instead of detecting it (it only messes up if 'Ignore' is chosen). This is why I didn't notice the detect was still disabled yesterday...

[EDIT] This problem goes away if I untick ' C1: 6850/6301/E-Clock' in SSE's 'extra options'. Another thing to confirm on HW.

MM41
Atari maniac
Atari maniac
Posts: 86
Joined: Sun Jun 28, 2015 2:36 pm
Location: France

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

Postby MM41 » Sun May 07, 2017 3:33 pm

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)

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 » Tue May 09, 2017 1:31 pm

dml wrote:Ok all is clear now.

Hi,
just to let you know that I updated Hatari devel version to add support for 4 pixels HW scrolling as used in beescrn4.prg by Paulo Simoes (in fact, my latest tests were with beescrl4.prg, which really didn't work well on my STF ; I never tested the more recent beescrl4.prg, but it works quite well on my STF (there's only one failing case in WS1), so I updated Hatari to support those switches as they can be considered stable now).
Hatari doesn't emulate "stabilizer switches" for now, so beware that a scrolling working under Hatari might fail on real STF (on the opposite, if it works on real STF, it should work under Hatari too)

You can compile your own version or get a binary version here http://antarctica.no/~hatari/latest/

With this, I confirm your 2 demos above are working correctly with all wakeup states.

Nicolas


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 1 guest