Hacker News Reader

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!

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

* 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. :^)

I could tell something was off, but couldn't put my finger on it. Very cool

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...

IIRC, the Atari ROM routines used a different 6-byte BCD floating point format.

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.

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.

8kb table for logs would consider 16% of 64kb that you have for engine, game, intro and end sequence.

> for example, just to add two numbers you have to shift mantissas and 6502 has no fast way to do it

How much work is there to do beside shifting mantissa? (A shift is also necessary for many fixed point calculations).

- 80x30 resolution

- mostly 8 colors

Its impressive, but unplayable.

Reply on news.ycombinator.com