joefish wrote: <...> Do the foreground in 3 colours + transparent, and the background in just 3 colours (not 4), set the combined overlapping colours to prioritise the foreground, and that still leaves you with 4 colours unused that you can allocate to sprites on the fly.<...>
Slightly offtopic, could you demonstrate and elaborate this technique with a sample .PI1 file and a seperate thread on the generic Coding section? I think this could be interesting knowledge for more newcomers to ST coding. I personally would like to see a practical demonstration of this aswell
There were a couple of demos on the ICTARI user group disks; one scrolling with two scenes, and another with pathed sprites. A few years ago I was chatting about it with (the sadly late) Joffa Smith - I'll try and post an image of the demo disk I sent him.
is there meant to be rasters in the sky? As on Hatari there appears to be scanlines flickering at set points due to sync issues?
There WAS going to be, but it turned into a far more complex issue that i was prepared to tolerate for a "quick" demo lol.
It was never meant to be a large scale project, it was just the testing of some tiling tools i used and it got a bit carried away
Raiden, the game im working on now DOES feature some of the techniques i developed here though.
We all have to remember that this DOESNT use ASM commands or wierd PROGRAM ports, it simply uses STOS and its extensions. Of course it COULD be better but the idea was never a project, just a test of what the tiling system i built could do.
Dammit, I tried doing a Shadow of the Beast parallax scroll in assembly and it's running in one VBL, when I based the pre-shifting around two VBLs. Damn code running too fast...
So far I've got the trees and mountains moving in parallax (1 and 4 pixel steps). Both are re-rendered to 3 colours each, as per my previous demo, with a rastered sky. The clouds behind the trees are being repainted every time, but they're not actually moving yet. So it's repainting about 85% of the screen in one VBL, which is roughly what you get if you were doing a straight copy of one screen buffer to another.
I haven't done the bottom bit or any sprites, which are evidentally going to tip it over into two VBLs- which is what I was planning for anyway. If it runs in one VBL I'd need twice as much pre-shifting of the foreground chunks, after all!
Not sure how much memory I can chuck at pre-shifting the clouds and still fit it in 512K. For a game engine I'd probably use half a screen width of each of the background graphics and display it twice; same for the mountains, as they're pre-shifted in an extravagant 16 steps and they're not really all that interesting. Whereas the foreground only needs 4 steps of pre-shifting, so you get more variety for your RAM.
-4096 colours / 27 colours
-16 sprites hard / no sprites hard
-3 Dma channels / no Dma
-splitscreen facilities / can do it easily
-scroll hard h/v / can do it but takes more memory!
Parallax in different strips is a completely different 'beast' to per-pixel transparency overlaid graphical layers though. Generally the 8-bit machines don't have the facilities to even attempt it. Though there have been some fairly clever tricks to give the illusion on systems with hardware sprite or scrolling tilemap displays.
My Stuff: FB/Falcon CT63 CTPCI ATI RTL8139 USB 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 that are no longer for sale due to them over 30 years old - click here for list