
The Polygons of Another World: Atari Jaguar - masklinn
http://fabiensanglard.net/another_world_polygons_Jaguar/index.html
======
jlokier
I'm a former Jaguar developer too, and reading the article was a strange
experience, remembering things from ages ago. I'd forgotten most of the
details, as well as how it felt.

Also the Atari ST mention. I'm getting all sorts of 80s and 90s flashbacks
from that story, of what it "felt" like to program on those machines.

All those _fiendishly clever_ timing and register hacks to make the video and
audio hardware do things it wasn't designed to do, well outside their design
parameters, and other tricks to make 8-bit and 16-bit machines generally do
things nobody thought possible, until it was.

That feeling is something I miss a bit, as it's difficult to find tricks that
make the "impossible" possible on modern hardware.

[Edit: I suppose Spectre and friends qualify :-)]

~~~
alexisread
The stories of the ST (AMY chip
[http://www.atarimuseum.com/computers/8bits/XL/ASG/Chips/AMY/](http://www.atarimuseum.com/computers/8bits/XL/ASG/Chips/AMY/)),
STE botched launch
([https://www.youtube.com/watch?v=oarR61SeY8E](https://www.youtube.com/watch?v=oarR61SeY8E)),
Falcon
([https://www.youtube.com/watch?v=cBTXGgb__y4](https://www.youtube.com/watch?v=cBTXGgb__y4)),
Lynx ([https://www.mentalfloss.com/uk/games/36270/atari-lynx-the-
wo...](https://www.mentalfloss.com/uk/games/36270/atari-lynx-the-worlds-first-
colour-handheld-games-console)) and Jaguar (see other comments in this thread)
all make great stories!

Some of the stuff that were done on the machines is jaw dropping - realtime
raytracing on the Falcon for instance:
[https://www.youtube.com/watch?v=_cKRZ8QgH5o](https://www.youtube.com/watch?v=_cKRZ8QgH5o)

Doom on the Atari ST (not Wolfenstein, more sophisticated with heightmaps,
lighting, 64 colours etc):
[https://www.youtube.com/watch?v=QCvx2O5M69E](https://www.youtube.com/watch?v=QCvx2O5M69E)

Complex texturemapping on Atari ST:
[https://www.youtube.com/watch?v=gHwUchzEG8k](https://www.youtube.com/watch?v=gHwUchzEG8k)

Polygon landscapes on the Lynx:
[https://www.youtube.com/watch?v=DPexnRsNJDs](https://www.youtube.com/watch?v=DPexnRsNJDs)

~~~
rasz
You forgot stock 16MHz 1992 Falcon Quake 2 engine
[https://www.youtube.com/watch?v=WpwlZgQPCpk](https://www.youtube.com/watch?v=WpwlZgQPCpk)

------
drcode
As a former Jaguar developer, I'm getting PTSD just looking at the diagram
with the four different CPUs, all on the same memory bus in constant
contention, all with their own unique machine instruction set.

~~~
Someone
I didn’t know much about this, but was surprised to read _”a Motorola 68000
[…] running at 14Mhz […] two 32-bit RISC processors running at 26.59 MHz“_

I wondered how those could share a bus, with that weird 1: 1.899 ratio between
CPU frequencies. I think
[https://en.wikipedia.org/wiki/Atari_Jaguar#Processors](https://en.wikipedia.org/wiki/Atari_Jaguar#Processors)
answers that. It says the 68000 ran slightly slower, at 13.295 MHz. That makes
the other clocks exactly twice as fast.

~~~
basementcat
Devices can exchange data across clock domains.

[https://en.wikipedia.org/wiki/Clock_domain_crossing](https://en.wikipedia.org/wiki/Clock_domain_crossing)

[http://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V3/2...](http://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V3/2s/V3.Ch7-2s.PDF)

~~~
monocasa
Yeah, but it's weird for devices in different clock domains of the time to
share a classic parallel system bus. They "can" theoretically, but practically
they didn't because of the latency that cross domain clocking imposed.

------
the_af
I find the Amiga graphics are the nicest, then the Jaguar, then the 3DO's are
so terrible and overwrought I never would have liked this game if this was the
first version I played.

Nostalgia? Maybe. But I find the minimalist polygon graphics of the original a
big part of what made Another World a big hit. At least to me. In my mind this
is related to the concept of "closure" as described in "Understanding Comics":
the more abstract, more symbolic the graphics, the more my mental processor
can give it hyperrealistic meaning in my mind; conversely, the more detailed
the graphics, the less interesting they become and the less room for my mind
to "complete" them. The beast as a black outline with eyes and fangs is
terrific (and terrifying). The beast as a more detailed rendition would
probably just look silly.

Plus, you know, the polygon graphics look _objectively_ cool ;)

~~~
vidarh
I was an Amiga user, and I certainly can see why you prefer it, but the Jaguar
ones look great as well (something I'd never have admitted to back in my Amiga
days when Atari was "the enemy") - it feels like pixel art made for the
resolution.

The problem with the 3DO one to me is that it looks like it was just
downsampled from a high resolution image rather than was being drawn for the
resolution it was rendered at.

~~~
noizejoy
> back in my Amiga days when Atari was "the enemy"

To the best of my recollection that was the first major fanboi war in
computers, also amplified by the advent of pre-internet online community in
the form of BBSs (Bulletin Board Systems). I fondly remember accessing
GEnie[0] from my trusty Atari 1040ST (my first home computer, since it had
midi builtin).

However, I have to admit, the whole fanboi thing struck me as silly, since
Amiga’s were graphically superior, while Atari ended up attracting midi
developers and users. Not until much later did I realize, that in marketing
terms, a fanboi war may very well benefit both sides. So while I still shake
my head at fanboi posts, I also see why manufacturers like those wars.

[0] [https://en.wikipedia.org/wiki/GEnie](https://en.wikipedia.org/wiki/GEnie)

~~~
TomVDB
_To the best of my recollection that was the first major fanboi war in
computers, ..._

Definitely not the first major one! I fondly remember endless back and forth
discussions between proponents of the magnificent Commodore 64 and adherents
of the despicable ZX Spectrum.

~~~
Marazan
So close but deeply wrong. The Spectrum was the path of goodness and light and
the C64 was the route to beige coloured damnation.

~~~
the_af
I disliked the Speccy back then: I owned a C64 and my friend a Sinclair (which
was a Spectrum clone if I remember correctly) and back then I thought the C64
was so much better: better sound, better colors, less "artifacts" in color
graphics...

... now I see the Spectrum and I have a newfound respect for it. It was
technically inferior but there was a certain grace in how game devs worked
around its limitations and weird color palette. And the graphics were crisper
than I remembered.

~~~
vidarh
Sinclair Research (after sir Clive Sinclair, the founder) was the developer
and original owner of Spectrum. The classic Spectrum models are either from
Sinclair or a version developed by Timex (who also did a lot of the Spectrum
manufacturing, I think) under license.

There were a number of clones too, but Sinclair is the real deal and Timex
Sinclair was officially licensed.

Later the Spectrum was sold to Amstrad - at which point you got the Spectrum
models that looks like Amstrad computers.

------
corysama
The link skips over the part explaining that this is part of a series about
how Another World was implemented on many platforms:
[http://fabiensanglard.net/](http://fabiensanglard.net/)

Also, in this video
[https://www.youtube.com/watch?v=tiq0OL8rzso&t=2m](https://www.youtube.com/watch?v=tiq0OL8rzso&t=2m)
the person who implemented the SNES version tells the story first-hand.

------
hcarvalhoalves
Funny how Sony did a similar thing (and had similar problems) with the Cell
architecture of the PS3.

The developers who took the time to really target the platform (Naughty Dog?
Kojima Productions?) managed to extract a lot of performance from it, and PS3
really felt like something from the future for the time, but it made
developing and porting to the platform much harder.

(The difference is that the Cell architecture was more like cluster
architecture, just focused on multiprocessing, while this Jaguar seem to have
unique components each with unique quirks)

~~~
h0l0cube
It's more analogous to the PS2 and it's pipeline of arcane custom chips. All
of them had their own flavor of assembly, including a few chips that handled 2
opcodes per line, each operation with different cycle latencies. These chips
had to be driven by the DMA and synchronized with double buffers, to ensure
you had a decent fillrate of polygons. The CPU had a 'scratchpad' which you
could access in 1 cycle (as opposed to 30-200 from main memory depending on
cache misses), and would also be piped in by the DMA. Also, one of its vector
processors was accessible (slowly) directly from the main CPU as a coprocessor
(the so-called macro mode), but could also be driven by the DMA (micro-mode).
The main processor and the input/output processor were two flavors of MIPS,
the latter being the same as the PS1 presumably to provide emulation.

I'm certain the PS2 architecture was written by a mad genius - and it took one
to use it's system to the max. If it wasn't for popularity the PS1, it might
have gone the way of the 3DO. The PS3 was a dream to work with in comparison.

------
jlokier
On the Jaguar, I was employed to write a custom engine for a 3d fighting and
exploring game with some unusual art:
[https://en.wikipedia.org/wiki/Legions_of_the_Undead](https://en.wikipedia.org/wiki/Legions_of_the_Undead)

My approach to squeezing the most out of the Jaguar was to start by getting a
fairly complex fused tiled-polygon-and-texture rendering algorithm working on
the 68000 first, written mostly in C++ for GCC, with some of the classes
generated in Lisp.

To get all the geometry and other details right and focused on feeding calls
to a texture-scan-line inner loop.

Then to switch the inner part to a fast, asynchronous command pipe, pushing
commands to the GPU/blitter et al. which would read and execute those as fast
as possible. And then as needed optimise any bottlenecks on the 68000 using
assembly.

The idea was to keep the GPU/blitter as busy as possible filling pixels from
simple texture-line commands, with minimal logic to fetch and setup each new
blit (i.e. no higher level geometry calculations during which the texturing
would be idle), while the 68000 ran in parallel generating those commands and
doing the higher level geometry, which was quite complex in our game.

I got everything running just right on the 68000 for a nice demo, with the
graphics and maps we had ready by then. It was visually perfect, and play
speed was just about usable but not _smooth_ like we were aiming for.

Unfortunately perhaps, that's when Atari called my boss in to do a milestone
demo, so that version was shown.

When my boss returned, I was told whichever Tramiel was head of Atari at the
time was "angry" as the game looked "too slow", and the project was cancelled.
:-(

Just as I was getting the GPU/blitter accelerated mode working, which was
projected to be 2 weeks work (since everything up to that point had been aimed
at this).

I never did get to complete or show off the fast version. So close!

Atari was in trouble and collapsed very soon after, so maybe that wasn't the
real reason.

We then started moving the project to the Fujitsu FM Towns:
[https://en.wikipedia.org/wiki/FM_Towns](https://en.wikipedia.org/wiki/FM_Towns)

And then the PC using DJGPP.

The geometry, texturing and physics systems could be moved over because they
were mostly GCC-compatible C++. (At the time different C++ compilers accepted
different dialects.)

But all the effort around optimising the engine around pushing pixels as fast
as possible out of the Jaguar's hardware subsystems had to be abandoned.

Fortunately the pipeline architecture translated quite well to x86 texturing,
first using awesome integer register tricks (very few registers on x86, but
because you could address individual bytes and words inside dword registers
you could "vectorise" some of the texturing and address arithmetic); later the
FPU became faster.

This was in the days of Doom, Quake and Descent, when extremely hand-optimised
assembly software rendering was normal on PCs, and consoles had very strange
"not quite right for 3D" blitters. (Ask about the Sega Saturn sometime.) GPUs
as we now know them were just starting to be created for PCs, and Microsoft
launched DirectX a year or so later.

\--

The Jaguar's CRY colour space was not great. We had a very large graphics
asset pipeline at the time, derived from hundreds or thousands of photos of
real physical models made by the artists (a very different look than drawing),
and all of it had to be scaled, alpha-clipped and quantized into CRY, which
was not kind to the colours. Adequate, but not great use of the colour bits
available.

Somewhere I'm pretty sure I still have a "pnmtocry" executable in Linux a.out
format :-)

~~~
jopamer
I just wanted to say that I enjoyed this comment _so much_. As a Jag owner at
the time I remember being taken by the production shots of that game that
popped up in magazines, and couldn't wait to see it in motion. The craftiness
necessary to pull off a compelling rendering pipeline on the hardware of that
time period, combined with the aesthetic directions the constraints pushed
designs in, still inspires me. (And somewhat indirectly led me down my own
career path.) Thanks!

~~~
jlokier
Hey, thanks for the uplifting comment!

If we had published on the Jaguar, maybe that would have led to a whole
different career for me too :-)

It's lovely to think someone outside the company enjoyed it. Because it was
never published, it felt like multiple years put into something that just
disappeared, and I didn't get much feedback from outside the company. That
happened with the next game I worked on too, Mr Tank, which was more
technically advanced and a lot of fun to play in the demos.

------
zanderwohl
The color space is probably one of the stranger things I've seen. I wonder
what led the designers to choose that scheme. I'd love to see the design
considerations for this whole system.

~~~
XaspR8d
It's not _conceptually_ that different from YUV[1], the color spaces used by
PAL television and most JPEG images. I can't speak to the Jaguar, but both of
those decisions were motivated by the desire to completely separate the
luminance/brightness dimension from the 2 color dimensions. For PAL this was
to maintain compatibility with black and white televisions during the slow
adoption of color, for JPEG it's a compression trick since the chroma channels
can be downscaled more than the grayscale without humans noticing as readily.

In any case I'd argue the ability to reason about this space is a bit more
natural than RGB (and a bit less than HSV) too.

But I'm sure there were some other specific requirements they were trying to
satisfy...

[1] - [https://en.wikipedia.org/wiki/YUV](https://en.wikipedia.org/wiki/YUV)

~~~
zerocrates
YCbCr (often called YUV for... reasons) and 4:2:0 chroma subsampling (half the
vertical resolution for each plane of color information as for the brightness)
are still the dominant color encoding used for digital video, HDTV, Blu-ray,
etc.

The "CRY" model used by the Jaguar is fairly different than (though as you
say, related conceptually in its separation of brightness/darkness
information, of course). I think it basically just arose from a combination of
big focus on smooth shading while keeping the color values workably small and
fast to calculate on.

------
jimbo1qaz
The URL links to the #back_1 anchor/id and ends up half a page down.

------
lostgame
Are there any particularly good interviews with Jaguar developers? I love
getting into all the tiny nerdy details of old game systems.

~~~
djmips
Maybe someone could interview drcode from the top comment!

~~~
drcode
It's been done: [https://www.stitcher.com/podcast/the-atari-jaguar-game-by-
ga...](https://www.stitcher.com/podcast/the-atari-jaguar-game-by-game-
podcast/e/55849591)

------
rasz
>Three years later, with the Jaguar project ahead of schedule, Atari decided
to abandon the Panther and released its 64-bit machine in November 1993

so ahead of schedule they released Broken hardware (for example SRAM
scratchpad was supposed to be cache, but that didnt work) with Broken SDK on
top (generated code had tendency of randomly crashing).

------
guerrilla
If you want to see how the gameplay looks, check it out:
[https://www.youtube.com/watch?v=wjMf_bEfqIc](https://www.youtube.com/watch?v=wjMf_bEfqIc)

This is the PC port so I'm not sure if it looks exactly the same as the
original...

~~~
teddyh
That’s the 20th Anniversary edition; it has been graphically enhanced from the
original. In that linked video, you can see at 3:22 where the player, probably
by mistake, switches back and forth between the original graphics and the
enhanced version, but just for a second.

------
jordache
amiga graphic ages the best.

3DO is nasty looking

------
superdisk
I love this series, it's just so comfy (and informative) to read.

~~~
fabiensanglard
Thanks!

~~~
bni
I agree with the parent post.

One really interesting game to analyse technically would be Bioforge. Golden
era MSDOS game that used some not seen before tech.

