The real powers of the Atari weren't Scrolling games with Sprites ;)

[Mr SQL]

On ‎6‎/‎23‎/‎2019 at 2:06 PM, emkay said:

 

Maybe  it is caused by the fact that non of those "great" 3D Engines found their way to a playable game?

 

 

Castle Wolfenstein's Doom engine did, and this wireframe virtual world is from 1982:

 

[emkay]

30 minutes ago, Mr SQL said:

Castle Wolfenstein's Doom engine did, and this wireframe virtual world is from 1982:

 

Nice, but...

Double Scanline mode ?  They say Antic D is a no go

 

And, those wireframe objects. Doing them filled, dropping the calculation on the not visible parts , and keep the movement in byte boundaries, would fit better for fps on those slow machines.  

 

[emkay]

Don't you think, it will be possible, to use the Atari's features for the imagination of a smooth 3D presentation?

 

In Basic mostly Mode 6 is used (also mode 7)

 

In Basic Games the feature of just rotating the character set has been standard.

 

In Basic has been standard to just rotate the  palette for animations

 

The modes start with 20x30 characters for a full screen presentation.

 

It is too slow to calculate any 3D related stuff in basic.

 

Now put things together :

 

Build such a "Raycaster" or else 3D calculating base engine.

Do a character set of 512 bytes .

For the left and the right side 3 different "arrow like, showing a slight angle downwards.

The size is depending on the "viewing distance" .  

You can use a filled char for the widest part of the wall(s).

 

For Walls that appear in the front, tiles could be build, that suppose to rotate, when needed. You know: a little bigger an a pixel for the "right" angle" if closer, and vice versa.  And always the edges.

 

8 special chars yet.

 

Put them to a more free to use level, give 16 chars.

3 Angles = 48 chars.

 

Then change the characters for 3 charsets , with an offset for the depth movement.

Shifted arrows for the walls, shifted size for walls in  the front.

 

Set 4 different brightness levels for the depth impression.

 

For obstacles just change a color register.

 

Is this really not to get working together ?

 

Just finding the correct time for registers to change, to aid the 3D presentation?

 

And after it all works, to add somewhere in the middle of the screen a horizon "DLI" that changes some colors, does the character flip , and the LMS mirrors the whole thing for the border presentation?

 

 

 

 

    

[Heaven/TQA]

Basicly what you suggest is prerendering all angles so an animation. Works in small windows but not with textured walls and higher as you might run out of chars quickly. And using bitmaps needs space too. Not impossible but that “Bards tale” approach is nothing new.

 

there were games using that even with angles. Can not remember those C64 games which had precalculated turn aninmations.

 

but that works by fixed player position. As soon as you want fractional move inside a “grid square” (map) you are fckud as maths is incorrect and it looks wrong from player point of view.

[emkay]

3 hours ago, Heaven/TQA said:

Basicly what you suggest is prerendering all angles so an animation. Works in small windows but not with textured walls and higher as you might run out of chars quickly. And using bitmaps needs space too. Not impossible but that “Bards tale” approach is nothing new.

 

there were games using that even with angles. Can not remember those C64 games which had precalculated turn aninmations.

 

but that works by fixed player position. As soon as you want fractional move inside a “grid square” (map) you are fckud as maths is incorrect and it looks wrong from player point of view.

 

Erm .... no?

You're misssing the imagination.

But. where to start?

When Rastaconverter appeared, most pictures don't look that well, but sometimes they fit like they were drawn for the Atari particular.

If a game is well, possibly someone else finds a way to optimize things ans to make it better.

 

But, particular those "3D" games were .... (put what you think in here ) ...

 

You only can build on things, if there were things to build on.

 

Look at those  Scrolling games with Sprites.  Paul Lay has everything "exhausted" , what the Atari offers for such games. There is nothing more to get there. Having a sneak peek on Flimbo's Quest, it possibly will end up in a playable game, luckily all enemies just move horizontal.  Thanks to Megabit Cartridges .

 

 

What I'm suggesting is a possible 3D engine that could run on some kilobytes of RAM. The used mode is also very low on CPU usage and allows a lot easy manipulations by the given hardware.  

 

"Finetuning" to some Megabytes of RAM    still possible.

 

 

 

 

 

 

 

 

[emkay]

I'd like to bring this special example in again:

 

 

Seeing the slower CPU AND the very slow Color-RAM is used, AND there is a mechanism running that makes the screen linear for 40x50 "pixel" that slows the CPU more down. The game is there and it runs "playable".

 

Seems the C64 had a huge fan , able to do 3D engines, and who wanted to have such a game on that machine.

 

So, if someone isn't expecting too much, the result might get always as fair as the machine is offering specifications .... 

 

 

 

[Heaven/TQA]

24 minutes ago, emkay said:

I'd like to bring this special example in again:

 

 

Seeing the slower CPU AND the very slow Color-RAM is used, AND there is a mechanism running that makes the screen linear for 40x50 "pixel" that slows the CPU more down. The game is there and it runs "playable".

 

Seems the C64 had a huge fan , able to do 3D engines, and who wanted to have such a game on that machine.

 

So, if someone isn't expecting too much, the result might get always as fair as the machine is offering specifications .... 

 

 

 

 

 

But that’s not char based but FLI 4x2? 

[emkay]

23 minutes ago, Heaven/TQA said:

 

 

But that’s not char based but FLI 4x2? 

On the C64 everything is char based. You should know that. The Color RAM- is the virtual addition to the displayed character.

The programmer did that "Hack" to enhance the character mode to 50 lines.  So he got the possibility of programming the graphics linear. No need for Bit calculations or Character position calculations . Just sorting and positioning of the characters needed. Or should we say "Color-RAM" ?

The Atari has no color RAM, so it's basically the same tech , to do that scrolling trick . You could use the "Graphics 0" mode , scroll it to 4 lines and build 50 lines, overlay it with gr. 10 GTIA Mode.

But that will always cost CPU time for 3D calculations.   

Interesting that the scrol trick on the Atari will free up cycles. Making such game much more fluent on the Atari.

 

Mode 6 would be the fastest mode, depending on directly available cycles, and it looks like the standard color mode. The biggest benefit is in the direct accessible manipulations for this mode.

 

 

Edited June 26, 2019 by emkay

[_The Doctor__]

I can't believe I'm saying this but some of that sounds reasonable. I'm not kidding... and with that I'm running away before people start tossing rotten veggies at me.

[R0ger]

I made Doom like game for Palm http://www.questions.cz/preview.html. Game like this is imho perfectly doable, as Project M shows. But I don't think it would be fun with joystick. Also the resolution is really low. The ratio of invested work and obtained fun just doesn't seem reasonable to me.

And it's really not about this mode or that mode. If someone want's to invest the time, he will find a way. Even if you just picked up where Project M finished.

[Heaven/TQA]

2 hours ago, emkay said:

On the C64 everything is char based. You should know that. The Color RAM- is the virtual addition to the displayed character.

The programmer did that "Hack" to enhance the character mode to 50 lines.  So he got the possibility of programming the graphics linear. No need for Bit calculations or Character position calculations . Just sorting and positioning of the characters needed. Or should we say "Color-RAM" ?

The Atari has no color RAM, so it's basically the same tech , to do that scrolling trick . You could use the "Graphics 0" mode , scroll it to 4 lines and build 50 lines, overlay it with gr. 10 GTIA Mode.

But that will always cost CPU time for 3D calculations.   

Interesting that the scrol trick on the Atari will free up cycles. Making such game much more fluent on the Atari.

 

Mode 6 would be the fastest mode, depending on directly available cycles, and it looks like the standard color mode. The biggest benefit is in the direct accessible manipulations for this mode.

 

 

Don‘t mix stuff up. The mood on C64 uses linear bitmap like mode with chars... of course I know it’s “chars” but you want to use 8x8 chunks or why are you always referring to “chars”?

 

thats why I asked.... what do you want... a raycaster or chars formed “dungeon crawler”

 

all example videos you showed where bitmap ones. Because working in char 8x8 boundaries plus resolution will not give you the freedom and mathematical accuracy. And in the end you will end up again in bitmap.

[Heaven/TQA]

All engines on a8 I am referring and have coded are based on nibble modes with 4:2 or 4:4 aspect that’s where a8 has most cpu available without penalty. Charmodes are worst to use on a8 imho with all those bad lines.

 

only Creme de la Creme coders like Jacky of Booze Design or Axis of Oxyron or Oswald of Resource can pull such things of on C64 in 160x res.

[Heaven/TQA]

...

Edited June 26, 2019 by Heaven/TQA

[emkay]

 

2 hours ago, Heaven/TQA said:

Don‘t mix stuff up. The mood on C64 uses linear bitmap like mode with chars... of course I know it’s “chars” but you want to use 8x8 chunks or why are you always referring to “chars”?

 

thats why I asked.... what do you want... a raycaster or chars formed “dungeon crawler”

 

all example videos you showed where bitmap ones. Because working in char 8x8 boundaries plus resolution will not give you the freedom and mathematical accuracy. And in the end you will end up again in bitmap.

 

I don't mix things up. I explain what mode to use, if someone wants to make more than just some demoscreen.

Character mode is the hardware, texturing the software (filling character content depending on the needed details).

 

 

 

[emkay]

2 hours ago, Heaven/TQA said:

All engines on a8 I am referring and have coded are based on nibble modes with 4:2 or 4:4 aspect that’s where a8 has most cpu available without penalty. Charmodes are worst to use on a8 imho with all those bad lines.

 

only Creme de la Creme coders like Jacky of Booze Design or Axis of Oxyron or Oswald of Resource can pull such things of on C64 in 160x res.

It's said: Every cook uses water for cooking ...

In every C64 demo with some 3D , you can see it easily where the tricks take part. Mostly the same chars used , while some content is changed on the fly (racing the beam) .  Thus the used screen is rather small . Your "nybble" Mode is good for direct 3D experiments, but for a game it is better to have more resources left. Game mechanics need some fx ...

And, not to forget, the fastest "3d" game engine is still Wayout!

[Heaven/TQA]

Yes and wayout/capture the flag are bitmap not charsets.

 

i personally don’t believe that you can pull off nice stuff with chars. I even say it gives you less resources for a game you would be surprised.

 

 

4:00 is suprise suprise... bitmap mode C64.

 

on csdb there is an interactive prg.

 

 

[emkay]

8 minutes ago, Heaven/TQA said:

 

 

4:00 is suprise suprise... bitmap mode C64.

 

 

 

 

What do you want to approve there? As I wrote , if they use 3d it is a tiny window on a tiny screen. And, as you see it is still rather slow. The faster routines re-use characters.

 

And, well, Wayout! uses Bitmap. But the picture is rather small. Full screen, you only will get using Mode D and a lot DL tricks. But if you want to have some more details, you have to use a character mode. The Calculations will get a little slower, but the re-usable content is a big speedup then.

 

 

Mode D  4800 Cycles

Mode 6  5400 Cycles

 

Mode 6 allows to re use characters, so you don't have to fill the whole screen with content.

Slower 3D calculations get more than compensated by that feature.

Don't forget: The CPU has to do the calculations AND the screen handling. Less screen handling means also more cycles left for 3D calculations.

Not to forget some scenario when you walk along a street  and immediately a barrier appears... this barrier is just a different color on the same content, just by changing the character value .... even here, no special bit calculations needed.

 

[Heaven/TQA]

If you believe in that go for it. Me put Atari charset weakness aside. A8 is a bitmap machine.

[emkay]

1 minute ago, Heaven/TQA said:

If you believe in that go for it. Me put Atari charset weakness aside. A8 is a bitmap machine.

A8 is both. Bitmap and Charset.

And, even more interesting: it can mix both. But most games miss that fact   ... combined modes plus PMg multiplexing seems to make every brain explode  ... if you see how coders avoid it ...

[Heaven/TQA]

Yes. I avoid it. As now with coding experience since 1986 on A8 I have to say most Jay Miner gfx modes of A8 are simple there because it was “hardware” design but with no real world usage. 

 

And if some wildest design dreams on combining that with that always fall apart when you write code... that’s a fact. Sad but true.

[Heaven/TQA]

game.xexattachted the Numen engine as interactive game. Tell me why would someone go for charset? I don't see it as you never would replicate a portal engine like that with chars. 

 

(space to open the door btw... ;))

[Heaven/TQA]

and my straight c64 port...

 

here please use qwasy and nm etc to look move around.

 

game_c64.prg

 

and now look again on the Booze Portal engine and you realise that it is higher res and does not face too much speed penalty like the C64 port of Numen portal engine. (which of course was based on A8 strength).

 

all those 3d stuff depends heavily on available CPU power and not on "gfx mode"... if you would code yourself you would see that even the c64 weird bitmap mode organisation or the ZX spectrum does not come into place when you work with engines which using unrolled loops and fixed screen adresses per pixel... in that case it does not matter.

 

and before you ask... Booze portal uses EOR filler... 

Edited June 26, 2019 by Heaven/TQA

[Heaven/TQA]

And for an unreleased potential Lynx demo...

 

 

now Lynx works in same mode like A8... but 4Mhz cpu vs 1,7 and maths is done on the FPU (ok more precise its not a floating point unit but an 16x16 hardware mul) of the Lynx and drawing on the blitter...

 

just to to give you idea that it’s CPU power in 3d... not mode.

 

Edited June 26, 2019 by Heaven/TQA

[emkay]

Just now, Heaven/TQA said:

And for an unreleased potential Lynx demo...

 

 

now Lynx works in same mode like A8... but 4Mhz cpu vs 1,7 and maths is done on the FPU of the Lynx and drawing on the blitter...

 

just to to give you idea that it’s CPU power in 3d... not mode.

 

I'm not saying you write nonsense, but in the context it is nonsense. If you can save CPU cycles for 3d calculations, it doesn't matter how you reach that.  To put the Lynx into the thread shows your shifted realization here. On the Atari 800  it is much more relevant how you manage the resources. Every cycle that isn't needed for screen handling, is available for the calculations.

[Heaven/TQA]

and if you judge on 3d engines... make yourself prior that familiar with what 3d in your terms is... Bard's tale with 90 deg turns, fixed view etc, raycaster which is 2d with a simple 3d view (Wayout, Capture the flag, Midi Maze), textured like Wolf engine in Arsantica 3, Doom engine which is "2.5 D" but using BSP tech (Portal engine) or Duke Nukem which does not use BSP but clipping against "Sectors" (means portals)....

 

so you first need to define what you want or what you are actually talking about.