16K 3D engine

[xxl]

?

 

 

 

[+x=usr(1536)]

Okay...  What are we looking at here?

[vitoco]

Will we need 3D goggles?

[+x=usr(1536)]

[Justin Payne]

So, it looks like it's just duplicating the same image. If it required goggles, I'd expect some offset between the two images and they both look to be the same BUT that could be because the resolution is so low. I'm interested and would like to know more.

 

[emkay]

6 hours ago, xxl said:

?

 

 

 

Antic Mode 7 ? 

Nice. 

Next try fullscreen?

[snicklin]

I am guessing that it is a demonstration that you could, when this is further developed have a 2 player game operating at this speed.

 

It's got nice movement. At a guess that is because it's at 160 pixel resolution.

[xxl]

raycaster is for a narrow image (32 bytes) but the pixel width does not have to be in byte size - that's what the renderer is for. It can be 1 pixel (byte width), maybe 2 pixels (as in GR.9), maybe 4 pixels (GR.7) or maybe 8 (GR.8)... The height of such an image depends on the method you choose so that the image is not too distorted Filling walls with either color or texture - a wall has a width (after rendering) of 4 bytes - e.g. 4x4 = 16 color pixels.
I don't know if it makes sense to display two images generated with shift for right and left eye - because there will be no angle correction and besides, squinting to see the effect is interesting for 5 seconds  but for two players we have to use the windows in the upper left corner and in the lower right corner - then it might look nice

 

If someone has an interesting texture to check I can use it, but I wouldn't expect miracles... Best in format ( http://matosimi.websupport.sk/atari/atari-fontmaker/ ) because it will be easier for me to convert.

 

 

[Mclaneinc]

Someone's been disassembling Way Out! 

[xxl]

actually it looks similar on the video ? but Way Out or Capture The Flag are more advanced - they display the opponent but here we can texture walls

[xxl]

8 hours ago, emkay said:

Antic Mode 7 ? 

Nice. 

Next try fullscreen?

if you want a quick answer, write a PM and not wait for censors to confirm your answer.
The display mode depends on the rendering itself - you can add any mode you want but it seems to me that it's better to go towards 4 color lores. Full screen rather not - there are already full screen engines with 1 byte pixel size - and they seem to be better ... here we are limited to 32 bytes, but thanks to this you can do really hardcore optimizations in terms of the amount of data needed for calculations. It is very possible that this engine can be squeezed into such a form that it can be used in BASIC.

[globe]

6 hours ago, xxl said:

raycaster is for a narrow image (32 bytes) but the pixel width does not have to be in byte size - that's what the renderer is for. It can be 1 pixel (byte width), maybe 2 pixels (as in GR.9), maybe 4 pixels (GR.7) or maybe 8 (GR.8)...

Never really did any calculations but wouldn't bit operations needed for 4 pixels gr.7 or 8 pixels gr.8 cause a relatively big slowdown?

Or is there some clever trick around that?

[Heaven/TQA]

5 hours ago, xxl said:

actually it looks similar on the video ? but Way Out or Capture The Flag are more advanced - they display the opponent but here we can texture walls

Me thought it is capture the flag tech as I have posted some years ago Info by Paul himself. 1D scanline buffer and Ora filled.

 

hmmm nice one XXL

Edited February 6, 2022 by Heaven/TQA

[xxl]

3 hours ago, globe said:

Never really did any calculations but wouldn't bit operations needed for 4 pixels gr.7 or 8 pixels gr.8 cause a relatively big slowdown?

Or is there some clever trick around that?

There is nothing here that you don't know before. The speed is solely due to the amount of computation - there is simply less computation because the "view" is smaller. Everything can be optimized but unfortunately limitations often come out...

 

2 hours ago, Heaven/TQA said:

Me thought it is capture the flag tech as I have posted some years ago Info by Paul himself. 1D scanline buffer and Ora filled.

It has nothing in common with his engine.

 

The project had several turning points, it evolved after Emkay's words about using characters as free boxes on the raycast screen. At first I didn't see how this could benefit the speed... later during a conference with the AtariBDSM group (yes they have their 3D engine too - I saw it, brilliant) the idea of solving the problem of writing vertical stripes on the screen came up.... it seemed to me that only PMG gives such an effect - writing a 3D engine that projects data to PMG memory seems crazy ? Can you imagine having a 3D image at 32px resolution ? hardware horizontal stretching, double vertical resolution, unused PMG memory for textures ? you throw into memory managed by GTIA and that's it. Later the idea came up to put everything into character set memory and let ANTIC take care of it (similar thing happened in Nighshade) also you can arrange the data lying in memory next to each other to be displayed one below the other, but the problem was the height ? everything small and the limitations itself... all the time the idea is evolving and we will see where it leads

[Heaven/TQA]

35 minutes ago, xxl said:

There is nothing here that you don't know before. The speed is solely due to the amount of computation - there is simply less computation because the "view" is smaller. Everything can be optimized but unfortunately limitations often come out...

 

It has nothing in common with his engine.

 

The project had several turning points, it evolved after Emkay's words about using characters as free boxes on the raycast screen. At first I didn't see how this could benefit the speed... later during a conference with the AtariBDSM group (yes they have their 3D engine too - I saw it, brilliant) the idea of solving the problem of writing vertical stripes on the screen came up.... it seemed to me that only PMG gives such an effect - writing a 3D engine that projects data to PMG memory seems crazy ? Can you imagine having a 3D image at 32px resolution ? hardware horizontal stretching, double vertical resolution, unused PMG memory for textures ? you throw into memory managed by GTIA and that's it. Later the idea came up to put everything into character set memory and let ANTIC take care of it (similar thing happened in Nighshade) also you can arrange the data lying in memory next to each other to be displayed one below the other, but the problem was the height ? everything small and the limitations itself... all the time the idea is evolving and we will see where it leads

AtariBDSM group?

[Heaven/TQA]

And yes PMs GTIA is our „blitter“ similar to the Apple 2GS horizontal automatic filling between pixels 

[xxl]

1 hour ago, Heaven/TQA said:

AtariBDSM group?

yep,

 

Count Ulrich von Chain and Marquise Liebling Pejcz

 

https://www.pouet.net/groups.php?which=14074

[xxl]

On 2/6/2022 at 5:51 PM, globe said:

Or is there some clever trick around that?

maybe one trick... how close can you get to the wall? I ask because small enough allows you to skip collision checking at corners (collision procedure halved) 

[globe]

On 2/9/2022 at 1:25 AM, xxl said:

how close can you get to the wall? I ask because small enough allows you to skip collision checking at corners (collision procedure halved)

8 units (player moves over 32x32 grid squares), in Final Assault I didn't check corners at all so you could grind your face right against the wall if you came from the side without triggering the 8 units distance check.

In 128KB engine this is fixed.

[xxl]

one more small observation...

usually the implementation of the racasting algorithm calculates the height of the vertical stripe or the height of the empty space from the top of the screen from which it calculates the height of the padding but actually you don't need to calculate the height of the vertical strip for texturing, nor do you need to calculate from where to write it.
since we are doing the calculations for the texture anyway, it is enough to draw the texture from the center of the screen and control the overflow on the address when adding another byte of texture (break loop)

 

2 calculations less ?

 

Disadvantage: the texture cannot cross the page border.

 

Edited February 11, 2022 by xxl

[xxl]

 

textures: 1,2,3 as solid color, >4 normal textures, outlying textures are replaced by color

 

unfortunately writing 4 pixels to one byte is very slow ? (like in the video)
I think 2 pixels per byte is optimal for Atari (i.e. GTIA modes).

 

[Heaven/TQA]

On 2/11/2022 at 3:06 AM, xxl said:

one more small observation...

usually the implementation of the racasting algorithm calculates the height of the vertical stripe or the height of the empty space from the top of the screen from which it calculates the height of the padding but actually you don't need to calculate the height of the vertical strip for texturing, nor do you need to calculate from where to write it.
since we are doing the calculations for the texture anyway, it is enough to draw the texture from the center of the screen and control the overflow on the address when adding another byte of texture (break loop)

 

2 calculations less ?

 

Disadvantage: the texture cannot cross the page border.

 

Don't get that 100%... normally your texture collum is anyway "baked" into speedcode rendering the collum? (say 50% scaling is LDA texture STA screen LDA texture+512 STA screen+40 LDA texture+1024 STA Screen+80 ... assuming each texture line is on a page)? (ok. assuming here rendering direct to VRAM not into collum buffer for ORA 2nd collum 0x x0)

Edited February 16, 2022 by Heaven/TQA

[xxl]

2 hours ago, Heaven/TQA said:

speedcode rendering the collum

I can't imagine scaling a texture in speedcode - it would take up a lot of space. This whole engine takes up 2KB.

The texture takes 128 bytes and cannot exceed the page limit.
I don't write directly to the screen but to the buffer because I don't calculate the whole width at once but one ray at a time and then I calculate the texture scaling and write to the buffer, another ray and so on. 4 rays per byte and then copy the column to the screen.
I have another idea to skip the scaling calculations (it will be quite a speed up but I haven't done it yet, if I succeed it will be another video soon) - this will open the way to using at least 3 textures depending on the scale and the visibility range (currently I do not count it so the map must end with a wall

 

[xxl]

indexes for texture scaling - you don't have to calculate it while drawing ?

unfortunately this takes 4KB for arrays

resolution 64x

 

 

 

 

[Heaven/TQA]

XXL… can you share the source? I am curious.