8-way scrolling system for prototyping games on 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

8-way scrolling system for prototyping games on STE

Postby dml » Thu Mar 24, 2016 11:06 am

[*** EDIT ***] This has since been updated to include STF(m)+MegaSTs.

I decided to post some info on a scrolling system developed for STE games some time ago. This doesn't exactly preclude demos - but I was thinking mainly about games and prototyping when I came up with it. It also lets me digest a bunch of related things in one place.

Note: The same principles can be applied to STF but without a 4-bit (non-overscan) syncscroll and plenty of memory it is quite a bit more limiting. If a stable 4-bit syncscroll is figured out and made available at some point I can integrate it :) Otherwise there will be some tough constraints on h-scrolling vs ram budget.

The system was written in a mixture of C and 68k. The 'game mainloop' and playfield logic is C. The intensive/drawing parts are 68k. The main rationale was making it easy to experiment and adapt to different game and display formats with minimal changes. Specific techniques have been used to ensure the C keeps pace with the 68k parts but I won't describe those here.

Before I get any flames about using C for something like this, you can be sure the cost is counted in scanlines, not VBLanks. If every cycle is needed for a 1VBL game, then sure, the C parts should be converted - probably at the expense of configurability / prototyping friendlyness though

Diagrams are attached showing the various playfield modes and how the display is made up for different scenarios.

A summary of features:

- 8 way (or 4-way) scrolling
- horizontal-only scrolling
- vertical-only scrolling
- horizontal scrolling with vertical nudge-margin (up to 1 screen of margin)
- vertical scrolling with horizontal nudge-margin (up to 1 screen of margin)
- scroll rate from 0 to +/-16 pixels per frame on each axis
- map size up to 32768 x 32768 pixels
- highly configurable for different kinds of game
- very low drawing cost
- optional wraparound maps
- double-buffering or physical-only display
- dual-field colour boosting (with or without double-buffering, and allows scroll rate of 0)

Note: nudge-margin scrolling could be described as 'limited 8-way', but cheaper than full 8-way if the scroll range is short since fewer tile updates are required. Also has flatter cost for a rectangular display.


The display 'arena' is made up of elements called 'playfields', each of which is a physical image buffer mapped to a virtual tile space. The virtual tile space is a wrap-around window onto the source map tiles (a map tile is typically 16x16 pixels but depends on the game).


If you consider a normal double-buffered display, just replace each buffer with a virtual 'playfield' and you get the rough idea of whats going on.

Copy of Display Configurations - Standard.png


The size of the physical image buffer depends on the type of scrolling selected - some combination of horizontal and vertical scroll - and the expected scroll range on each axis. It's obviously cheaper to avoid performing updates which are not needed for a specific scroll configuration, so each layout is optimized for a particular combination of scroll features. These attempt to save both memory and time if you know what your game needs. And if you change your mind, it's easy to reconfigure the display after the fact.

The 'loopback' configurations maintain a shadow tile-page in order to jump back by a full screen without a cost spike. 'scanwalk' configuration allows padding scanlines to be consumed by h-scroll without needing a loopback buffer (This trick is only possible on the H axis but is nearly always preferred over H-loopback).

Scroll Configurations(1).png



The number of playfield elements required to define the display arena depends on the display mode (double-buffered or not, colour-boost/interlace or not).

It may seem nuts to have a complete, independent playfield per display element (instead of one playfield with multiple memory buffers), but there are several excellent reasons for this relating to the scroll state, speed and distribution of work. See if you can guess what they are :twisted:

I'll be posting some demos later which use the worst case - double-buffering and colour-boosting at the same time - so there are 4 playfields being maintained per VBL, each with one or two virtual tile pages being updated & maintained with new tiles. Various tricks are employed to make this happen quickly (cheapest method with unlimited scroll is H-only, costing a handful of scanlines - most expensive is 8-way at ~1/4 frame for unlimited diagonal). More tricks are employed to prevent spiking behaviour so the cost remains flat for each scroll position. (Having said that, I stopped optimizing code when it became cheap enough to be concerned with other things e.g. sprite clearing - so there is room left for sure).


The colour-boosting feature allows you to obtain 50-100 colours from a single 16-colour palette without raster splits. It involves heavy offline processing of the graphics with a tool and the display arrangement is more complex. It also costs more to maintain the display updates.

This consumes two 'field' elements per display buffer ('front' and 'back' both have 'even' and 'odd' elements). The scrolling engine has to maintain all 4 if the scroll can be interrupted (e.g. halted) even for a 1VBL game - although sprites need written only to the synchronized field. For games requiring 2+ VBLs, sprites must be written to 2 fields at once for the colour-boosting to work. If 1VBL drawing is assured and scroll rate is fixed, 4 playfields can be reduced to 2 (logical/odd + physical/even).

Display Configurations - Colour Boost.png


For more information on the boosting thing on static and moving images, see my original posts here:
viewtopic.php?f=68&t=24166


I'll post a few updated samples by the weekend or early next week. I have posted some earlier demos but these were more about the colour boost and not much was said about scrolling. The code isn't yet ready for release because some things are still missing but hopefully will get something on GitHub or BitBucket before long so people can play with it. (You'll need GCC+VASM cross tools for hacking around with it, and PhotoChrome v6.23+ for the preprocessing of maps direct from .png images although the map/tile file format is trivial to produce independently)


Happy STE coding
You do not have the required permissions to view the files attached to this post.
Last edited by dml on Thu Mar 31, 2016 2:15 pm, edited 1 time in total.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2904
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

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

Postby AtariZoll » Thu Mar 24, 2016 11:58 am

Great . Looking forward. Must say that all this terminology is strange to me (nudge for instance). but probably code will better suit me :D
Negative feedback has usually positive effect.

User avatar
metalages
Atari freak
Atari freak
Posts: 50
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

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

Postby metalages » Thu Mar 24, 2016 12:57 pm

Very interesting :)
I tried to make a playfield reusable system on STe in the 90's but it remained bugged on the "looping" system.
Happy to see I am not the only one to mix 68k and C on the ST :)

Your approach to work with flipping pictures is also very interesting.

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

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

Postby Anima » Thu Mar 24, 2016 5:46 pm

Thanks Doug for sharing your tools.

I did some tests with the enhanced colour approach (single VBL switching) as well but sadly I ran into problems. The first one is the quality of the display on modern TVs (Atari STE connected via SCART). The deinterlacing of the picture does not results in a mixed colour but you see two separate pixels with the alternating colours which looks like an ugly dithering. The second problem was the movement of the objects where some of the bobs moving at different speed look like they weren't enhanced at all. I think there's a solution for the second one but I was very disappointed by the overall result. Probably using an original monitor would help...

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

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

Postby dml » Thu Mar 24, 2016 7:50 pm

Anima wrote:Thanks Doug for sharing your tools.

I did some tests with the enhanced colour approach (single VBL switching) as well but sadly I ran into problems. The first one is the quality of the display on modern TVs (Atari STE connected via SCART). The deinterlacing of the picture does not results in a mixed colour but you see two separate pixels with the alternating colours which looks like an ugly dithering. The second problem was the movement of the objects where some of the bobs moving at different speed look like they weren't enhanced at all. I think there's a solution for the second one but I was very disappointed by the overall result. Probably using an original monitor would help...


Yeah both fair points.The input gfx and settings affect things a lot also. The 'modern monitors' issue is probably the most difficult to deal with - I've been working on the basis that decent palette solving can produce output that - at worst - produces a nice dither, and at best new colours. Assuming the monitor has *some* persistence will usually result in a middle ground. This is quite difficult to achieve but have been getting fairly good results for the most part. Input with many saturated colours doesn't work well but that's life!

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

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

Postby dml » Thu Mar 24, 2016 10:34 pm

Here's a first test.

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

two programs - one tests a fixed scroll rate (0 or 1 pixels per vbl) and the other tests a varying, high speed scroll using sin/cos offsets.

Obviously the 'image' is not baked - it is created and destroyed at the margin as the window moves around the map.

As stated before, this display configuration uses 4 playfields (back/front/odd/even), all of which use a V-loopback buffer and all 4 must be updated. So that's effectively 8 sets of BG tile updates involving two axes at a time. (In fact this gets amortized in a tricky way so it's really just 4 in the end). In any case, there's a lot going on to maintain arbitrary scroll, and the cost rises with scroll speed.

Without the colour boosting, the cost is about half.

I'll post separate demos for H and V scrolling cases, both of which are considerably cheaper.

Should work ok in STEEM in fullscreen with VSync checked. Won't work well in windowed mode - or without VSync.


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

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

Postby dml » Thu Mar 24, 2016 11:40 pm

..and a specific H-scroll test:

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

This one is 240 high but the display is only 200 - I was planning on nudging it up/down as it scrolled but out of time tonight.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4858
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

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

Postby simonsunnyboy » Fri Mar 25, 2016 10:19 am

Thanks for sharing, I am delighted to see real useful ST knowledge being passed on openly.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

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

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

Postby dml » Sat Mar 26, 2016 1:06 pm

Thanks for the comments.

I've done a bit more since - created a tool for auto-cutting maps (initially for EstTeeEfEm's STOS Raiden) and have now generalized it a bit more for general use on STs. I'll post this with source code + examples first, while I complete the playfield code.

The general idea is to feed in a large bitmap, which is chopped into the minimal set of unique tiles and emitted as an ST-friendly tile library + map data in a couple of different formats including .PI1s and a more direct/compact format for 68k coders. It's directly compatible with the playfield system described above. It doesn't yet export the popular 'Mappy' format, but I might add this later if there is interest.

It can colour-reduce to a fixed palette and can generate 1-8 plane tiles so it should be usable with Falcon 8-plane modes as well.

It can do fuzzy tile matching with RGB error tolerance, so you can hack away at the size of the tile library to save ram if things get tight, at the expense of some small visual errors appearing in the map. This can be tuned and defaults to off.

That's all for now - will post the samples soon, including a non-interlaced version of the playfield viewer to use with it.

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

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

Postby troed » Sat Mar 26, 2016 1:21 pm

dml wrote:I've done a bit more since - created a tool for auto-cutting maps (initially for EstTeeEfEm's STOS Raiden) and have now generalized it a bit more for general use on STs.


Wow!

I kind of get the urge to make my scrolling system (demo code, ST sync scroll) compatible with this. Thanks as always!

/Troed

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

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

Postby dml » Sat Mar 26, 2016 1:40 pm

Troed - That would be excellent! I had plans to put an old ST synscroll routine in but perhaps there's a chance of a state-of-the-art version sometime in the future?

User avatar
AtariCrypt
Captain Atari
Captain Atari
Posts: 354
Joined: Fri Mar 14, 2014 5:04 pm
Location: Lancashire, England
Contact:

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

Postby AtariCrypt » Sat Mar 26, 2016 2:50 pm

Even as a non-programmer I think this is a brilliant share and very interesting. Thanks Doug. Hope it helps lots of you guys but now I'm gonna lurk this thread (with interest) Yellow_Colorz_PDT_23 and wondering what STE goodies could come out from this!
AtariCrypt ... ST/e gaming https://ataricrypt.blogspot.com

distantminds
Atari maniac
Atari maniac
Posts: 93
Joined: Thu Sep 29, 2005 5:03 pm

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

Postby distantminds » Sat Mar 26, 2016 3:17 pm

Wow Doug, this looks fantastic!

Will your playfield engine work with different bitplane tiles? (eg. non 4-plane)?

looking forward to the finished article :D

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

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

Postby dml » Sat Mar 26, 2016 3:34 pm

Currently the displayer/renderer is fixed at 4-plane tiles but it's easy to modify. I have a few things planned which will need this but it will probably arrive a bit later. The sprite-restore (and 'example' drawing) will come first though.

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

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

Postby dml » Sat Mar 26, 2016 3:45 pm

Ok here's the first example which includes the tool, some map graphics (Flying Shark), a script to process the 24bit map data and a demo to run the result on STE.

All intermediate files are included in case you can't run the scripts and just want to run the demo, or see whats involved.

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

The source graphic is 'shark.png'. The rest are intermediates.

To run the script use:

Code: Select all

./genmap.sh shark

I found a few bugs while putting this .zip together - which have been fixed - but I'll keep the tool source until next week when I'm more sure its 'clean'. Just takes a bit longer to pull that together. The current build is for Windows but I'm sure it will easily port to Mac/Linux with a few minutes in XCode / including the right gcc headers etc.

The scripts use ImageMagick for some colour remapping steps - which is completely optional - but convenient. (I will actually provide a better colour tool later to replace one of the more important steps).

The tilecutter itself can work from pre-reduced (4bit or 8bit) .BMP images - or direct from 24bit .BMP images if you feed it a fixed palette as well, but for this example it's using a pre-reduced 4-bit .BMP via ImageMagick.

I have no particular fondness for .BMP - was just easy to code in a day. I'll add support for multiple formats later. FreeImageLib or similar...

The demo should just run on an STE providing you copy tiles_f0.ccm (the map) and tiles_f0.cct (the tiles) along with the .tos.

This demo hase colour boosting disabled. Plain 16 colours to keep things simple. The colour boost feature is a flag in the playfield engine. If you enable that flag it will try to load map/tiles for both fields. For now it is just loading and displaying one colour field.

The script is configured to use a tile matching tolerance of 0.75. This reduced the tilecount from 1108 to 986. I couldn't see the difference visually, although its probably seen if you compare the maps side by side. Still, it seems to do what it's supposed to!

I'll post a bit more later on exactly whats happening here.

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

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

Postby MM41 » Sun Mar 27, 2016 5:23 pm

Tryed on real STe with SC1425 monitor :o , very impressive for a beta.

Some trouble appear in the upper border and they are more visible with the 8-way variable scrolling of the village (upper to middle).

Great work DML :D .

I'm waiting for next evolution

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

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

Postby dml » Mon Mar 28, 2016 9:34 am

MM41 wrote:Tryed on real STe with SC1425 monitor :o , very impressive for a beta.
Some trouble appear in the upper border and they are more visible with the 8-way variable scrolling of the village (upper to middle).


Thanks for the info - if you can somehow capture this I can take a look?

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

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

Postby dml » Mon Mar 28, 2016 9:42 am

As of last night the playfield code is able to support STFM-compatible scrolling layouts. i.e. layouts which don't rely on hidden display margin (the STE LINESKIP register) for hardware scrolling on X. This involves using different tile update strategies for changes in X & Y.

I haven't inserted any STFM-specific code yet so the STE is just pretending to be an STFM just now by setting HSCROLL=0 & LINESKIP=0 but the playfield updates are correct and its scrolling around 8-way in 16 pixel horizontal steps without drawing errors. I'll aim for a proper STFM compatible test sometime soon...

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

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

Postby MM41 » Mon Mar 28, 2016 5:56 pm

Sorry the pictures are not very good :oops: ,
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: 3472
Joined: Sat Jun 30, 2012 9:33 am

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

Postby dml » Mon Mar 28, 2016 6:01 pm

Ah do you mean the crazy bouncy colours in the top border? If so, those are timing rasters. Feedback on CPU time consumed per frame. So its actually deliberate.

A new version ready soon. Have integrated the DHS syncscroll for STFM support and this is now working although the code might not yet be 100% STFM-clean.

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

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

Postby dml » Mon Mar 28, 2016 7:32 pm

Here's a (very early) preview of the playfield engine running on 1MB STF/M.

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

It is 'jumpy' on the horizontal axis because there is no pixel tileshift implemented yet - it is however running in 1 VBL all the time and internally thinks its scrolling by pixels.

Note: This integrates the DHS syncscroll method (7 scanlines) which is a lot better than the older one I was planning to use. It was also fairly easy to integrate. Nice work guys!

I had to make quite significant changes to the playfield engine to get it working with a hybrid tile update strategy - a combination of STE patterns on the vertical axis and STF patterns on the horizontal axis. It also needs to use the CPU while the STE version blits tiles. The combined methods also means the performance is not so flat on STF as it is on STE - hscroll is quite a bit more expensive than vscroll (the latter costs almost nothing). However it's still a win overall. There's a ton of CPU time left per VBL even with 8way scroll on a 320x266 pixel display.

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

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

Postby dml » Tue Mar 29, 2016 10:17 am

From last evening - an updated version of same test for STF/M (+MegaSTs), adding a slightly improved way to display 4096c palettes on STFM.

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

I'll probably look at pixel tile shifts next, and then go back to sprite-restore stuff.

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

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

Postby troed » Tue Mar 29, 2016 10:52 am

You're too fast with updates ;) The only way I (or anyone else with current state of the art sync tricks in their portfolio) would be to expand upon that for STFM would be to go from 7 lines to 4 for the sync scroll, and possibly add an in-between (8 pixel*) shift (Paulo's non-fullscreen four pixel syncscroller).

/Troed

*) In one-and-a-half wakestate one of the four needed offsets for full 4-pixel scrolling doesn't work, but 0/8 works in all of them. Would still need the user to visually select between one of two methods depending on whether the graphics looked alright or not.

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

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

Postby dml » Tue Mar 29, 2016 11:02 am

troed wrote:You're too fast with updates ;) The only way I (or anyone else with current state of the art sync tricks in their portfolio) would be to expand upon that for STFM would be to go from 7 lines to 4 for the sync scroll, and possibly add an in-between (8 pixel*) shift (Paulo's non-fullscreen four pixel syncscroller).


Having an 8-pixel shift would be great. I saw the 4-pixel (beeshift) demo and found it both interesting & impressive - but from what I read its incomplete re: machine/wakestate compatibility so didn't look deeper.

I did spend some time looking at his fullscreen 4-line syncscroll sample but couldn't detangle the syncscroll from the fullscreen part - there seemed to be a state carried over between frames which causes the whole thing to roll/flash with any adjustment of the main fullscreen part, or I just didn't understand wth was going on in there! (likely)


troed wrote:*) In one-and-a-half wakestate one of the four needed offsets for full 4-pixel scrolling doesn't work, but 0/8 works in all of them. Would still need the user to visually select between one of two methods depending on whether the graphics looked alright or not.


Aha - that makes sense. So I can probably make good use of this if I can make sense of the code! Is it linked somewhere handy?

[EDIT]

I found some source inside the beeshift5 archive so will have a look at that soon...


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 1 guest