Hacker News Reader

Comment by fabiensanglard | Hacker News Reader

Thanks for the correction. I will update the drawings asap.

Since you seem to know the machine well, maybe you can shed some light on something i was unable to clarify: What is the fastest way to clear a framebuffer to a desired color on an Amiga. My hypethesis is that it was done with the Blitter, by disabling all DMA entries "doing something else". Do you have any idea?

View on HN

To set the framebuffer to a single color, consider that there are actually up to 6 "framebuffers" (one for each bitplane.) Consequently, it is to either set all bits for a given bitplane to 1 or to set them all to 0. To control the actual word that is blitted without DMA, you would use BLTADAT, BLTBDAT or BLTCDAT registers to control the corresponding blitter input word with DMA disabled (so the blitter does not write into these registers itself.)

A common technique to avoid having to blit each bitplane independently (esp. for BOB sprites where the blits are small and plentiful) is to interleave the bitplanes by row using the BPL1MOD and BPL2MOD register values; these values are added to each bitplane pointer address at the end of each row to move the pointer to the start of the next row; consequently a single blit operation can capture all bitplanes as in memory a row can consist of all row bits belonging to bitplane 0, all row bits belonging to bitplane 1, all row bits belonging to bitplane 2 and so on.

If this is the bitplane layout used then a single blit can only set the values to 0 or 15 (all 0's or all 1's for 4 bitplanes enabled); note however that the blitter too has modulo registers (BLTA/B/CMOD for each input and BLTDMOD for the destination) so perhaps best examine how fancy the programmer got with it (eg. multiple blits to clear the screen to a specific color even if the bitplanes are interleaved using BLTDMOD.)

Obviously I'm a bit rusty given it's been a few years, but I hope this helps. I'm a fan of your work, thank you.

I had no idea about the BPL1MOD and BPL2MOD. Now that i know they exist I don't see why a game developer would not use them.

I will try to double check with Eric Chahi but this is so much more efficient that it has to be the way he drew polygons (instead of drawing into a scrap buffer and blitting four times, he used BPL*MOD to draw and blit only once).

Unless I'm wrong, a drawback of using interleaved bitplanes to do fewer but larger blits is that the mask for the sprite shape gets bigger too.

If you do several blits, one per bitplane, you get to use the same mask data, but when using interleaved data the mask needs the same shape data * number of bitplanes involved.

It's still a pretty small price to pay compared to Atari ST/ZX Spectrum preshifted bitmaps.

Does that mean you cannot use the Blitter to draw lines and fill area as described in the article?

You'd use a single multi-bitplane interleaved fill-blit if the background surrounding it did not need to be preserved (eg. no mask requirements as per Flow - demos tend to do this for its speed).

I'd imagine Another World creates an off-screen single-bit deep bitmap and uses that as a mask. I sent you an email if you'd like to explore more, however the original programmer probably just remembers what he actually did.

Also note that non-overlapping polygons can be grouped together in both approaches by line-blitting with XOR destination (adjacent polygons share an edge and so the edge is XOR blitted twice); so there are substantial speed-ups to be had.

Thank you so much, I am going to amend the "fill" section. Are you ok with being credited as "quincunx" or you prefer something else?

That's very kind, quincunx is fine, or no credit is fine too. Glad I could be of help.

To maximize performance you'd tend to combine the blitter with a M68k loop, typically using MOVEM to maximize the number of bytes copied per instruction.

The reason for this is that the blitter can not utilize every single memory cycle.

So if you want to maximize graphics throughput you'll need to carefully balance the work between the blitter and CPU depending on which CPU.

There's also a NASTY bit you can set so the Blitter gets the bus cycles it want, any CPU access will have to wait for a spare cycle.

I'm not sure how much faster using that bit will make Blitter graphic operations in practise. I suppose when using 6 bitplanes a small speedup of like 10-20% could be seen.

so fun to see both of you discuss in depth like old magicians

Half-brite was not in the Amiga 1000 and early Amiga 500 and 2000. The later “ECS” chipset has included “halfbrite”. Most games did not take advantage.

Do you know of any games that used halfbrite? I can’t think of a single game that did.

I think there were like three games that used HAM mode, if you filter out “displaying a scan of the box art while the rest of the game loads”. Knights of the Crystallon, Pioneer Plague, and maybe Mindscape?

At least Pinball Dreams did and googling suggests Cannon Fodder. I suppose a few more must be in there.

Edit: https://retrocomputing.stackexchange.com/a/196/4616

Also The Settlers

Black Crypt - http://hol.abime.net/126 Links - http://hol.abime.net/892 Universe - https://en.wikipedia.org/wiki/Universe_%281994_video_game%29

Also interesting is the game 'Universe', which boasted achieving 256 colours on ECS (edit: a comment on the StackOverflow page linked below says it works on OCS as well). Some quick Googling before asking you guys about it as I was planning to turned up this:

https://retrocomputing.stackexchange.com/questions/44/how-to...

The Amiga was such an interesting machine. It's too bad I never got into assembly programming back then.

Psygnosis' Shadow of the Beast used halfbrite, and was heavy on the copper effects too. Gameplay kinda sucked, but it was a hell of a demo against an ST or PC. When it was released no one had seen anything like it. :)

Edit: I suspected many Psygnosis titles used EHB, so I did a quick search, and discovered that the surreal barn-owl based defender clone -- Agony (Shades of Jeff Minter?) indeed used EHB, then got easily sidetracked as someone has made a UE4 based PC clone of it.

https://gamejolt.com/games/agony-unofficial-remake-demo/1601...

I remember my friends and I spent far more time showing it off to people than actually playing it properly.

Which fits, as people involved basically later described the original Shadow of the Beast pretty much as a graphics showcase with "no thought whatsoever" going into more than showing more parallax scrolling and more monsters in.

It's hard to show it to people now and have them understand just how jaw-dropping it looked to people at the time, both to Amiga users, but especially to PC users where most people still did not have graphics cards capable of lots of colours and smooth scrolling with even a single parallax layer, much less the dozen or so in Shadow of the Beast...

I also just realised the intro I remembered showing friends is the intro for Shadow of the Beast II, a game I never bothered playing - but where "everyone" had seen the couple of minutes of animation of the intro, at a time when having a long animated intro like that was in itself a big deal.

Also the smoothness - locked at 50 frames per second, it was mesmerising.

I came from the MSX computers, which usually had blocky character per character scrolling, or slower animations. The PC games were usually even crappier then that. And the Amiga stereo sound, was also incredible if you happened to play a game on a stereo TV set. Most games didn't even bother to mix the sound properly (to slow CPU and/or too few channels, 2 for left, 2 for right) but that the sound had some kind of "depth" not present in mono speakers, also added to the subconscious feeling that this is different.

(3D games - Wolfenstein & Doom - instantly switched the tables, it was obvious that the parrot was not merely pining but actually dead.)

Codetapper has a nice breakdown of how it did things

https://codetapper.com/amiga/sprite-tricks/shadow-of-the-bea...

I still vividly remember Agony beautiful soundtrack. The game itself was very pretty but gameplay was nothing exceptional.

Most Amiga games with parallax used dual playfields mode. AFAIK, you couldn't combine that with EHB.

Shadow of The Beast used dual playfield graphics, not EHB. Agony too, for gameplay. Title screen etc could be EHB.

https://codetapper.com/amiga/sprite-tricks/shadow-of-the-bea...

Fusion was another one that used half brite

http://amiga.lychesis.net/knowledge/EHB.html

I know of one game that actually used HAM (specifically HAM6, the original OCS version) during gameplay and it seemed to run very fast as well - it was a PD game called Zdzisław Bohater Galaktyki 3D and it's, well, not very serious [0].

[0] https://www.youtube.com/watch?v=IV5UPk8ZQZw

It seems all sequences are prerendered, it’s all animation.

Yes indeed, but typically displaying a fullscreen HAM image takes up several seconds [0] of very visible scanline progress. This is pretty much instantaneous and runs on even the base 68000 models, as long as they fulfill the memory requirement (which is admittedly rather hefty - 2MB chip and 8MB fast).

[0] example: https://youtu.be/Y9qzUbT_5Dk?t=95 timestamp and later on as well

That’s just Deluxe Paint being slow. A HAM image is no slower than an EHB image, it’s the same amount of bytes.

Lionheart? Very impressive pixel art, too.

Yeah, and pretty impressive performance wise as well.

It was only early NTSC (only) A1000s that didn't include EHB -- it was OCS, not an ECS feature. Far as I recall all revision A500s and A2000s had EHB. All PAL A1000s had it.

Quite a few games used it for drop shadows and such. Well, the ones that weren't ST identical, which was far too many.

https://en.wikipedia.org/wiki/Original_Chip_Set

Reply on news.ycombinator.com