[HN Gopher] New 3D FPS released for 1979 Atari 800
___________________________________________________________________
New 3D FPS released for 1979 Atari 800
Author : legoxx
Score : 320 points
Date : 2021-11-03 14:13 UTC (8 hours ago)
(HTM) web link (atari8.dev)
(TXT) w3m dump (atari8.dev)
| Minor49er wrote:
| The theme song linked at the bottom reminds me a lot of the
| System Shock 1 theme song
|
| https://www.youtube.com/watch?v=uZRuDOqIIBA
| spicybright wrote:
| I have so much respect for people that take on challenges like
| this.
|
| It might be "useless" in a utilitarian sense, but I think of it
| as an incredible art form.
| buescher wrote:
| To be pedantic, it needs a 64K machine like the 1982 1200Xl or
| 1983 800XL so would not run on the (max w/o 3rd party mods) 48K
| Atari 800 from 1979. But yes, wow!
| protomyth wrote:
| Both the 400 and 800 had upgrades to 64K. The Atari 400
| required some soldering and the 800 was simply a plug-in
| expansion.
| CWuestefeld wrote:
| Not so. Behind the two ROM cartridge slots there were three
| slots for RAM expansion, each being 16KB.
| protomyth wrote:
| Yeah, the 16KB cards were from Atari and the banked
| switched cards were from third parties. Antic Magazine
| (named for the chip) had a lot of ads in the back for
| those.
| karmakaze wrote:
| That's for the Atari parts using linear addresses. There
| were numerous third-party memory expansions that used bank
| switching as in the XL's to get much more. I wrote Point-
| of-Sale software using 128K banked expansion for an 800.
|
| I also had my 400 upgraded to 48K with a mechanical
| keyboard.
| michaelcampbell wrote:
| IIRC (and I may not), I upgraded my 400 to 64k, and a "real"
| keyboard. But I think you could only address 48k of it at once
| or something hinky.
| buescher wrote:
| Yeah, you had ROM space (and potentially cartridge ROM space)
| eating into your 64K on all the models and had to bank-switch
| for anything more than 48K IIRC. With a BASIC cartridge in
| place you'd lose another 8K.
|
| Also I don't recall any of the 400/800 3rd party upgrades
| being compatible - they used a different bank-switching
| mechanism - with the later XL/XE models.
| michaelcampbell wrote:
| "bank switching" sounds familiar, so I'm pretty sure my
| memory of 64k is correct then. I can't say I understand
| what it means, but I remember something of that term at the
| time.
| bluGill wrote:
| You group your memory into groups of 16k (could be other
| sizes, 16k is what I recall but it has been years). Then
| you have a switch that you can program the switches
| between groups (also called banks). You can only access
| one at a time, but you can switch between them very fast.
| It was possible to get up to 5 MB of memory that way,
| even though you could only use 64K at a time.
| protomyth wrote:
| Where did you get a real keyboard for the 400. I searched and
| searched and could not find one. I was so envious of the
| Timex / Sinclair folks who had a nice replacement.
| michaelcampbell wrote:
| I can't remember but it was designed for the 400. This was
| circa 1983.
| atum47 wrote:
| I tried to write a raycast [1] in JavaScript once, I used lines
| instead of the traditional grid, but it end up messy and with
| weird texture artifacts. Still, I would like one day to come back
| to this and do a proper job.
|
| I'll download the game after work and see if I can run it under
| an emulator, but the graphics and music alone seems wonderful.
|
| 1 - https://github.com/victorqribeiro/myRaycast
| greggman3 wrote:
| This isn't a complaint, it's a suggestion. Would be cool if I
| could just run it in my browser like https://www.2600online.com/
| pixelpoet wrote:
| Having written realtime ray tracers in the classic demoscene
| style on e.g. 300 MHz Pentium 2 Celeron (the original one with no
| cache, that overclocked to 450-550 MHz), I sometimes wonder about
| how cool it would be to open source a modern rendering engine
| around the time of the first Pentium 3 with SSE, in 1999.
|
| You could completely revolutionise computer graphics on that era
| of hardware, with the view to increasing vectorisation, and
| probably strongly steer it towards ray tracing instead of
| rasterisation (even skipping over the local minimum of k-D tree
| methods, the introduction of Surface Area Heuristic and
| eventually settling on modern BVH building and traversal).
| [deleted]
| codedokode wrote:
| The game uses ray casting, not ray tracing. Ray casting is when
| you send a ray once for every column of pixels to get a
| distance to a wall. Also, if the walls are only horizontal or
| vertical the calculations get simpler.
|
| Also I wonder how you can achieve clock frequency like 300 MHz
| without a cache. Shouldn't CPU stumble on fetching every
| command?
| dahart wrote:
| > The game uses ray casting, not ray tracing. Ray casting is
| when you send a ray once for every column of pixels
|
| Both 'ray casting' and 'ray tracing' are overloaded terms,
| the distinction isn't as clear as you suggest. You're talking
| about 2d ray casting, but 3d ray casting is common, and means
| to many people the same thing as 'ray tracing'. Ray casting
| "is essentially the same as ray tracing for computer
| graphics". https://en.wikipedia.org/wiki/Ray_casting
|
| There's also Whitted-style recursive ray tracing, and path
| tracing style ray tracing, but ray tracing in it's most basic
| form means to test visibility between two points, which is
| what ray casting also means from time to time.
| giantrobot wrote:
| The Covington Celerons had an L1 cache but no L2 cache. The
| Pentium II of the era had an off-die L2 cache. So the
| accelerometer was a binned Pentium II without any L2 cache. A
| later model of the Celeron was released with a 128k L2 off-
| die L2 cache.
|
| At its base clock speeds the Celerons were middling chips.
| But since they readily overclocked you could get them up to
| 450-466MHz. They wouldn't be equivalent to the same speed
| Pentium II (because of no L2 cache) but they punched above
| their weight for the price.
| romwell wrote:
| First time reading about BVH. Sounds like Kirkpatrick's
| hierarchy, but in arbitrary dimension.
|
| What's the advantage over BSP/kD-trees/octrees?
|
| And what do you mean by rasterization - we still have to deal
| with pixels in the end, so it has to happen somewhere? (..I'd
| love to play with a color vector monitor though!).
| pixelpoet wrote:
| > What's the advantage over BSP/kD-trees/octrees?
|
| With BVH, the partitioning is fundamentally over lists of
| objects rather than space; if you split by space, you
| can/will have objects on both sides of the splitting plane,
| leading to duplicate references.
|
| Doing it by lists means there are no duplicate references,
| however the combined bounding volumes can overlap, which is
| to be minimised, subject to the Surface Area Heuristic cost.
| It winds up being something like a quicksort, although for
| the highest quality acceleration structures you also want to
| do spatial clipping... this is an extremely deep field, and
| several people have spent considerable part of their
| professional career to it, for example the amazing Intel
| Embree guys :)
|
| It also happens to work out best for GPU traversal
| algorithms, which was investigated by software simulation
| quite a few years ago by the now-legendary Finnish Nvidia
| team, and together with improvements on parallel BVH building
| methods and further refinements is basically what today's RTX
| technology is. (As far as I'm reading from the literature
| over the years.)
|
| Here's a fundamental paper to get started:
| https://research.nvidia.com/publication/understanding-
| effici... (Note that these are the same Finnish geniuses
| behind so many things... Umbra PVS, modern alias-free GAN
| methods, stochastic sampling techniques, ...)
| t8sr wrote:
| Octrees divide space into regular sized chunks. BVH divides
| space into chunks of varying size, but with a balanced
| population of bodies in each. The idealized BVH divides the
| population by 2 at each level.
|
| Compared to octrees, BVHs deals well with data that's
| unevenly distributed. At each level you split along the axis
| where you have the most extent. Finding the pivot is the
| interesting part. When I recently implemented a BVH from
| scratch, I ended up using Hoare partitioning and median-of-
| three and it worked really well. The resulting structure is
| well balanced, splitting the population of bodies roughly in
| half at each level, and that's not even the state of the art,
| that's just something my dumb ass coded in an afternoon.
| dahart wrote:
| > And what do you mean by rasterization - we still have to
| deal with pixels in the end, so it has to happen somewhere?
|
| At a high level, you could think about it as where in your
| nested loops you put the loop over geometry (say, triangles).
| A basic rasterizer loops over triangles first, and the inner
| loop is over pixels. A basic ray tracer loops over pixels,
| and the inner loop is over triangles (with the BVH acting as
| a loop accelerator). Just swapping the order of the two loops
| has significant implications.
| q_andrew wrote:
| I was under the impression that the theory was there but the
| hardware was not. Like, rasterization was a necessary evil
| because it gave better results more quickly (and artists needed
| that feedback).
| fistynuts wrote:
| Yes, absolutely right, and for games it was the only option
| with no fast floating point and very limited memory.
| chaganated wrote:
| i'm not surprised. atari 800 was an exceptional machine. great
| work on the game though.
| jhbadger wrote:
| Yes, it had a lot of custom chips, and some of the same people
| (like Jay Miner) who worked on the Atari 800 design later were
| involved in designing the Amiga which likewise was based on
| custom chips.
| legoxx wrote:
| there were 3 custom chips (ANTIC, GTIA and POKEY) 1 semi-
| custom (SALLY was a VERY MINOR modification of 6502) and 1
| common industry chip (PIA). I would not say exactlly "lot of"
| ;-)
| verifex wrote:
| Download link isn't working, for anyone that is trying to
| download it.
| legoxx wrote:
| It is working very well for me Verifex. Please try
| https://atari8.dev/final_assault/Final%20Assault%201.0.zip
| mysterydip wrote:
| I was expecting a very basic raycaster, no textures etc. This is
| seriously impressive!
| buescher wrote:
| I was expecting it to need 128K!
| mypalmike wrote:
| Yeah just updating every pixel randomly at 20 - 30 fps is a
| feat on the 8 bit Atari, nevermind with a raycaster.
| GekkePrutser wrote:
| Wow this looks amazing. Will give it a try on my real 800XL.
| lizknope wrote:
| I had an Atari 800 in the early 1980s. The games were close to
| the arcade version and with the BASIC cartridge we could write
| programs and save them to a cassette tape drive or floppy.
|
| https://en.wikipedia.org/wiki/Atari_8-bit_family
|
| Jay Miner was one of the main developers who later went on to be
| the "father of the Amiga"
|
| https://en.wikipedia.org/wiki/Jay_Miner
| r00fus wrote:
| Was so jealous of my friends that had an Atari 400 even, the
| 800 was legendary.
| varelse wrote:
| 1982 is calling but expects to be connected to some HN pedant
| "helpfully" pointing out that you can't actually shoot stuff.
|
| https://youtu.be/j4OLnrwLcJA
| buescher wrote:
| The Lucasfilm games ('84-'85) blew my mind at the time.
| Fractalus, Ballblazer, Koronis, Eidolon.
| varelse wrote:
| Hot take: The Eidolon is more impressive than this effort and
| it works with the technological limitations of the platform
| rather than against it like this does.
|
| All those LucasArts games were stunning for the time and
| Rescue At Fractalus has a genuinely terrifying experience
| within it not replicated IMO until the first time you hear
| "Anytime..." in Alien vs Predator...
| kingcharles wrote:
| That's incredible. Was this the earliest instance of raycasting
| in the wild?
|
| Good intro to raycasting for those interested:
| https://lodev.org/cgtutor/raycasting.html
| varelse wrote:
| I _think_ it is. But... But PLATO Moria might be the OG of 3D
| in this space.
|
| https://en.wikipedia.org/wiki/Moria_(1978_video_game)
| ThomW wrote:
| I had their follow up game Capture the Flag on my Atari 800.
| Same engine, but slightly upgraded graphics. Fun game!
|
| https://moegamer.net/2019/03/05/atari-a-to-z-capture-the-fla...
| varelse wrote:
| I once walked out of a John Carmack SIGGRAPH talk when he
| opened with claiming he invented the FPS because of Ultima
| Underworld, The Eidolon, and Way Out...
|
| Like him otherwise, but nope he didn't invent it...
| legoxx wrote:
| Slovak group GMG released a full featured FPS for 40+ year old
| computer (64kb of ram, 1.79Mhz 6502)
|
| Features:
|
| - raycaster engine running at 25 - 30 FPS
|
| - animated textures
|
| - lighting system
|
| - destroyable walls
|
| - automap
|
| - 3 enemy types
|
| - final boss
|
| game is fully playable in Altirra emulator
|
| video: https://www.youtube.com/watch?v=lRd3MucaRoU
|
| homepage: https://atari8.dev/final_assault
|
| discussion: https://atariage.com/forums/topic/326709-final-
| assault-new-g...
| aliswe wrote:
| the FPS is really smooth - and the floating point (?!)
| calculations of the raycasting engine seem to be totally "on
| point" ?!?!
| flatiron wrote:
| Comment a bit of a limitation of the ray casting:
|
| https://atariage.com/forums/topic/326709-final-assault-
| new-g...
|
| simply amazing what they did. could you imagine if this came
| out in the 80s?!?!
| GekkePrutser wrote:
| Yes this would have been mind-blowing.
|
| Ps there was a game that had a similar FPS view in those
| days. It was a maze game with polygon graphics but no
| textures. I forget the name. No shooting though!
| Thoreandan wrote:
| * Mercenary: Escape from Targ (Novagen)
| http://mercenarysite.free.fr/mercframes_graphic.htm "open
| world" vector FPS/RPG, fully RAM-resident, in 48k & 64k
| editions.
|
| * Alternate Reality: The City (Datasoft/Paradise
| Programming) FRPG with 90-degree turns, rendered
| walls/doors as scaled textures between the animated
| backdrop and foreground NPC sprites.
|
| I wrote an FAQ as a kid for Mercenary for local BBS' - I
| think I discovered at least 3 victory conditions. :^)
| laumars wrote:
| There were a few.
|
| I had Sultans Maze[1][2] and Articfox but plenty others
| existed too.
|
| [1] https://en.m.wikipedia.org/wiki/Sultan's_Maze
|
| [2] https://youtu.be/af1CfayG5Ec
|
| [3] https://en.m.wikipedia.org/wiki/Arcticfox
| mywittyname wrote:
| So I was curious about how the Atari 800 handled floating
| point calculations. As it turns out, Steve Wozniak helped
| develop the FP routines for the 6502.
|
| http://archive.6502.org/publications/dr_dobbs_journal_select.
| ..
| codedokode wrote:
| I doubt there are any floating point numbers because FP is
| very slow to emulate (for example, just to add two numbers
| you have to shift mantissas and 6502 has no fast way to do
| it). If I was writing a game for an 8-bit CPU, I would use
| fixed point numbers (for example, 8.8 numbers which use 8
| bits for integral part and 8 bits for the fractional part,
| or maybe 10.6, or 12.4 numbers).
|
| 6502 cannot multiply or divide (division is a costly
| operation even on modern CPUs) so I would use adding or
| subtracting logarithms for this purpose. 12-bit precision
| logarithm table requires just 8 Kb RAM (and you can get
| 13-bit precision with interpolation).
|
| The disadvantage of this approach is that every time you
| convert a number from linear to logarithm or vice versa you
| get approximately up to 0.3% error (for 12-bit logarithm).
| So multiplying or dividing several numbers in a row is
| fine, but if you have to alternate multiplication with
| additions you will accumulate an error. So I would look for
| formulas that avoid this. But for a game a little error in
| calculations is not noticeable.
|
| Also one might think that the most time-consuming part for
| pseudo-3D game is math and calculations. I doubt that. The
| most of CPU cycles are usually spent in rasterisation and
| applying textures. Is is easy to calculate positions of 3
| vertices of a triangle, but it takes a lot of time to draw
| it line by line, pixel by pixel, and if you want to have
| textures this time can be multiplied 5x-10x.
| brianpaul wrote:
| IIRC, the Atari ROM routines used a different 6-byte BCD
| floating point format.
| legoxx wrote:
| I can assure you that no BCD routines (nor Woz's nor
| Atari's) were hurt during production of this game. They
| are really slow. You need to use all kind of tricks and
| cheats when creating 3d game on 8bit machine and all
| needed calculations are precalculated in lookup tables.
| ciroduran wrote:
| I love that the credits mention the raycast tutorial by Permadi
| https://permadi.com/1996/05/ray-casting-tutorial-table-of-co...
|
| I used this tutorial in the 2000's to write a raycaster myself in
| C using Allegro. It's wonderful that these tutorial are still
| useful so many years after they've been written.
| joshspankit wrote:
| If this had been released when the 800 was new, it would have
| _blown people's minds_.
| wombat-man wrote:
| Here's a video: https://www.youtube.com/watch?v=92K9wnk_4Cw
|
| Pretty interesting but it's a little hard to make out what's
| going on sometimes.
| laurent123456 wrote:
| If you reduce the window to a very small size (or look at your
| monitor from a few meters away) then it's actually easier to
| see what's going on.
| buescher wrote:
| I wonder how it would look on a CRT TV over RF.
| kingcharles wrote:
| Thank you. I can't help but feel the wall textures have screwed
| the whole thing. It might be that they've tried to just be
| _too_ clever with this and a less complex solution (flat
| shading, gouraud shading) would have worked better.
| wombat-man wrote:
| Yeah I had the same thought. I played a few FPS on my ti-83
| back in the day, it was black and white, and really it only
| drew the edges of the walls and outlines of people. But I
| could tell pretty well what was going on in comparison to
| this.
|
| This atari game might also look a lot better on a crt or
| something.
| VeninVidiaVicii wrote:
| It's difficult for me to tell if the player is looking at a
| wall or a hallway...
| memco wrote:
| It's a bit unclear what's demoing visuals vs. gameplay. It
| seemed often that when the player reaches a corner, instead of
| turning the corner and continuing down the corridor the player
| would sometimes turn into the corner and wiggle. I wonder is
| there something about corners that's a bit janky or is that
| just a habit of this particular user that they sometimes just
| turn left and right randomly particularly in corners?
___________________________________________________________________
(page generated 2021-11-03 23:00 UTC)