The Polygons of Another World
fabiensanglard.net
fabiensanglard.net
the A500 had 6 bitplanes, not 5, also, with PAL being the most popular region, I'd say 320x256 was the more popular resolution over 320x200. 6 bitplanes are used for Hold and Modify (HAM mode, where 2 bits select Red, Green, Blue or Palette, and the remaining 4 bits indicate either R G or B values, or the index of the color.) The other 6 bitplane mode is "Halfbrite" which doubles the palette size for a total of 64 colors, where the second half 32 colors are half the intensity of the first half. When running with 6 bitplanes, agnus (the memory controller if you will) steals a lot of cycles for Denise (the display chip) from both the 68K and the blitter. The blitter being crucial for drawing filled polygons.
The second thing that made the Amiga revolutionary (and one could argue, for this reason, that the PCI architecture of Hombre/AAA is not a true Amiga no matter Commodore's demise) - the second thing is the way that Agnus orchestrates memory access much like the microcode inside a CPU orchestrates registers and ALUs. In particular, Agnus controls the memory address lines and chip-register-address lines; the chip-register-address and the memory address lines are opened up simultaneously against eachother with one reading and the other writing. So, for instance, when reading bitplans, agnus opens the chip bus using one of the register addresses 0x110-0x11A for BPL1DAT to BPL6DAT depending on which of the 6 bitplanes is being read; while at the same time driving the appropriate memory address by putting the contents of agnus registers 0x0E0-0x0F6 for BPL1PTL/H to BPL6PTL/H on the address bus of the "chip memory" DRAMs. The datalines of the DRAM and the special chips (Denise here) directly open on eachother (eg. DRAM and Paula chip-selected at the same time.)
I'm not sure if I did it justice and got the elegance of this architecture across in this short post. I'm sure many enthusiasts like me who got their start on the Amiga programming 68K continue to discover new things about this machine.
Good times, warm memories.
I can't speak to why they differ exactly though.
320x200x60 = 384k lines 320x256x50 = 410k lines
Akshually, the horizontal (BW) resolution has little to do with timing. It's as good as the analog components are and as good the computer can output. Amigas had 1280x256 resolution, if you wanted, on standard PAL equipment. (On a fuzzy TV set, you weren't likely to appreciate 1280 horizontal resolution though.)
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?
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 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).
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.
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.
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?
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
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.
[0] example: https://youtu.be/Y9qzUbT_5Dk?t=95 timestamp and later on as well
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...
https://codetapper.com/amiga/sprite-tricks/shadow-of-the-bea...
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.
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.)
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...
Quite a few games used it for drop shadows and such. Well, the ones that weren't ST identical, which was far too many.
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.
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.
The VIC-II would count as custom hardware, I should think, as it sounds as if it was designed specifically for the C64. Same as the Amiga stuff was designed by the Amiga team for use in their computers. And same as the ARM CPU (and the other bits) were designed by Acorn for use in theirs.
>The Amiga 1000 could not boot by themselves, they had no ROM. The bootloader was on a floppy and you better not lose or damage it!
Amiga 1000 has bootloader (Kickstart loader) in ROM, chips U5N and U5P - two 256Kbit EPROMs/mask ROMs, 64KB in total. What it didnt have was firmware(Kickstart, like PC bios) or system(Workbench, like PC DOS/Windows) in ROM. You can see chips containing A1000 bootloader on the motherboard picture, its the two with stickers, right below two 8250 CIA chips https://www.bigbookofamigahardware.com/bboah/media/download_...
You cant boot(load) without a bootloader. Trivia: Back in the day Bill Gates held a record of writing the shortest bootloader for Altair 8800, computer with nothing but LEDs for output and switches for input. You had to input said bootloader every single time you wanted to load something (like BASIC) from tape. 'Computer Notes Volume 1, Issue 6, 1975' Page Twenty-One, Author Bill Gates: “I’ve written a bootloader that only takes 13 bytes of keyed-in data, but anything smaller than 20 bytes isn’t easy to use.”. He was finally beat by one byte in 2017 http://just8bits.blogspot.com/2017/03/doing-it-in-less-than-...
>It was Commodore best selling product with an estimated 6 millions units shipped from 1987 to 1991
other than you know, C64 ;-) and thats not counting other products like Datasette Commodore 1530, shipped with every VIC-20 and C64.
>amiga_arch.svg
Chip RAM is not directly connected to CPU, its gated behind AGNUS https://www.pmsoft.nl/amiga/A500-block-diagram.jpg DBR signal is what switches CPU data bus access.
They were initially called Toro, but there was another company with that name.
As for the choice - they just wanted a nice friendly name, and Amiga was that, being simultaneously a nice sounding foreign word (for the English speakers) by with the known friendly Spanish connotation to many.
After the joystick and joyboard (joyboard was also the source of why Amiga crashes are called Guru meditations) production died off, they were left with only Lorraine, so Amiga became the machine name too...
My understanding is that Kickstart contained both Exec (the kernel) and Intuition (the windowing GUI library), so it was more than a BIOS.
The Datasette did not ship with every VIC-20. There were plenty of non-Commodore datasette clones on the market, however.
Realistically every single C64/VIC-20 user, and probably at least 1/2 of C128 ones had a tape drive, bulk of them manufactured by Commodore.
btw C128, considered a failure by many (including me), sold 4.5 million units, right in the ballpark for total Amiga, all models combined, worldwide sales.
>pc_arch.svg
VGA was hanging off 16 bit ISA bus. CPU wasnt touching ISA, Ram wasnt touching ISA. You had chipset with build-in memory controller, ISA arbitration and fast Cache was the norm. Typical contemporary 386/486 motherboard diagram http://www.textfiles.com/bitsavers/pdf/samsung/pc/98134-925-.... page 1-1 system block diagram will explain a lot.
> clear the screen
this must be the worst clear screen routing of all time :o why bank switch at all? setting mask to 0xff once will write to all of them at the same time
outpw(0x3c4, 0xff02);
memset(VGA,0, 8000);
>SOLVING COPY, 4x speed up
Transfer speed when writing to non crappy 16bit ISA VGA card is ~3MB/s. Reading is always slower, nobody optimized graphic cards for reading, sometimes even ending up under 1MB/s. I think I read Abrash or Carmack stating that IRL on real hardware this ended up being a wash in terms of performance.
>SURPRISINGLY DIFFICULT AUDIO, On Amiga and ST it was a piece of cake
ST has no native PCM output. Atari uses "Yamaha" YM2149 aka re-licensed AY-3-8910, audio chip from ZX Spectrums and Amstrad CPC. Its the same pain as trying to play PCM on Adlib (volume register?), except even lower fidelity.
The Amiga's blitter could write almost 4Mbs per second (if you set things up juuuust right and you had the wind behind you). On a modern monitor (a modest 1920 * 1080) the Amiga's blitter would take almost 2 seconds just to clear the screen.
It's one of my most replayed games ever. Even when I know the plot and there are no surprises, this game manages every time to take me to... (cue music) ANOTHER WORLD.
"...it is the original version built from 1989 to 1991 by then 21 years old Eric Chahi working alone in his bedroom."
Because he got royalties from an earlier game, and that paid enough for him to take on this project. And he did pretty much everything except the music: Programming, graphics, story, box art. One dude. One 21yo dude. In his bedroom. And he wrote a VM! He wrote his own bytecode! He wrote his own VM host in assembly!! And then he wrote the game in his own bytecode!!!
And then you have the people who ported games in this time period, who often got nothing to work with. No code, no comments, no assets. Disassemble the thing yourself on a platform you might know very little about, and re-write the thing on a platform you do know a lot about. You get a couple of months. Chop chop, the publisher is waiting.
And if you haven't read Jordan Mechner's journals of him writing Prince of Persia from the same era, you should. It's equally bananas. And impressive.
The more important thing to note is that the brutal constraints of the day and the extremely high bar to entry acted like a pre-sorting mechanism but also fueled the best and brightest to exceed their perceived limitations and unleash their creativity.
Compare and contrast with today, where the low bar to entry has led to a proliferation of garbage-level work (on all levels, not just games) that tends to not only drastically decrease SnR but calibrate the "standard". When everything looks like mediocre garbage, this is what everyone expects.
And with that still comes some gems to go along with the garbage, so in the end, we win.
I also enjoy that we still have a modern-day version of small indie developers (sometimes also one-person teams) building and shipping games.
It is of course a different landscape today and most small or single-person teams are working with an engine like Godot, Unreal or Unity (or many others), but given the increased complexity (and capability) of the underlying hardware, this sort of makes sense.
Also look for Another World – 20th Anniversary Edition.
Btw it's not as good but the sequel, heart of the alien, is only on the segacd.
I hunted down a Sega CD and Genesis just to play it.
I rushed, hoping to find some oldskool tricks and remember my time spent reading Denthor's VGA Trainer[0].
It seems I'll have to wait some more chapters for that, though. :-)
I don't think this idea would scale well for much bigger projects, as debugging internal scripts can quickly become a bottleneck.
Tooling is a perennial problem with extension systems, but it’s really damned if you do, damned if you don’t. If you’re not using an extension system, then you’re probably writing the game logic and the engine as one giant mass of C++ code. Writing tons of game logic in C++ will get you in trouble for lots of reasons. Writing an interface between your C++ core and some kind of scripting system will get you in trouble for completely different reasons.
Tim Sweeney did a presentation about the programming environment needs of different parts of games back in 2005, still worth reading: https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...
The strategy of using a bytecode VM to ship cross-platform games seems to have been pretty popular back then, which is a little surprising to me -- I thought Java came up with that idea first!
https://en.wikipedia.org/wiki/Short_Code_(computer_language)
The reason was to save space, as well as not having to constantly update the software as the hardware specs changed.
So in 1 bpp hires mode, there's just a single bitplane (and the memory layout is identical when comparing to Amiga 640x400 interlaced hi-res 1 bpp screen mode). In 2 bpp medium res (640x200, 4 colors), there are two bitplanes, alternating bitplanes for every 16-bit word. So 16 bits of bitplane 0 for the first word, then 16 bits of bitplane 1 for the second word (these together form the first 16 pixels), and so on. In the 320x200 low res mode there are four bitplanes interleaved in the same way.
What this means from the programmer's perspective is that you can do similar bitplane tricks as with Amiga, e.g. modify just one of the bitplanes independent of the others. For instance effects where car headlights change the background image colors can be done the same way on both machines: render to just one bitplane and use the palette to achieve the change in colors.
However, when with Amiga it's trivial to modify bitplane pointers independent of each other to scroll graphics around, on Atari ST all bitplanes are tied to the same base pointer (because they are interleaved in the memory). (And to make things like full-screen scrolling even more difficult, this base pointer is aligned to 256 bytes, i.e. the low byte of the video memory base address is always 0 on Atari ST - on STE this is programmable.)
There are some cases where the interleaved bitplane format gives benefits: while neither of the machines are good for writing texture mappers (or other effects that require manipulation of single pixels), it's slightly more efficient on Atari ST because the layout allows some tricks (e.g. using MOVEP instruction to write 8 pixels to all 4 bitplanes at once from a single 32-bit register).
From the point of view of a game like Another World, the bitplane arrangement of Atari ST doesn't really cause additional problems when comparing to the Amiga. The issue is the lack of blitter (and STE blitter isn't that great improvement, it doesn't have the line drawing capabilities of Amiga blitter and has less flexible src/dst mechanism, so no wonder it isn't utilized by the game).
The interesting thing about it was, it was a polygon game that ran without using the SuprFX chip.
With the SNES being sprite-based I could never figure that out.
>[...] They also wanted to replace all the music made by Jean-François. I had yielded for the extra songs, but I wanted to keep the music of the introduction, as it perfecly matched the atmosphere and the animation timing. This became a real struggle [...] So I took drastic measures. I thought of creating an endless fax. A huge fax of a meter long in which I wrote in big letters "keep the original intro music". I would insert it in the fax, enter the number, and when the transmission started, I would tape both ends of the letter together, which would create a circle that went on and on until there was no paper left in the offices of Interplay, at the other end.
http://www.anotherworld.fr/anotherworld_uk/another_world.htm
After a bit, though, I realized it wasn't that the 3DO version was underwhelming, but instead that the Genesis version was amazing. It already felt like a next-gen game, and so the upgrade to the 3DO didn't make a huge change.
In the end, it has become one of my favorite games. I love the art, the style, the cutscenes, and even though it's incredibly short, I love the story.
I never played Heart of the Alien, because I never had a Sega CD, but I'd like to play it at some point on an emulator.
It's also just a lovely piece of art.