Playing Sam's Journey, would an A8 version be possible

[Mclaneinc]

I got the impression (although from whom I couldn't even hope to remember, it was probably around a decade ago) that a lot of Polish games were written on black and white televisions so colour were chosen based on luminance alone...?

 

 

Ah, very interesting and revealing fact...

 

I looked at some of the Polish stuff at the time and wondered if a blind person had chose the colours, they seemed at odds with each other so this fact now explains a whole lot..

 

Please accept my apologies to the Polish devs, I didn't realise there was that sort of issue for some..

Edited March 18, 2018 by Mclaneinc

[Mclaneinc]

I believe it mostly comes down to history, circumstances and therefore how the Atari scene evolved.

 

My biggest regret is that the Atari barely left a trace in the UK marketplace. There was a natural evolution in games on dominant platforms in the country - mainly Commodore 64 and Sinclair Spectrum - thanks to real competition, high sales, dynamics... Apart from rare solo efforts by Paul Woakes, Archer Maclean, Zeppelin Games or Harlequin Software, the Atari was left aside and progress stalled. New standards were set on other machines while we lost something like five years for not being in the motion, which is A LOT.

 

The "Polish revival" was a godsend to Atari users and brought us a number of new games and missing genres. The main problem was what we got was essentially the normal step up from the games we knew... when development stopped on the Atari, not necessarily the other games you could find on the Commodore 64, Spectrum, Amstrad CPC, MSX...

 

Nobody's to blame. At the time, some software just seemed "good enough" or Atari coders didn't have the same standards compared to some of the biggies / non-budget games you'd usually have on the Commodore 64 for instance. After all, you can't expect an amateur climber to beat Mount Everest...

 

So yeah, our cursor got stuck on games from the mid-eighties for a long time...

 

This being said, I think the Atari has been slowly catching up these past years: a number of titles are really "big" games with depth, which is a good thing

 

--

Atari Frog

http://www.atarimania.com

 

Totally agree, for me the forerunners on the Atari in the UK were the bedroom lads who cut their teeth on the Atari but as it stalled they moved on to the now more industrious C64 where the dev was now much more company based and starting to form the monster it was to become. The suits were in their infancy but they had started.

 

As for the Eastern European revival, it was a brilliant thing, they rekindled the love of the Atari by producing games, the love had not faded elsewhere but there were very few new releases across the scene (if memory serves me) and the introduction of these Polish titles renewed the will to make stuff all over the place, people got the bug again and we must thank our Eastern European cousins for almost reinventing the Atari as a dev platform. Since then the production may not be as prolific as the C64 scene but they have been regular and amazing, I love the fact that people have looked at the C64 etc and said "I can do that on the Atari" and went on to do it, never let it be said that our Atari programmers don't run from a challenge.

[Mclaneinc]

I'm pretty sure, an experienced C64 coder could write a whole "PAC MAN" game in less than 2 hours in Assembler. The most time he had to set the pixel of the sprites, to have the game looking right. No additional interrupts needed, no special tricks...

On the Atari, the routine preparations for splitting the PMg will take longer to be created.

 

Look, I'm well aware of your love of wanting to be the most 'alternative' in the thread, your posting style follows a psychological pattern, be alternative, be radical, its clear to see but there's a world of difference between a simple much trodden PAC Man game and Sams Journey, yes you could knock together a simple PAC Man game in a very short time, especially if you ripped the mazes and character gfx and AI ahead of time but the complexity of Sams is incredibly high and what is worse is that you know it but are still trying to be the radical thinker.

 

I have no problem with people who think in different ways, hell my daughter confuses me at times but its left me to delve in to the workings of the brain and different can be good but different with a loss of logical functionality is not so good.

 

/Shrink mode off

 

Sams would take a really good Atari dev a good while to match the sprite engine alone, look at what the amazing Crownland non beta does with multiple sprites and char gfx, don't get me wrong, its a wonderful bit of work but Sams journey its not.

 

Could it be done, I'd love to think so but on a par with it, possibly not, perhaps some devs would like to prove me wrong and I'll apologise until the cows come home with utter pride..

 

Emkay, I like your threads and wording, your music is superb but sometimes I feel you just overstep the boundaries of logic just for effect.....But I like it, it makes the world go around...

Edited March 18, 2018 by Mclaneinc

[emkay]

Look, I'm well aware of your love of wanting to be the most 'alternative' in the thread, your posting style follows a psychological pattern, be alternative, be radical, its clear to see but there's a world of difference between a simple much trodden PAC Man game and Sams Journey, yes you could knock together a simple PAC Man game in a very short time, especially if you ripped the mazes and character gfx ahead of time but the complexity of Sams is incredibly high and what is worse is that you know it but are still trying to be the radical thinker.

You've almost got it.

 

The biggest problem is to have a "common" interface, where graphical data could be prepared for a game.

The C64 offers that by hardware, the Atari has to be prepared with "common usable" software routines.

While it is always the same on the C64 , well only the cycle stealing gets more by re using sprites, but that is really no problem, if you do games like Sam's Journey.

On the Atari the CPU cycle stealing can interfere any development, particular while "emulating" C64 features.

 

I could write "It's relatively easier to write such games on the C64 than on the Atari" . But that doesn't really "fill the gap".

If you're a coder , "coding every day 6502" code. You'd have to do coding 3D, complex software routines to prepare stuff.... whatever. And, if you want to play like with "Lego" you do a game with sprites on the C64.

Edited March 18, 2018 by emkay

[Bill Loguidice]

Half a meg of RAM is a pretty special requirement, considering it's a 3D game!

 

The tables you can store into something like half meg makes a pretty huge difference to performance and features, as that's something I'm currently very much involved with (as in - how much RAM I want to throw at the 6502 flatshading problem).

 

Yes, I know we have that on Atari (or more - 4 MB now), but given recent discussions about RAM extensions, it seems once shouldn't target more than 320, as that's what most people will have (including 576, 1MB, 4 MB).

 

Gimme 0.5MB on Atari, and we can skip Wolfenstein's raycasting and move towards flatshaded polygonal environment (sort-of a cross between Doom/Quake).

 

 

BTW, today I solved last big problem with the 8-bit coordinate system and fixed the related glitches (it was quite a lot of research!), so within a week or two I should have something nice running in 20+ fps. I'm thinking of reusing the dataset from my StunRunner on jaguar...

 

Well, it's all relative isn't it? 512K is "nothing special" on the CoCo 3. A fair number of commercial games back in the CoCo 3's heyday required 512K (versus the stock 128K), including games like the Sierra adventure games, Rogue, several of the Sundog titles like The Contras, etc. While it does give the CoCo 3 some advantages, it still wasn't particularly well-equipped as a game-centric machine and still has several deficiencies versus the Atari 8-bit or C-64. Anyway, the point is, even with that "advantage," you still get a mere shadow of a Wolfenstein 3D-like game. It's just not something an 8-bit computer (or console) is particularly well-equipped to handle because of processor limitations.

 

A big challenge with such a game of course is frame rate. If you want a true Wolfenstein 3D-like game, it really needs to move smoothly. Gate Crasher for all of its relative issues, at least moves smoothly. So, while something like Doom on the ZX Spectrum looks the part in many ways (and is a wonderful achievement), it's really difficult to say it plays the part. It's practically a slide show at times:

 

https://youtu.be/3v7cFGneuaw?t=1m50s

 

That's again why I don't count something like the recent Wolfenstein 3D port on the Commodore 64, which requires an external processor. As we know, running an FPS game the likes of which we're discussing is very processor intensive (requiring at a decent 386 on the PC side to be fairly smooth), so the fact that this requires a SuperCPU, which is basically a 16-bit processor, doesn't count as anything more than an interesting exercise (and, as always, I will state that I would never take away from the incredible efforts from anyone who programs such things; I'm speaking just on a practical level):

 

 

and Doom:

 

https://youtu.be/7ZzivzuDOls?t=3m27s

 

And this is cool, too, for the VIC-20 of all things, but again, something like its inspiration in many ways, but not performance:

 

 

It's kind of like fitting a round peg in a square hole. You can hack it, but it really doesn't fit. I love the efforts to do this stuff, but for all practical purposes, we're unlikely to have the type of FPS we're talking about (solid frame rate, decent number of enemies with AI, various objectives, decent level design, etc.) on an 8-bit processor, memory expansion or not.

[Bill Loguidice]

Additionally... you could do a full working 3D world without a single texture... just using lightning.

 

https://www.youtube.com/watch?v=obfXcjS5TYA

 

That's kind of the issue isn't it? How far can you abstract the concept before you don't really have what we're talking about? And with these types of demos you ALWAYS have to factor in what happens when enemies, AI, objectives, sound, etc., that make a game a game, will ultimately affect performance. Once the frame rate drops down to a certain level, it gets a lot harder to enjoy.

 

Anyway, I've said my piece. I'm still not convinced Sam's Journey is anything but a stellar achievement in any era, and I'm certainly not convinced that what most people really want instead of a nice platformer - or any game really well-suited to a particular 8-bit system - is a Wolfenstein 3D-like FPS game (or, as you say, "ego view," which I honestly don't think I ever heard before). Of course, people would love it if such a thing were accomplished, but probably not with what the end result would ultimately be. It certainly wouldn't be playable or enjoyable in the same way as a Sam's Journey.

[emkay]

That's kind of the issue isn't it? How far can you abstract the concept before you don't really have what we're talking about? And with these types of demos you ALWAYS have to factor in what happens when enemies, AI, objectives, sound, etc., that make a game a game, will ultimately affect performance. Once the frame rate drops down to a certain level, it gets a lot harder to enjoy.

NRV decided to use that 256 color interleaved mode. Without that horde of interrupts, the whole thing will run even faster.

If you have a look at the 1st of the Project-M demos, you see there are already moving objects included.

 

And, well, as I also wrote at the beginning of the thread, it means nothing. The evidence is in a final production, which is still not there. But there are enough empirical evidences that it is possible to have a fluent playable Wolf 3D on the Atari. Fluent in that case is more than 12 fps ....

[Bill Loguidice]

And, well, as I also wrote at the beginning of the thread, it means nothing. The evidence is in a final production, which is still not there. But there are enough empirical evidences that it is possible to have a fluent playable Wolf 3D on the Atari. Fluent in that case is more than 12 fps ....

 

Until we have at least a feature-complete level, it's all speculation. I also don't know if 13 FPS or greater is a good target for such a game. We might need quite a bit more for decent fluidity.

[emkay]

Until we have at least a feature-complete level, it's all speculation. I also don't know if 13 FPS or greater is a good target for such a game. We might need quite a bit more for decent fluidity.

Using the ANTIC for specific screen operations allows unbelievable stuff.

 

Wayout! , as a very early game using such Labyrinth levels in a 3D correct displayed way, is really fluent and has enemies, without visual fps drops.

 

 

You could enhance that to the full screen, without using more CPU cycles. Not to forget, the Atari HAS a "Sprite engine" , so not all has to be calculated, if an enemy appears.

Looking at the C64 version with that super CPU, seems there is the problem with VIC and the slow color RAM. Writes to any register in the Atari act without delay.

[Goochman]

I really enjoyed Wayout and wanted to complete every level, bu ton some levels that damn mirror that took away your map was too aggressive and eventually I just gave up.

[Bill Loguidice]

Wayout is again, one of several examples of such games (and had mediocre Apple II and C-64 versions, although it was still impressive enough upon time of release), but it's still a big leap to adding elements that a Wolfenstein 3D-like game would need to qualify as such. The fact that no one has done something like that as of yet probably tells us all we need to know about that, that it's simply not an easy, or necessarily even practical, undertaking. The proof comes if/when someone finally does it, even if it's a one level demo. Again, even with 512K to work with, Gate Crasher on the CoCo 3 is probably the closest we have on an unmodified 8-bit thus far, and it's still borderline in terms of feature-set. Outside of greatly simplified real-time mazes or turn-based games, it's just not an ideal target for platforms based around 8-bit processors.

[emkay]

Wayout is again, one of several examples of such games (and had mediocre Apple II and C-64 versions, although it was still impressive enough upon time of release), but it's still a big leap to adding elements that a Wolfenstein 3D-like game would need to qualify as such.

You know, there is a 2nd game of that by Paul Allen Edelstein, named Capture the Flag. It runs 2 of those screens, one for each player , side a side, at the same frame and framerate.

There is no C64 version available, yet a VIC20 port. But the VIC20 port pumps all reserves and plays the screens interleaved, to have an imagination of a higher speed.

While still much reserves were free on the Atari...

 

 

The fact that no one has done something like that as of yet probably tells us all we need to know about that, that it's simply not an easy, or necessarily even practical, undertaking. The proof comes if/when someone finally does it, even if it's a one level demo. Again, even with 512K to work with, Gate Crasher on the CoCo 3 is probably the closest we have on an unmodified 8-bit thus far, and it's still borderline in terms of feature-set. Outside of greatly simplified real-time mazes or turn-based games, it's just not an ideal target for platforms based around 8-bit processors.

GateCrasher is a real bad example. Not sure, where it fits to our discussion.

If everything fails, you could use GTIA mode 9 on the Atari, do some 3D calculations and spread the projection to the whole screen, allowing the available palette to project the impression of 3D, no need for bit calculations, just bytewise projection at 50 or 60 fps.

After the game runs, including enemies, just add details to the walls, till things turn down to 20fps.

Edited March 18, 2018 by emkay

[Heaven/TQA]

Gate crasher is really bad in terms of raycaster and really dont know why it needs 512k (ok samples and gfx). But those fisheye distorted levels?

 

I personally still vote for eidolon like game as FP RPG.

 

 

As having the source I can tell you that on a 64k machine there is not much room for game.

 

More interesting is the Duke engine of Fox used in Numen. That leaves more room for a game and fox implemented already shooting.

 

That needs around 32-40k as I already ported that to different platforms.

[VladR]

 

Well, it's all relative isn't it? 512K is "nothing special" on the CoCo 3. A fair number of commercial games back in the CoCo 3's heyday required 512K (versus the stock 128K), including games like the Sierra adventure games, Rogue, several of the Sundog titles like The Contras, etc. While it does give the CoCo 3 some advantages, it still wasn't particularly well-equipped as a game-centric machine and still has several deficiencies versus the Atari 8-bit or C-64. Anyway, the point is, even with that "advantage," you still get a mere shadow of a Wolfenstein 3D-like game. It's just not something an 8-bit computer (or console) is particularly well-equipped to handle because of processor limitations.

I had no idea 512K was available to them at that time. Jut presumed it was a fan-based HW expansion, as anything on Atari, so that's really interesting!

 

 

That's again why I don't count something like the recent Wolfenstein 3D port on the Commodore 64, which requires an external processor. As we know, running an FPS game the likes of which we're discussing is very processor intensive (requiring at a decent 386 on the PC side to be fairly smooth), so the fact that this requires a SuperCPU, which is basically a 16-bit processor, doesn't count as anything more than an interesting exercise (and, as always, I will state that I would never take away from the incredible efforts from anyone who programs such things; I'm speaking just on a practical level):.

 

A big challenge with such a game of course is frame rate. If you want a true Wolfenstein 3D-like game, it really needs to move smoothly

Interesting. Had no idea they had 20 MHz 65c816 around 1994 available. I'm sure, though, that the framerate could be improved, but at a great engineering effort expensed.

Besides, Wolfenstein on 386 was far from smooth - I played it actively at the time of release across a huge range of computers.

 

 

It's kind of like fitting a round peg in a square hole. You can hack it, but it really doesn't fit. I love the efforts to do this stuff, but for all practical purposes, we're unlikely to have the type of FPS we're talking about (solid frame rate, decent number of enemies with AI, various objectives, decent level design, etc.) on an 8-bit processor, memory expansion or not.

I've spent a great deal of effort in last 6 months working with 6502 Assembler, benchmarking my 3D routines, and optimizing them, so I have a really good idea what Atari can do and cannot do - as far as 3D goes. I wouldn't state that raycasting/texturing is such area, as frankly - even jaguar, who is ~infinitely faster compared to 6502, has issues with texturing.

 

But, there's a long list of famous 3D games from 16/32-bit paltforms that can indeed run very well (and still look recognizable) on stock 1.79 MHz Atari (e.g. 12+ fps), mainly vector/flatshaded, as our Atari is very good at scanline filling of flatshaded polygons:

- Tempest (yes, with dynamic perspective, like on Jaguar)

- Rez

- StunRunner

- Star Fox

- Star Wars (the arcade one)

 

The list above is something I actually spent some coding effort on - created a base prototype, counted the cycles and extrapolated the benchmarked data (by multiplying it by estimated scene polycount).

My performance target is 121,000 cycles for whole rendered frame, which corresponds to 12 fps on NTSC, as Atari has 24,186 cycles per frame available in 160x96x4.

[emkay]

Interesting. Had no idea they had 20 MHz 65c816 around 1994 available. I'm sure, though, that the framerate could be improved, but at a great engineering effort expensed.

Besides, Wolfenstein on 386 was far from smooth - I played it actively at the time of release across a huge range of computers.

In 1992 the 486/33MHz was a common CPU. There Wolfenstein ran smooth as silk. The typically "ET4000" standard was equal for playing fast action games. Thing struggled by the ISA Bus, causing animations running bad on "hi level" PCs. Remembering to clock the ISA-Bus to the limits for a fluent Wing Commander 2 experience. The changing to a VESA-LOCAL Bus Mainboard plus referring VGA Card , of course ET4000 compatible , made the jump of feeling to have a computer that was better than the Amiga (using ECS chip ) .

Using a "super CPU" on the C64 to show how it could have been on the C64, is even more ridiculous, if you just have a look at the doors and the slooooowww... graphics. The VIC 2 has shown it's limits in 3D games on the real thing at 1MHz already.

[VladR]

Wow, 486 ! Dude, you on drugs or what ? Of course it runs smooth on 486, as that's like playing the game from PS1 on PS3 and being surprised it "can" run at 720p.

 

 

When Wolf hit the streets, almost everybody around had 286, and very few had 386 DX 40, forget 486. The performance discrepancy between 286@12 MHz and 486@66 MHz is huuuuuge.

 

I played it a lot on 286, so that's why I say that the sub-12 fps is "normal", as that's what was around at that time.

 

You keep forgetting you're from Germany (though don't know if communist or capitalist one). That's hardly a statistical model for rest of Europe at those (and, frankly, even current) times...

[emkay]

Wow, 486 ! Dude, you on drugs or what ? Of course it runs smooth on 486, as that's like playing the game from PS1 on PS3 and being surprised it "can" run at 720p.

It's not me on drugs

It's just ridiculous to show any "superCPU" stuff on the C64. Neither the timeline nor the development grade does equalize anything

Any "super CPU" on the Atari takes advantage with all chips. 128 colors were fully available after a 20MHz CPU was used. Games would look sound and play like a 386 PC , if you understand...

[emkay]

Actually, back in the 80s we had discussions, why people liked C64 games that much.

SID music was one part. But, why? Well, it was , somehow, clean music, and it was something new. While all other sound devices sounded scratchy, SID sounded dull, but musically correct.

But, people had been a lot into the graphics... particular the colors. In that days, Drugs had been on the agenda in related ranges. People stated that the color usage chosen for the VICII reminded to LSD experiences.

 

What that means exactly... who knows ...

Edited March 18, 2018 by emkay

[VladR]

It's not me on drugs

It's just ridiculous to show any "superCPU" stuff on the C64. Neither the timeline nor the development grade does equalize anything

Any "super CPU" on the Atari takes advantage with all chips. 128 colors were fully available after a 20MHz CPU was used. Games would look sound and play like a 386 PC , if you understand...

Disregarding the architectural differences between 6502 and 80386 (which - btw - has an amazing instruction set compared to 6502, from my experience with coding 3D gfx at that time in ASM), you keep forgetting that while in DOS's Mode 13h (320x200x256) you can freely place any of 256 colors without any performance impact, on the 22 MHz Atari you have to race the beam and do STA Wsync on each scanline, which kills basically almost all of your 20 MHz, right there - and that's just to have those colors available, to say nothing of drawing with them.

 

The Eclaire XL, once it's available, with its 4x Antic modes, will be the closest thing (performance-wise) as you'll have 16 colors per scanline without Wsync, so with only 4 scanlines worth of WSync, you can have 64 colors on screen for 3D graphics. With 8 DLIs (which burn acceptable number of cycles), you'll have 128. Still not the same as on PC, but at least pretty close and useable.

 

Actually, back in the 80s we had discussions, why people liked C64 games that much.

SID music was one part. But, why? Well, it was , somehow, clean music, and it was something new. While all other sound devices sounded scratchy, SID sounded dull, but musically correct.

But, people had been a lot into the graphics... particular the colors. In that days, Drugs had been on the agenda in related ranges. People stated that the color usage chosen for the VICII reminded to LSD experiences.

 

What that means exactly... who knows ...

We would have to ask somebody experienced with LSD - any takers ?

[emkay]

Disregarding the architectural differences between 6502 and 80386 (which - btw - has an amazing instruction set compared to 6502, from my experience with coding 3D gfx at that time in ASM), you keep forgetting that while in DOS's Mode 13h (320x200x256) you can freely place any of 256 colors without any performance impact,...

That is not really true, as I wrote above. The ISA Bus was rather slow. Sharing every expansion. The communication between the devices was even worse. Changing graphics by the CPU could slow down things tremendously.

 

The Eclaire XL, once it's available, with its 4x Antic modes, will be the closest thing (performance-wise) as you'll have 16 colors per scanline without Wsync, so with only 4 scanlines worth of WSync, you can have 64 colors on screen for 3D graphics. With 8 DLIs (which burn acceptable number of cycles), you'll have 128. Still not the same as on PC, but at least pretty close and useable.

As soon as a more powerful CPU takes part, it is more useful to race the beam than to take care of the cycle stealing by ANTIC.

We would have to ask somebody experienced with LSD - any takers ?

hehe...

Edited March 18, 2018 by emkay

[VladR]

As soon as a more powerful CPU takes part, it is more useful to race the beam than to take care of the cycle stealing by ANTIC.

Wait, do you even understand how racing the beam works ? If you change colors via DLI on each of the 192 visible scanlines, you are going to burn 192/240 = 80% of those 20 MHz just on changing the colors.

 

You would then have an equivalent of roughly ~20% - e.g. ~4 MHz available during the vblank period. While certainly enough for most 2D games, it's nothing for 3D games.

 

Of course, a theoretical argument could be made, that changing the colors takes only small portion of each scanline's CPU time, as you wouldn't have only ~125 cycles available, but rather ~12x more, e.g. ~1,500 cycles, so you could, indeed, process a game or engine logic after you do the color register adjustment.

 

Can you at least imagine the coding effort of spreading the engine logic across 192 scanlines ? I would seriously argue that such a coding individual should quickly hurry and check himself in into the nearest mental asylum

 

That is not really true, as I wrote above. The ISA Bus was rather slow. Sharing every expansion. The communication between the devices was even worse. Changing graphics by the CPU could slow down things tremendously.

Did you ever code anything on 80286-80386 in Assembler ? Because back in the day, I did. Our high school school received English books for TurboPascal and among them was one for Assembler. So, after 6 rounds of refactoring, I made some very quick routines for 3D transform, line drawing and an quick prototype of a wolf-like 3D engine with textured walls. Which actually ran at higher framerate than wolf did (though there was no AI or audio at that time - but the point is that bus was capable of higher speeds).

 

I experimented with all the graphics modes available on EGA and VGA, not just default 13h, but also the 4-bitplane mode X (360x200/480 or similar, do not recall exact res after over quarter century). So, I have a pretty good idea about the ISA's performance. Trust me, 80286 was capable of higher framerates than wolf showed. The framerate on 80286 was more CPU-limited, than bandwidth-limited.

[+MrFish]

Well aware of it of course and I acknowledged that there are several first person games on all kinds of 8-bits. That's still not like what was being discussed, i.e., something like Wolfenstein 3D or Doom. The closest thing I can think of on an 8-bit is Gate Crasher for the CoCo 3 (512K RAM required, but nothing else special):

 

Emkay did mention Wolfenstein before posting the video of Project-M, and Project-M itself, of course, has the Wolf title screen, and graphics, etc. But your statement sounded like you were talking about FPS shooters altogether, which is why I responded with Midi Maze and the other info about Project-M.

 

I guess the point to be made here regarding 3D, is that given what's been achieved already back in the 80's on the Atari platform, and in light of recent achievements, there are still a lot of possibilities to be explored. And FPS or FP games of various types are on the menu and, in my estimation, can prove to be playable, fun, and worth the effort -- no matter what failures or half-efforts have been produced on other systems -- including 16-bits, if you want to throw them in.

Edited March 19, 2018 by MrFish

[kiwilove]

Platformers as such can be considered as one likely area to work on - for anyone who thinks they can address the shortcoming present

within this genre - like the shortage of independent sprites.

I would not suggest doing a conversion of Sam's Journey - specifically - unless the programmer is big fan of this game?

But rather to create something new with the A8 hardware in mind - to work around in... and engaging in their own creativity?

 

I would be happy if it can capture something from the likes of - Miner 2049'er, Bristles, that only come to my mind.here.

I was not really a fan of Mr Robot, Jumpman, Mr Robot, Cohen's various games and others - which simply missed the mark to me.

 

3D games (of any kind) are of another complexity altogether. Most people would think there'll be no real surprises to turn up - it'll always be a long shot - but it's still possible?

 

Harvey

[Gunstar]

Gate crasher is really bad in terms of raycaster and really dont know why it needs 512k (ok samples and gfx). But those fisheye distorted levels?

 

I personally still vote for eidolon like game as FP RPG.

 

 

As having the source I can tell you that on a 64k machine there is not much room for game.

 

More interesting is the Duke engine of Fox used in Numen. That leaves more room for a game and fox implemented already shooting.

 

That needs around 32-40k as I already ported that to different platforms.

I totally agree. While it would nice to see a "corridor crawler" FP game on the Atari, I am kind of tired of them. I too, would rather see more along the lines of The Eidolon, which has already been proven the Atari is fantastic at fractal type 3D environments. Or even something more "open world" like Koronis Rift, or a combination of interior and exterior levels of both these games.

[Lord Thag]

Occasionally, you'll get some brilliant programmer willing to spend the time to port some game to a console that really isn't designed to run it. And it's awesome, when that happens. But for every one game like that, there are fifty never to be completed ones.

Honestly, I'd much rather the time be spent working on something that caters to the system's strengths. The Atari was never meant to do games like Sam's Journey, and honestly, I don't much care. It WAS meant to do arcade style games, and it does strategy/RPG games quite well too, and we lost out on the best of those due to support dropping off after '86. I'd much rather someone ported a game we never got that is more easily within the Atari's design limitations. Ultima V, say, or several of those missing SSI Rpg games. Bard's Tale. Wizardry. Or maybe some arcade titles we never got, much the way we have been getting all of those awesome ZX Spectrum ports the last few years. Donkey Kong 3, Reactor, Zookeeper etc.