Scrolling on the Amiga | Hacker News Reader

Scrolling on the Amiga

uridiumauthor.blogspot.com

53 pointsingve26 comments

OMG! This is the blog of Andrew Braybrook, author of Paradroid and one of my childhood heroes! How cool is that!

Some years back, I found his journal online from when he developed Paradroid. I felt like being in heaven finding that treasure.

If I recall correctly, I read somewhere that he completely withdrew from the games development scene and now works for some non-game related IT company in the UK, but my memory on that is vague.

Was that the Paradroid journal? He kept a diary for Zzap!64 magazine called Birth Of A Paradroid:

http://www.zzap64.co.uk/zzap3/para_birth01.html

He also wrote a diary for his Morpheus game:

http://www.zzap64.co.uk/mentalprocre.html

Very interesting to read, but I can't seem to find a "year" when it was written. The Mental Procrastination has a publicised issue date of 1987, but I guess it was written before then?

Both remind me a bit of Jordan Mechner's "The Making of Prince of Persia".

Probably would have been written in 1987, just a couple of months delayed. Zzap used to publish development diaries while a game was being produced, which meant the diaries would sometimes end midway when a game was cancelled (thinking of the Batman Returns [1] game diary in that case).

[1] https://www.gamesthatwerent.com/gtw64/batman-returns/

Yes, I think that's the one.

Paradroid was tremendous fun on the C64 and also one game I fondly remember.

I recall being highly stressed by the game at one point. I had control of a low level droid and had no choice but to take on a very high level droid. I had to very carefully time when to trigger the few circuits I have to gain control and just managed it with seconds remaining on the clock. What a rush that was! :-)

The TI-99/4A had no hardware scrolling registers. Smooth horizontal scrolling for Parsec was achieved by putting the display into bitmap mode and having the CPU manually shift the background bit patterns in a fast inner loop. This trick (actually more like brute force) was possible because the CPU was a fast 16-bit CPU and had access to (only 256 bytes of!) fast SRAM to do the work in. And I don't think it was able to update the character pattern tables every frame (bitmap mode worked by having three active character pattern tables per frame, one for each 1/3 of the screen).

The Sharp X68000 would outdo both the Atari ST and Amiga in this comparison.

It basically had arcade machine class video hardware. It came later to market, but creamed the Amiga completely in specs, and they ended up shipping 25 different models of them, up to really high clock rates.

Unfortunately only really sold in Japan (though due to population size of Japan, it actually sold a _lot_ of units and a lot of games were ported to it).

It's really too bad it never really made it to Europe and North America

Thread about porting X68000 games to the Atari Falcon: http://www.atari-forum.com/viewtopic.php?t=24111 (bullet hell shoot-em-up video on page 19)

(Atari Falcon: https://en.wikipedia.org/wiki/Atari_Falcon - it's quite a lot better than the original ST, but still doesn't have sprites or multiple playfields)

Falcon is great. I have two ;-) And an X68000, though I'm not sure why I spent the money to have the latter. It's a hassle to work with (5 1/4" floppies with soft eject, hard to get parts/boards, non-standard SCSI, no decent floppy emulators, Japanese OS, hard to get software, 15khz frame rate video output on some games) and the PSU will self-destruct any day now given the crappy caps in them.

I believe I've done smooth vertical scrolling for games on the Tandy Color Computer, which is basically the same hardware as the Dragon 32. That was 30 years ago, so my memory is a little rusty.

I believe I used the "Can we start the screen memory on any address in video RAM?" mechanism from the article.

There was definitely some sort of boundary limitation: IIRC I couldn't get horizontal smooth scrolling to work, but I'm fairly sure I got vertical scrolling working.

If anybody has an archive of the disks from T&D software they can double check my assertion...

http://tandd.com/software/index.html is a nice URL, but not the right one :-)

http://www.colorcomputerarchive.com/coco/Documents/Magazines... gives scans of the cassettes. I guess (but haven’t fully checked) “T&D Software.zip” in http://www.colorcomputerarchive.com/coco/Disks/Magazines/ gives a 12 megabyte download of their contents.

Thanks a lot! I haven't found the game I'm referring to yet, but I did find the first game I ever sold: dbreak on disk 69.

See the original Uridium on the C64 in action here: https://youtu.be/N0TfHkNpRNs

Smooth scrolling could be achieved in character mode by making the borders wider, hiding 2 columns or 1 row, depending on the direction. The visible area could then be adjusted on a pixel-by-pixel basis, revealing the hidden content gradually.

Uridium's scrolling on the BBC Micro was also somewhat interesting: https://youtu.be/ToTQN6dxwDw?t=243

Multi-way scrolling was common for BBC Micro games, as the hardware directly supported the barrel-type scrolling described in the article, though only on a full-screen basis. Uridium programmed the CRTC in a particular way, however, allowing the screen's base address to be set halfway down the screen, giving a stationary area at the top and a fixed area at the bottom.

I think the only other game of the period that did anything like this was Firetrack (https://www.youtube.com/watch?v=8bxdd2_qrpg), which used it to get smooth vertical scrolling.

The technique is easy to do (http://www.cpcwiki.eu/forum/programming/rupture/), but you do have to know the trick! It's know a well-known thing, and there's a couple of modern BBC Micro games that use it.

Also see Uridium on the ZX Spectrum.[1] It's the only ZX game I can remember that had smooth scrolling, and when I first saw it, it left me in awe. I'd love to see how this was achieved.

[1]: https://youtu.be/CKZO-dnEReM

Andrew Braybrook, that's a name I haven't heard in a while. Aside from his original games, I remember he did a highly praised port of Rainbow Islands for the Amiga.

If you like this kind of look into old school games coding techniques, you'll probably like GameHut:

https://m.youtube.com/channel/UCfVFSjHQ57zyxajhhRc7i0g

umm ZX Spectrum 128Kb, +2 and +3 can swap memory video banks, doing a effective double buffering.

Atari ST

- Can we start the screen memory on any address in video RAM? No, limited boundaries. - Can we restart the screen display from another address during the display? No

What ? It could definitely be set to any memory address (with same 16-bit boundary as the Amiga)

Just to add some more details to what to3m said.

The ST's screen address did have to be on a 256 byte boundary. With 160 bytes per scanline you could scroll 8 scanline vertically by changing the screen address.

People did work out a methods of scrolling the screen with finer control. Sync scrolling [1] used overscan techniques.

ST screens had a border around the image, not filling the whole screen. Methods were developed to the bottom, right, left and top borders [2].

By combining left and right border removal different offsets could be generated to position the screen on any 16bit/pixel boundary [3].

[1] http://www.atari-forum.com/viewtopic.php?f=1&t=4357&sid=8a77...

[2] http://aldabase.com/atari-st-fullscreen-demos-history/

[3] https://blog.troed.se/2015/12/23/overscan-and-sync-scrolling...

The bottom 8 bits were alway zero, so all you could really do was 8 row (1280 byte) vertical scrolling. I don’t think you could change the screen base address mid-frame either, so you’d need a double-height buffer to do a continuous scroll.

The STe fixed both of these problems, and had variable wid5h rows and the pixel offset thing too. That meant a setup that was roughly equivalent to a 4-bit Amiga screen, though with interleaved bitplanes (which is not necessarily a bad thing).

The STe Blitter was really great, but totally underutilized because it was such a small fraction of the ST market. Atari really dropped the ball by getting the Blitter to market so late.

Interesting the different approaches. Commodore shipped the Amiga 1000 at too expensive a price point, and so Tramiel (who had rushed the ST to market just before the Amiga) got in with a rock bottom priced machine that initially looked like it would kill the Amiga (which was his intention.) But Commodore followed up with the cost reduced Amiga 500 which ended up winning against Atari Corp in the home gaming market (though IMHO the ST and offshoots were still far better productivity machines than the Amiga and did well in that market in Germany).

Going back to some of those ST games I loved, they have really crappy frame rates and high latencies.

One thing that stuck out for me was this comment:

"Amiga Do we have enough CPU time to rebuild everything on the screen every frame? Just about."

That seems dubious, given he says the Atari ST is "not really". Both had the same processor and the ST had a higher clock rate. The Amiga could only out-do the ST in graphics performance because of sprites and scrolling, but manually rebuilding the whole framebuffer on every refresh was not possible on _either_ machine. The Amiga could "cheat" by using dedicated hardware for specialized tasks. But could not really rebuild a whole frame each time either.

Copper, scrolling, sprites etc., sure won't actually touch the frame buffer. What you're forgetting is the blitter, which indeed is a way for the Amiga to redraw the whole framebuffer faster than its CPU alone could handle, AFAIK well within the time span of a frame. Add game logic and other I/O to that and the difference could very well cross the line between not enough CPU and enough CPU.

Well, sure, but I guess I read what he was saying as "CPU can rebuild buffer before next frame", not as "CPU + specialized chips can etc." But if you read it the latter way, yeah, the Amiga creams the ST. But if what you're doing isn't something that the blitter can help with, the two are roughly the same.

So for example, on the various 3d wireframe games that came out for those platforms (i.e. Starglider, etc.), the ST had a slight edge due to its slightly higher clock rate. In fact anywhere where it's just polygonal drawing, the ST had a very slight edge.

The Amiga's Blitter actually has line [1] and polygon fill [2] modes. Obviously this does require code to be rewritten to take advantage of the extra hardware. On a CPU > 68000 the tradeooff between CPu and blitter is different [3]

[1] http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui...

[2] http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui...

[3] http://eab.abime.net/showthread.php?t=50815

Reply on news.ycombinator.com