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 » Tue Apr 05, 2016 9:59 am

Did make a little more progress on this at the weekend, but not a huge amount. Still last night's sample is the most advanced so far:

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

1-pixel 50hz scrolling of a full arcade map on a 520STF, with open top and bottom border (limited to 240 scans), no CPU waste and no tile preshifting.

Around 75% CPU remains free, although judging by eye only - I didn't measure it properly. Most of the cost is the realtime tile shifting, although I did optimize it in a tricky way for small shifts (0,1,2,3 pixels).

A number of not-yet-addressed issues, including a flickery left/right border which needs masked, and some known HW wakestate issues with the current ljbk 'beeshift' scroll technique. A manual display mode toggle is missing - which is needed to deal with unlucky cases - but the way it is configured should work by default on most STFs most of the time.

This uses ljbk's 4-pixel hardware shift technique. Sticking to 8-pixel could work out more reliable on the remaining STFs/wakestates but raises the minimum spec from a 520 to 1040 ST. In any case I'll include all options in the codebase. If this technique evolves further I'll try to keep track of it.

This stuff will freak out on most of the emulators - well into space-cadet Shifter territory so you'll need some Atari HW if you want to try it. It actually deadlocks Steem SSE 3.8 on my PC! :-o
Last edited by dml on Tue Apr 05, 2016 10:11 am, edited 1 time in total.

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 » Tue Apr 05, 2016 10:09 am

Hatari doesn't like it, but it doesn't hang haha.

Still get a general idea though, super smooth. Great stuff Doug.


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

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

Postby npomarede » Tue Apr 05, 2016 10:22 am

dml wrote:Yeah Hatari shows garbage instead. But OTOH doesn't go into a coma. :)

Hi
yes, I never really implemented Paulo's 4 pixels hardscroll in non overscan mode in Hatari (could be done by adding some special cases just for this list of switches, but this usually results in unreadable code in the end).
I'm planning to support it "automatically" through a more generic handling of shifter's states when switching between hi/med/low res, maybe in next Hatari version.
These scrolling routines will be a good real life test case :)
Nicolas

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 05, 2016 10:26 am

That would be nice to have. I have probably made things marginally worse by opening the top/bottom border (which I wasn't even sure would work with it - but apparently it does, for me at least!). The syncscroll+shift does seem to upset the VBL timing so any timerb scheduled directly from VBL will move up and down several lines at a time... so any scheduling has to be after the syncscroll event. There is also some SMC in there to patch toggles according to wakeup modes...

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

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

Postby npomarede » Tue Apr 05, 2016 10:35 am

I have a work in progress to support all STF wakeup states, which was not the case in Hatari 1.9, so this might already give better results when it will be completed (it already runs "Closure" demo by Sync, so I'm confident it will improve the situation)

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 05, 2016 11:58 am

Just realised that I missed an opportunity to cut the 25% CPU load to about 8%. But another time! Needs effort to do it properly.

I'll make a diagonal/8way test out of this and then go back to the playfield system itself - sprites etc. I'll deal with the remaining STF tidy-up work another time.

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 » Tue Apr 05, 2016 12:03 pm

8% ?!

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 05, 2016 12:15 pm

Well the playfield engine uses speculative/predictive rendering - the tiles appear in thin slices with some rules involved. This is mainly to balance out spikes on STE where new tiles appear slightly offscreen and where CPU spikes would normally occur every 16th frame or whatever (a new tile strip appearing). But using a 4pix or 8pix hardware shift, you can do something similar with the offscreen buffers. Divide the overall work by 4 (since only 1/4 of the 16 scroll positions need tile writes), and divide the spikes across 4 draw events to produce a flat cost on every frame.

But I can't be bothered just now. :) Sprites first.

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 05, 2016 12:36 pm

Ok I lied - I decided to try it quickly since its lunch now. It works fine. It costs <1% CPU for 15 out of 16 scroll positions, then all drawing for 4 playfields produces a 25% spike at the final pixel step. So taken on average over a period its 7% CPU (ignoring syncscroll cost - another bunch of scanlines).

It's still more effort to distribute the 25% spike across all frames, but the method will be similar to that used on STE - draw the tiles incrementally in managed slices for all playfields on every frame. Sorted.

[EDIT]

Here's a version of that with the timing raster on. The position of the green raster indicates where the CPU becomes free. Note that it is measured relative to the *lower* part of the screen where the raster is sitting (not the top!) - where I currently synchronize the mainloop for testing. For most frames the playfield cost is tiny, and every 16 pixels there's a spike which runs over the lower border and wraps around to the top - but no more than about 25%.

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

joefish
Atari maniac
Atari maniac
Posts: 85
Joined: Thu Dec 05, 2013 4:15 pm

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

Postby joefish » Tue Apr 05, 2016 1:22 pm

Just a little note on 8-way scrolling. I've done horizontal and vertical scrolling on the ZX Spectrum and ST, where you have to fill-in the edge of a buffer as you go. But not 8-way, where you would have to fill-in along 2 edges at once.

But, it's possible to rig your game design so that you only need 4-way scrolling - not these more awkwards diagonals.

I started thinking about games like Contra / Probotector / Gryzor, or Rygar, where you follow a fixed path that changes direction. But I also noticed that the underground sections in Shadow of the Beast, despite being a large 2D map, only ever use 4-way scrolling. It avoids needing diagonals by not letting you move left/right when falling (so it only needs to scroll vertically), and also having the map laid out so that jumping is only ever over gaps, never up or down to a different platform - so the game doesn't scroll vertically when you jump; only when you complete your jump if you then need to fall down, in which case it no longer needs to scroll horizontally.

Of course, another trick to simplify scrolling of a 2D map is evident in the likes of scrolling shooters like Vulcan Venture / Gradius 2. Just use a buffer 2 screens high and scroll it horizontally with fill-in, and grab a window out of it to allow a little vertical movement.

But do carry on with all the hard work! :D

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 05, 2016 1:35 pm

Yes indeed all good points. I actually solved the 8-way case some time ago but only because it was interesting at the time :) A lot of game designs can easily be made to fit 4-way without a big impact. It's also cheaper to run, even in this system. Although in most cases for what I will provide - the cost of sprite management and any parallax effects will generally overshadow the scroll cost anyway...

However it's nice to have arbitrary scrolling there for people who want to use it. While it is described as 8-way it does allow arbitrary (circular) movement so long as the rate doesn't exceed 16 pixels between buffers. (I could extend this limit but I doubt anyone will use such a fast scroll).

joefish wrote:Of course, another trick to simplify scrolling of a 2D map is evident in the likes of scrolling shooters like Vulcan Venture / Gradius 2. Just use a buffer 2 screens high and scroll it horizontally with fill-in, and grab a window out of it to allow a little vertical movement.


This is what I had loosely defined as 'nudge scroll' near the start of the thread - its cheaper than full 8- or 4-way update logic if the amount needing scrolled is a portion of a screen's worth (and claims less ram if less than a screen's worth). Once again - for a lot of games even this is enough!

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

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

Postby exxos » Tue Apr 05, 2016 1:58 pm

Doesn't seem to run under steem :(

Steem__00002.jpg
You do not have the required permissions to view the files attached to this post.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

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 » Tue Apr 05, 2016 2:06 pm

Yeah DML already said it kills STEEM :D

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

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

Postby exxos » Tue Apr 05, 2016 2:27 pm

Yep, but tried it anyway ;)
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

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 » Tue Apr 05, 2016 3:32 pm

When I try the tests supposed to run on STE, all of them gets mixed up bitplanes with wrong colours, except the Stf test "pf_stf4096_2pix.zip", which shows correctly. I have an STE with 4mb and Tos 2.06. Thanks for your work so far, DML!

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 05, 2016 3:55 pm

Hi, thanks for the info!

The "pf_stf4096_2pix.zip" case is probably working ok on STE because its using a reference syncscroll routine which is compatible with that machine. The plain-STE cases might be suffering from a bogus top-border timing, causing the main part of the screen to screw up. It is using completely different code (and not too well tested either) so that's possible. I'll take a look and see if I can reproduce it here on the STE here and issue fixes to the test archives.

Cheers

joefish
Atari maniac
Atari maniac
Posts: 85
Joined: Thu Dec 05, 2013 4:15 pm

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

Postby joefish » Tue Apr 05, 2016 4:35 pm

OK, I've re-read this thread a couple of times to try and get my head around what's happening! I'm unfortunately stuck with emulation at the moment, so I can't see this going on a real box.

As far as I can gather, this scrolling is about using buffers of what's actually on-screen? The only software 'painting' that's going on is fill-in of tiles along the edges of the various bits of buffer? And then the actual 'movement' is done by 'synch-scroll' techniques - manipulating the video chip into shifting the display around? Except on the STE, where such things are deliberately programmable?.

npomarede wrote:Also, don't forget the "master" of fast scrolling : Steve Bak was certainly one of the 1st coder to use similar techniques to get the outstanding speed in "Goldrunner" or "Return To Genesis", even with 512 KB.

Erm - seems to me he's scrolling less than half the screen in Return To Genesis, so it flippin' well should be happening in one VBL!

Is it generally assumed then, that purely in software, you're not going to see a 320x200px tilemap with 1 pixel scrolling in one VBL on a stock 520STFM?

(With apologies in advance for derailing other people's threads about scrolling. Feel free to abuse mine with distracting kitty pics if you like... :mrgreen: ).

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

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

Postby npomarede » Tue Apr 05, 2016 4:44 pm

joefish wrote:Erm - seems to me he's scrolling less than half the screen in Return To Genesis, so it flippin' well should be happening in one VBL!

Yes, it should be possible to "beat dis" today even with software only rendering, but for the time it was really great coding.
Is it generally assumed then, that purely in software, you're not going to see a 320x200px tilemap with 1 pixel scrolling in one VBL on a stock 520STFM?

If this requires to keep each screen and only update the in-going/out-going tiles, then this might be quite complicated, as 16 screens will eat just 512 KB of RAM :)
So only solution is to lower the width / eight of the displayed screen, or use less than 4 bitplanes (goldrunner uses only 2 IIRC), or use a minimum horizontal scroll of 2 or 4 pixels.

Nicolas

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 05, 2016 4:50 pm

joefish wrote:As far as I can gather, this scrolling is about using buffers of what's actually on-screen?


On STF - yes.

Extra buffer 'states' are used for pixel scrolling with finer grain than the screen address. Normally on STF the screen address grain is 256 bytes. Normal syncscroll reduces this to 2 bytes (16 pixels), allowing v-scroll using just the address. The ljbk method (and alien's earlier fullscreen version of same) reduces this further to 4 pixels.

On STE, the extra buffers are not needed. Normal double-buffering aside.

joefish wrote:The only software 'painting' that's going on is fill-in of tiles along the edges of the various bits of buffer? And then the actual 'movement' is done by 'synch-scroll' techniques - manipulating the video chip into shifting the display around? Except on the STE, where such things are deliberately programmable?.


Yes that's right. The STE has the added advantage of virtual pixels on the horizontal axis. I use 32 pixels of hidden buffer for speculative tile rendering. You can use 16 otherwise.

joefish wrote:Is it generally assumed then, that purely in software, you're not going to see a 320x200px tilemap with 1 pixel scrolling in one VBL on a stock 520STFM?


Yes. At least not in 4 planes. Without some kind of syncscroll and/or extra buffers you're left with copying data every frame and there's generally too much of that for 1 VBL.

The idea of this playfield library is to get most of the background scrolling for free and to save time getting that part to work. You'll still have to pay the 'usual price' for whatever gets slapped on top of that :D

joefish wrote:(With apologies in advance for derailing other people's threads about scrolling. Feel free to abuse mine with distracting kitty pics if you like... :mrgreen: ).


I don't mind at all. It's on-topic :)

joefish
Atari maniac
Atari maniac
Posts: 85
Joined: Thu Dec 05, 2013 4:15 pm

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

Postby joefish » Tue Apr 05, 2016 5:42 pm

joefish wrote:Is it generally assumed then, that purely in software, you're not going to see a 320x200px tilemap with 1 pixel scrolling in one VBL on a stock 520STFM?

dml wrote:Yes. At least not in 4 planes. Without some kind of syncscroll and/or extra buffers you're left with copying data every frame and there's generally too much of that for 1 VBL.

OK, so now I know no-one meant it to, but to me that sounds awfully like a gauntlet being thrown down somewhere far away, as that was said about the ZX Spectrum until I actually did it. Though it's probably not all that impossible if you want to chuck some effort into the job - just not necessarily all that useful or impressive when you can do so much more with synch effects. And there are always limitations - and skimping on the bitplanes is clearly a too-obvious ruse which you've thought of too! :lol:

I seem to remember devising a tile-based omni-directional scroller that worked in less than one VBL, but only on two bitplanes - and with a very limited tileset. The code might be long-lost now though. I vaguely remember trying to implement some sort of grid in the back two bitplanes, that with colour-cycling and rasters could be made to appear to scroll in parallax. But the grid was too fine and the main tileset too limited, and it all ended up looking a bit crap.
Last edited by joefish on Tue Apr 05, 2016 5:50 pm, edited 2 times in total.

joefish
Atari maniac
Atari maniac
Posts: 85
Joined: Thu Dec 05, 2013 4:15 pm

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

Postby joefish » Tue Apr 05, 2016 5:47 pm

[Oops - double post. Meant to edit, not quote.]

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

Yes of course you can't beat the performance of case-specific code. I won't be trying to do that here because there's no way to capture all of those cases in a sensible amount of code. I'll be happy if it just lowers the bar for a few people interested in coding an ST game but without the time or the patience for some of these details. Time that could be spent on the game.

However the performance available from this should still be better than much of what's been used in commercial ST games already, with a few notable exceptions, partly because it combines knowledge different places collected over a longer period.

As a side note - I do remember one day in 1991 when I tried to convince my bosses to adopt syncscroll in an ST title being prototyped. I received a funny look and a matching reply. It's not that we were unaware of those tricks - but the QA burden was scary. Well there were some other reasons too but that was a big one.

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 » Tue Apr 05, 2016 6:55 pm

Was the other reason because they wanted to Amiga version to shine more? :roll:

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 05, 2016 6:59 pm

EvilFranky wrote:Was the other reason because they wanted to Amiga version to shine more? :roll:


Lalalala, :coffe: ...is that the time?


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 7 guests