8-way scrolling system for prototyping games on STE

GFA, ASM, STOS, ...

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

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Thu Apr 14, 2016 4:39 pm

TheNameOfTheGame wrote:Awesome! Can't wait to see the new code in action!


:cheers:

I'm gradually getting the source into decent shape to put up on BitBucket with the tool code. There are still quite a few things missing but they can be added in steps.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Fri Apr 15, 2016 11:00 pm

First test of properly clipped blitter sprites with BG restore on 320x240 hscroll (machine = STE)

https://dl.dropboxusercontent.com/u/129 ... prites.zip

This routine makes use of FXSR/NFSR and sprite pixel width estimates to cull redundant blitter reads - but I think its still being wasteful with the masking pass. Will look at other ways to improve this later on. Still its around 2x the speed of the non-preshifted software routine so its being useful.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Fri Apr 15, 2016 11:07 pm

I think I'll try to focus a bit on STE, fleshing out missing areas and tidying up the code for a release. The STF stuff is interesting but its 3x the effort and every change can break other stuff which then needs retested on both. Trying to do both platforms at once is taking a lot longer. I think there's enough done on the STF side now to leave some details for fixing later on.

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

Re: 8-way scrolling system for prototyping games on STE

Postby TheNameOfTheGame » Sat Apr 16, 2016 4:46 am

That's amazing stuff! Just checked it out and it's silky smooth scrolling with blazing sprites! Amiga-who? :mrgreen:

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 871
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: 8-way scrolling system for prototyping games on STE

Postby EvilFranky » Sat Apr 16, 2016 8:44 am

Looks great Doug, so how much free CPU time is there in the STE version?

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Sat Apr 16, 2016 9:25 am

Most of the time is now used up drawing sprites with the general-purpose sprite drawing/clearing functions.

However there are some alternatives planned for case-specific sprites e.g. bullets, slabs, props, layers and other things that are faster to draw for specific things but less general-purpose. e.g. if you want a bit of the map to move, you wouldn't want to use the sprite routine as it's far too wasteful.

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 871
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: 8-way scrolling system for prototyping games on STE

Postby EvilFranky » Sat Apr 16, 2016 9:50 am

Even if a final game production using it ran into the 2nd VBL, it would still be quite amazing really.

Wonder if Bod could benefit from the technique with his R-Type conversion...I believe he open sourced the code?
Last edited by EvilFranky on Sat Apr 16, 2016 9:51 am, edited 2 times in total.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Sat Apr 16, 2016 10:13 am

Well I'm hoping it can be used to get game mockups done with good speed and lowish pain, and run in 1 or 2 vbls. Its always hard to make a strictly 1-vbl game on STs with much going on and it will involve some compromises but I'll do what I can to make it as easy as possible for anyone with the patience to have a go. If the end result is some game prototypes being made for 2vbls then its been useful - that should be enough cpu time to do a fairly complex game.

I do plan to include some simple 1vbl mockups as a guide to using the source libraries though. Hopefully that will be the fun part :)

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Mon Apr 18, 2016 6:11 pm

Here's a bit of progress - a quick demo showing a new method for drawing giant sprites on the scrolly playfields. STE-only for now (STF version would be a lot more coding). And no clipping yet.

https://dl.dropboxusercontent.com/u/129 ... method.zip

This one is 2 VBLs but most of the time is spent saving/restoring the background under the sprite. The background scroll & sprite draw takes about 0.75VBL. Will look at a new method for save/restore later also...

that's all for now.

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 871
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: 8-way scrolling system for prototyping games on STE

Postby EvilFranky » Mon Apr 18, 2016 6:45 pm

So is it faster to draw 1 huge sprite like this rather than lots of smaller ones like player/bullets/enemies Doug?

User avatar
bear
Atari freak
Atari freak
Posts: 53
Joined: Fri Jul 02, 2004 4:44 pm

Re: 8-way scrolling system for prototyping games on STE

Postby bear » Mon Apr 18, 2016 6:56 pm

This test, ste_slab_method caused a lot of flickering on my STE, how about you others? Cool progress anyway!

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Mon Apr 18, 2016 7:03 pm

I think there's still a problem in the displaymanager on STE because I saw it display the backbuffer instead of frontbuffer during one set of tests, and it seemed erratic. So the sync is probably broken. I'll look at this next.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Mon Apr 18, 2016 8:38 pm

EvilFranky wrote:So is it faster to draw 1 huge sprite like this rather than lots of smaller ones like player/bullets/enemies Doug?


Yes - normally it would be a bit faster but in this case its a lot faster because the method is different, being optimized for a big fill area.

It's essentially a polygonal outline comprised of textured spans, with no specific masking pass. So all 4 planes can be moved with the blitter at once, instead of AND'ing 4 planes then OR'ing 4 planes - which requires a lot of memory access per pixel.

Here's the sprite drawn normally, with pixel-shifted spans:

test1.png


And here's the same sprite with the span offsets locked at 0 - all the pixel data gets left-justified.

test2.png


Span setup aside (which is optimized with some global/shared precalc - about 32k) this minimizes the number of reads/writes needed by the blitter in total to get the thing on the screen with the outline intact. It also uses the NFSR bit in the blitter to dodge final span reads where possible.
You do not have the required permissions to view the files attached to this post.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Mon Apr 18, 2016 8:46 pm

bear wrote:This test, ste_slab_method caused a lot of flickering on my STE, how about you others? Cool progress anyway!


I'm getting the same flicker here - it looks like there's not enough padding time between blitter slices and top/bottom border events. Should be able to fix that.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2019
Joined: Sun Jul 31, 2011 1:11 pm

Re: 8-way scrolling system for prototyping games on STE

Postby Eero Tamminen » Mon Apr 18, 2016 11:10 pm

Any thoughts on providing also pixel perfect collision detection for sprites? ;-)

(Either using separate 1-bit sprite masks, or doing it while blitting to save memory?)

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Tue Apr 19, 2016 9:42 am

Yes I'll provide something for collisions but haven't settled on details yet. Often a combination of methods is needed in a single game (proximity & object classification tests, map cell type tests, background mask tests, tests for movable-scenery objects, other special case tests...). I'll start with those which are more general/reusable in order not to waste too much time.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Tue Apr 19, 2016 10:27 am

bear wrote:This test, ste_slab_method caused a lot of flickering on my STE, how about you others? Cool progress anyway!


I did get this fixed last night and left it running for a good while - so will upload a new test over lunch.

TimerA (top border) was being delayed by blitter activity and while the top border code does re-synchronize with hblank events it's a relative test and doesn't know which line it began counting on. So the blitter activity can cause the top border event to be randomly delayed by a whole line. I changed it to schedule the TimerA slightly earlier and added a TimerA-data sync before the HBL sync so has an absolute reference for the correct line every frame. Flicker gone.

I didn't catch this previously because I was lazy and testing with Steem more than usual. :)

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

Re: 8-way scrolling system for prototyping games on STE

Postby Anima » Tue Apr 19, 2016 11:31 am

dml wrote:
EvilFranky wrote:So is it faster to draw 1 huge sprite like this rather than lots of smaller ones like player/bullets/enemies Doug?


Yes - normally it would be a bit faster but in this case its a lot faster because the method is different, being optimized for a big fill area.

This is one of the true advantages of the Atari Blitter: use write cycles only where it is needed (ENDMASK = $FFFF) instead of the common "read - modify - write" cycle waste.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Tue Apr 19, 2016 12:32 pm

Have updated the same archive with a new .prg, so hopefully the flicker should be gone or at least greatly reduced! I'll give it more proper testing over the weekend.

https://dl.dropboxusercontent.com/u/129 ... method.zip

[EDIT] think the left-justify hack is still in there so the sprite will be a bit weird looking. nevermind.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Wed Apr 20, 2016 6:02 pm

The project has been tidied up and now its possible to build multiple demos for STE/STF machines in the same project. So I can start making specific, separate samples now instead of having everything mixed up in one file with confusing switches.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Thu Apr 21, 2016 2:34 pm

Here's an updated version of the demo from yesterday, with both slabs and sprites drawn on a scrolly background (STE again).

https://dl.dropboxusercontent.com/u/129 ... _demo1.zip

This uses the tidied-up code, although a lot of loose ends remain. Trying to get those sorted out in the evenings as time is available so the first code snapshot can be uploaded for people to play with.

Meantime, I have attached the top level C++ source for the demo itself, which should help illustrate the setting up and drawing of things - it's fairly straightforward. Hopefully it will become clearer and more compact as the loose ends and get fixed and a few ugly details (like obtaining the framebuffer) get put behind their interfaces.

The first obvious thing should be the relatively small amount of code needed to define a world, buffers and the scrolling type - the rest of the code is dedicated to loading or drawing items.

Once again - this stuff is aimed mainly at quick prototyping but should be good enough to support a final game too, with some more effort. In its current form that's not really viable due to a number of missing or weakly defined things e.g. overly simplistic memory management and lack of input. I'll deal with these gaps over a bunch of future updates and add more complete samples later. For now I'll just make some samples for the stuff that's ready.

[EDIT]

...think I saw a bug in the animation frame calc which crashes the demo after a while - will look at it after work in the evening sometime.
You do not have the required permissions to view the files attached to this post.

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

Re: 8-way scrolling system for prototyping games on STE

Postby TheNameOfTheGame » Thu Apr 21, 2016 3:37 pm

Really nice! Looking forward to watching this project progress. [smilie=greencolorz4_pdt_12.gif]

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Thu Apr 21, 2016 6:17 pm

Ok I looked at the bug now and it's fixed - updated the archive.

I see another glitch which happens in STEEM but not on HW or in Hatari. If the blitter is paused with the FXSR bit set (for left-clipping), and then restarted, the blit can get corrupted. This sometimes upsets sprites when they go into the left border. But I'll ignore it for now since it seems to be a minor STEEM thing.

MM41
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 115
Joined: Sun Jun 28, 2015 2:36 pm
Location: France

Re: 8-way scrolling system for prototyping games on STE

Postby MM41 » Thu Apr 21, 2016 8:41 pm

Excellent DML :D,

On real STe i have a flash on screen sometimes but less than the olders versions.

The flash is never at the same time.

I'll try on another STe to compare.

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

Re: 8-way scrolling system for prototyping games on STE

Postby dml » Thu Apr 21, 2016 9:45 pm

MM41 wrote:Excellent DML :D,

On real STe i have a flash on screen sometimes but less than the olders versions.

The flash is never at the same time.

I'll try on another STe to compare.


:cheers:

Yep I think you're right - occasionally the top border still pops and causes the screen to flicker. Still a small amount of blit interference - there's a bit of trial and error in the tuning so I'll give it another pass once the first code drop has been made.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 5 guests