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

[+MrFish]

look forward to seeing what you can pull off. It's amazing what fighting against limitations can do to motivate our creative forces.

[VladR]

...Similar with the star-tunnel. In a filled polygon solution, you wouldn't see the "depth" that is shown by the lesser pixels and what the eye gets presented.

Bullshit. You have 4 colors available. In a tunnel, that fills whole screen, you don't have to waste one color for background. So, you got 4 colors for the tunnel.

Look at my StunRunner wireframe - it also has 4 sections. Just imagine each depth-section rendered in different color. This will totally give you a full immersion and experiencing of the full depth.

 

If you adjust their brightness in the palette, based on how close each section's front vertex is, you can even increase that illusion further, as we have -what- 16 luma available in palette ? Thus the distant segments will gradually move from darker to brighter (at almost free cost, as unlike DLIs, this is just adjusting one byte)

look forward to seeing what you can pull off. It's amazing what fighting against limitations can do to motivate our creative forces.

Thanks. There really is no other coding thing quite like it

[Heaven/TQA]

It's actually THE feature that C64 coders can do best. Show more than actually has been done. Similar with the star-tunnel. In a filled polygon solution, you wouldn't see the "depth" that is shown by the lesser pixels and what the eye gets presented.

 

it's not c64 coders... it's demo coders... we are masters in "smoke and mirror"

 

but again... you claim it is easy I told you it's not in 50 fps and with the restrictions I told you... and I said grab basic as you did in the 80s... nowadays we can run it in warp mode in Altirra or Atari800win to demonstrate your idea. maybe you have the "simple" trick which would be fine...

 

it takes a little bit more than "bla bla 4 different chars done in basic"...

[VladR]

As I said... its not that simple....

Of course it is - for emkay

[+MrFish]

as we have -what- 16 luma available in palette ?

 

8 lumas in non-GTIA modes.

 

 

Thanks. There really is no other coding thing quite like it

 

... or to put it another way, it forces us to clean up our sloppy coding.

 

Same with doing graphic design on these machines... you will be challenged to render simple objects, and find ways and methods you never thought possible.

[emkay]

Bullshit. You have 4 colors available. In a tunnel, that fills whole screen, you don't have to waste one color for background. So, you got 4 colors for the tunnel.

Look at my StunRunner wireframe - it also has 4 sections. Just imagine each depth-section rendered in different color. This will totally give you a full immersion and experiencing of the full depth.

Bullshit ?

I was writing about the C64 demo...

[emkay]

it's not c64 coders... it's demo coders... we are masters in "smoke and mirror"

 

but again... you claim it is easy I told you it's not in 50 fps and with the restrictions I told you... and I said grab basic as you did in the 80s... nowadays we can run it in warp mode in Altirra or Atari800win to demonstrate your idea. maybe you have the "simple" trick which would be fine...

 

it takes a little bit more than "bla bla 4 different chars done in basic"...

Yes, I know. Some stuff will never get into Atari coders.

[VladR]

 

8 lumas in non-GTIA modes..

Ah, damn. I was too far gone with experimenting with EclaireXL's 4x GTIA modes

But, even 8 lumas will multiply the effect accordingly - instead of just 4 colors, there will be 8 animated ones, which especially in motion, does wonders, as our eyes evolved phenomenally to do the motion interpolation.

 

Bullshit ?

I was writing about the C64 demo...

OK, so can you imagine what I'm talking about or not ?

[Heaven/TQA]

Yes, I know. Some stuff will never get into Atari coders.

Glad I am not Atari coder but Atari Lynx, c64, Vic20, Gameboy, pico-8, Amiga, Atari ST...

 

But honestly why not grabbing basic and do a prototype like you do in RMT and G2F? I even do protos in turbo basic and run it in full speed in Altirra.

[+MrFish]

Ah, damn. I was too far gone with experimenting with EclaireXL's 4x GTIA modes

 

Must have some fat memory requirements.

 

 

But, even 8 lumas will multiply the effect accordingly - instead of just 4 colors, there will be 8 animated ones, which especially in motion, does wonders, as our eyes evolved phenomenally to do the motion interpolation.

 

8 is plenty; In fact, some of those are close enough, in many cases, that cutting it down to 4 lumas is more useful.

Edited March 20, 2018 by MrFish

[emkay]

But honestly why not grabbing basic and do a prototype like you do in RMT and G2F?

 

Because I don't find it any useful?

[emkay]

OK, so can you imagine what I'm talking about or not ?

I know what you are writing about. To add some needed lumas, you can additionally use the PMg.

 

I actually wanted to do a quick edit in G2F. But that seems not possible. You'd have to draw pixel by pixel...

 

Hope, the quick edit shows what could be done. In theory moving the PM bars horizontally allows to give a depth movement impression...

 

Edited March 20, 2018 by emkay

[Heaven/TQA]

Because I don't find it any useful?

Nothing to add...

[VladR]

Must have some fat memory requirements.

Well, 320x192x16 takes exactly 30 KB, so two of those are 60 KB. But even stock 130XE still gives you additional 64 KB.

 

But, plenty driving games would do fine with partial dobulebuffering (where you use Antic's LMS) which means 48 KB for doublebuffering, and that still leaves a lot for game.

 

Especially with flatshading, there's no sprites consuming the memory. The base vertex mesh may consume a 1 KB at most, the rest is computed at run-time.

 

So, even 64 KB RAM is enough for driving games at 320x192x16.

 

8 is plenty; In fact, some of those are close enough, in many cases, that cutting it down to 4 lumas is more useful.

Not sure I understand what you mean. 8 is double of 4, so I reckon it should feel more colorful with 8 different lumas compared to 4, no ?

 

 

 

Also, it was bugging me that I posted incomplete StunRunner track mesh, so I debugged it (I had a typical the copy-paste bug, where I didn't replace all values, duh!) and here it is:

4 Segments, each is 10 triangles (5 quads) -> 40 triangles per scene

500 pixels in all lines

38,273 cycles for clearscreen, clipping, drawing, polygon loop overhead

 

(still need to refactor the 3D transform (as I recently reworked the whole worldspace and clip-space with just 8-bit precision) and fixed-point coefficient lookup into asm, which are still in C at this moment). But it should all fit comfortably under 72,000 cycles, which is 20 fps on NTSC.

 

Still, I am glad to see that the 8-bit coordinate system works both near camera and far away and for the clipping (it was a bitch to get all 3 cases merged together, I almost thought I'm only gonna get the 2, but 2 days ago had a heureka moment and now all 3 cases work).

[VladR]

I know what you are writing about. To add some needed lumas, you can additionally use the PMg.

 

I actually wanted to do a quick edit in G2F. But that seems not possible. You'd have to draw pixel by pixel...

 

Hope, the quick edit shows what could be done. In theory moving the PM bars horizontally allows to give a depth movement impression...

Sorry, I am not following. How exactly would you fill the polygon with PMG ? it has arbitrary shapes along the edge. Only flatshading can fill those.

 

Remember, when you play the game, during steering the camera will change those shapes every frame.

 

 

One easy hack is just to do the polygon fill on the main wide track polygons (across which you are driving). If we did DLIs, you could have a nice shaded depth-based effect.

But, each DLI costs how much CPU time ? Roughly ~125c per scanline ? If we do 20 such changes, we're down 2,500c, e.g. instead of 24,186c per frame, we would have just 21,686c. This could still work...

 

Or did you mean something else ?

[emkay]

Nothing to add...

Is that a provocation ?

 

I made it rather clear... several times.... that I don't want to do any racing behind C64 stuff.

Then you want me to do exactly that?

[emkay]

Sorry, I am not following. How exactly would you fill the polygon with PMG ? it has arbitrary shapes along the edge. Only flatshading can fill those.

That's where speed meets details. If you have a closer look at the C64 version, the lines never change the degree.

In that parts you can use the PM Bars to save CPU time and to add colors, while needed detail can be added with flat shaded polygons/squares... whatever.

Edited March 20, 2018 by emkay

[Heaven/TQA]

Nope. You claimed its easy and I asked for a proof. And as you always claim you did basic in the past I offered you a way to show and proof your concept that its a simple char animation. Nothing more. So you dont want to do it by yourself because you find it useless I simply stopped by saying ok. Nothing more to add.

[emkay]

Nope. You claimed its easy and I asked for a proof. And as you always claim you did basic in the past I offered you a way to show and proof your concept that its a simple char animation. Nothing more. So you dont want to do it by yourself because you find it useless I simply stopped by saying ok. Nothing more to add.

It IS easy. But that doesn't automatically include to be done in 5 minutes.

[VladR]

That's where speed meets details. If you have a closer look at the C64 version, the lines never change the degree.

In that parts you can use the PM Bars to save CPU time and to add colors, while needed detail can be added with flat shaded polygons/squares... whatever.

So, what exactly happens to those PM bars in your head ? How exactly do they behave there?

 

because it looks like only mean to add "movement" to those vertical polygons (those that extend upwards).

 

 

But the problem with your logic is:

- the cycles/time it takes to fill those few pixels is totally miniscule

- the PMG bars have only huge changes in pixel width, so when jumping from 5px to 6 px, it's quite a jump on screen - whereas with flatshading you have full per-pixel control

- you would have to manage changes from PMG Width - from 1, to 2, then to 4 and each would need a separate codepath

- you would need additional 3 LUT tables to transform the desired pixel width into the PMG Width

- PMGs takes cycles too

 

So, in the end, it would be a hack that would look far from the way full flatshading can, and highly likely it would be even slower. Because the quad-pixel on those tiny polygons would take less than 10%. it's the Edge processing/traversal/drawing that takes over 90% of time. Those 1-2 STAs per scanline would take totally negligible amount of cycles.

[emkay]

So, in the end, it would be a hack that would look far from the way full flatshading can, and highly likely it would be even slower. Because the quad-pixel on those tiny polygons would take less than 10%. it's the Edge processing/traversal/drawing that takes over 90% of time. Those 1-2 STAs per scanline would take totally negligible amount of cycles.

It's exactly hard to follow YOUR logics. You want to have colors but you don't want to use the colors the Atari has to offer.

Probably, you only save 10% using PMg there, but you gain 100% more colors.

The C64 version is tricking in all registers and is still useless. And, without tricking, even the Atari version won't really satisfy people.

[Heaven/TQA]

@Vladr

 

What about combining your 3d scene plus gates on top of the street like in master of the lamps? Think of only having top half....

 

[+MrFish]

Not sure I understand what you mean. 8 is double of 4, so I reckon it should feel more colorful with 8 different lumas compared to 4, no ?

 

I just mean the lumas are close enough that there are instances where you may like a little more contrast between them; so then, you can use 4 equally spaced lumas -- or even just 2 in some cases. It all depends on the effect you want to achieve. Just think about Pole Position, for instance, with it's white and red side makers. Your impression of speed comes from how fast these move towards you, but the high contrast between the lumas is what allows your eyes to pick it up more easily at higher speeds. Lower contrast between different lumas may be fine at slower speeds but may end up looking more like one color at higher speeds, or at the least will be a more subtle effect. I suppose something like you're doing, with wire frame, the division between sections (dark lines) help with the perception of motion. So, the contrast between different lumas used may not be as important as with something like Pole Position, where the difference in lumas provide the delineation.

Edited March 20, 2018 by MrFish

[VladR]

It's exactly hard to follow YOUR logics. You want to have colors but you don't want to use the colors the Atari has to offer.

Probably, you only save 10% using PMg there, but you gain 100% more colors.

The C64 version is tricking in all registers and is still useless. And, without tricking, even the Atari version won't really satisfy people.

- We can get more colors - via DLIs. Since we have 8 lumas, we really only need 8 DLIs. That's 8*125 = 1,000c less per frame. How many color changes are easy during DLI ? 3 or 4 ? I forgot now.

- I will gladly sacrifice 1,000c and go down to 24,186 - 1,000 = 23,186c (available per frame, even though at 20 fps, that's 3,000c lost on more colors) knowing we get the depth-based shading (e.g. fog)

 

- How about using PMGs for something else ? Say an enemy or a powerup/item ?

[VladR]

What about combining your 3d scene plus gates on top of the street like in master of the lamps? Think of only having top half....

Gates ? You mean the two diagonal pixel-cloud lines (of the 4 that move towards you) ? Can you explain more ?