Raycaster

[GDMike]

Oooh.. could makeTIcraft with this sorta thing, TIcraft wouldn't need speed, just objects.

Edited August 14, 2020 by GDMike

[Asmusr]

17 minutes ago, GDMike said:

Oooh.. could makeTIcraft with this sorta thing, TIcraft wouldn't need speed, just objects.

If you mean like like Minecraft then no - that would require a real 3D engine that supports horizontal surfaces, for instance. 

[+FarmerPotato]

1 hour ago, Asmusr said:

If you mean like like Minecraft then no - that would require a real 3D engine that supports horizontal surfaces, for instance. 

A version that takes place on a single layer of blocks would be an appropriate subset. Like Flatland-you can't see or go outside your plane.

 

There would still be a lot of hidden things, and features that are not 3D like crafting.

I was thinking of that in 10-liner 49er (aka 99craft) in the contest this year. Only up-and-down and side-to-side like the original Miner from 99er magazine. Or Lost Ruins.

 

 

 

[Asmusr]

6 hours ago, artrag said:

Please unpack textures! even if you double the space encoding them twice, once in the lower and in the upper nibble  it will be worth!

Yes I will try. But it actually requires 4 times the space since I need each pixel in both upper and lower nibble for the max efficiency. Since each texture is 16x64 pixels it will take 2K per texture, so I have to move to a larger bank switched cartridge where I can store 4 textures in each 8K bank.

 

The other part of the inner texture loop is calculating the source texture address. I use three 16-bit registers for that:

- One for the base address of the texture column.

- One for the offset into the column, represented as an 8.8 fixed point number.

- One for the increment to the offset for each screen pixel, also FP 8.8.

For each pixel written I add the increment to the offset and the high byte of the offset, which is the number of whole pixels, to the column base address. 

Actually I think that could be done slightly faster as well if I could assume that no texture column crosses a 256 byte boundary.

  

 

 

 

[Asmusr]

48 minutes ago, FarmerPotato said:

A version that takes place on a single layer of blocks would be an appropriate subset. Like Flatland-you can't see or go outside your plane.

 

There would still be a lot of hidden things, and features that are not 3D like crafting.

I was thinking of that in 10-liner 49er (aka 99craft) in the contest this year. Only up-and-down and side-to-side like the original Miner from 99er magazine. Or Lost Ruins.

I would be happy to discuss how to implement Minecraft for the TI in another thread. ?

Edited August 14, 2020 by Asmusr

[Asmusr]

Here is the latest cartridge file for the textured raycaster if you want to try it. My TI has been packed away since the beginning of Corona, so I haven't actually tried this or the fast raycaster on real hardware.

texcaster8.bin

[dgrissom]

2 minutes ago, Asmusr said:

Here is the latest cartridge file for the textured raycaster if you want to try it. My TI has been packed away since the beginning of Corona, so I haven't actually tried this or the fast raycaster on real hardware.

texcaster8.bin 32 kB · 1 download

I tried the .dsk version this morning on my TI  (with TIPI/32K).  It worked extremely well.  I tested it with my Joystick.  It may not have the textures.  It's the best TI (almost) game, I've played in a long time!  Loved the surprise!

 

I will try the texcaster8.bin later today.

[jrhodes]

5 hours ago, Asmusr said:

Here is the latest cartridge file for the textured raycaster if you want to try it. My TI has been packed away since the beginning of Corona, so I haven't actually tried this or the fast raycaster on real hardware.

texcaster8.bin 32 kB · 6 downloads

Pressing M opens a map in the latest non-textured .bin, but in this one it just garbles the screen.

[dgrissom]

20 hours ago, dgrissom said:

I tried the .dsk version this morning on my TI  (with TIPI/32K).  It worked extremely well.  I tested it with my Joystick.  It may not have the textures.  It's the best TI (almost) game, I've played in a long time!  Loved the surprise!

 

I will try the texcaster8.bin later today.

I tried it on my console.  The added textures made it very sluggish.  As jrhoades indicated the map is garbled.

 

BTW.  What's your or anyone else's highest score on the non-textured version? ?   My last game was 825...

[Asmusr]

15 hours ago, jrhodes said:

Pressing M opens a map in the latest non-textured .bin, but in this one it just garbles the screen.

I have fixed the map issue in this version. It also has more optimizations: unpacked textures and some code moved to scratch pad. I'm not sure the difference is that noticeable, however.

 

 

texcaster8.bin texcaster.rpk

[Asmusr]

In this version I'm not doing all the hard work of updating the screen if you're not moving. That makes it possible to open the doors by shooting them almost like before.

 

 

texcaster.rpk texcaster8.bin

[Asmusr]

This is close to my vision for the textured raycaster, but I don't think it's likely to happen.

 

 

[Tursi]

2 hours ago, Asmusr said:

This is close to my vision for the textured raycaster, but I don't think it's likely to happen.

 

 

Well, what if you reduce the 3D window to 1/4 screen like it is there?

 

(edit) Actually, if you look at it, there's a pretty steep limit on the depth as well... if you went black earlier, you could speed distant rays.

 

 

Edited August 15, 2020 by Tursi

[MueThor]

Dear Asmusr,

 

What is pictured on the shield, which can be seen from time to time in your game? To me it looks like a bloody chicken shot dead. Addendum: Okay, later on I saw that a dragon is pictured on the shield. How is about a black, white and red symbol resembling rather very faintly a N... German Swastika instead?

 

 

Regards

 

 

 

Edited August 16, 2020 by MueThor

[Kiwi]

I think trimming the top and bottom 1/6, and then the top 2/3 of the screen would be the 3D part, the 1/3 can be the stats and text.  That way you keep the full 64 wide pixels resolution. I think it'll run a bit quicker since it's drawing less. 

I can't believe this is working on a TMS9918a chip. Really nice job.

Edited August 16, 2020 by Kiwi

[artrag]

12 hours ago, Kiwi said:

I think trimming the top and bottom 1/6, and then the top 2/3 of the screen would be the 3D part, the 1/3 can be the stats and text.  That way you keep the full 64 wide pixels resolution. I think it'll run a bit quicker since it's drawing less. 

I can't believe this is working on a TMS9918a chip. Really nice job.

Naturally reducing the view port can speed up the rendering but before that, another option could be unrolling the column rendering creating a different routine for each height of the rendered column.

You can generate them with an offline script before assembling and include them in a large "case of" 

In this way you can also embed in the code the offsets in the column of the texture corresponding to scale and height within the viewport.

At cost of a few KB of automatically generated code you would skip this part

 

Quote

- One for the offset into the column, represented as an 8.8 fixed point number.

- One for the increment to the offset for each screen pixel, also FP 8.8.

 

Edited August 16, 2020 by artrag

[fabrice montupet]

Always great work Rasmus!

I used the page https://raphael.js99er.net/ to make some graphic tests but I haven't found the way to put the textures on the game code.  So I have no idea if what I drew is interesting or not. Here is the texture of the door. If you have some time, can you take a look on it?

door-texture.rap

[Asmusr]

1 hour ago, fabrice montupet said:

Always great work Rasmus!

I used the page https://raphael.js99er.net/ to make some graphic tests but I haven't found the way to put the textures on the game code.  So I have no idea if what I drew is interesting or not. Here is the texture of the door. If you have some time, can you take a look on it?

Thanks, that's definitely better than mine. Here's a version using your door.

What I'm looking for now is dungeon textures and maybe a few monsters, so I can make a demo in a dungeon setting. 

texcaster8.bin

[Asmusr]

7 hours ago, Kiwi said:

I think trimming the top and bottom 1/6, and then the top 2/3 of the screen would be the 3D part, the 1/3 can be the stats and text.  That way you keep the full 64 wide pixels resolution. I think it'll run a bit quicker since it's drawing less. 

I can't believe this is working on a TMS9918a chip. Really nice job.

I agree it's probably best not to lose any horizontal resolution, although that would have the biggest effect on performance since fewer rays would have to be cast.

[Asmusr]

12 hours ago, MueThor said:

How is about a black, white and red symbol resembling rather very faintly a N... German Swastika instead?

I'm not going to make a WW2 related game, so no.

[fabrice montupet]

Thank you!  OK, I'll see for dungeon textures ?

I have made wooden door too if you're interested :

 

woodendoor-texture2.rap

Edited August 16, 2020 by fabrice montupet
Texture corrected

[fabrice montupet]

Maybe adding some vegetation here and there on the stone walls could be interesting. Mixing it with the normal wall could break the linearity of the wall.

brick-vegetation-texture.rap

[Asmusr]

17 hours ago, Tursi said:

Well, what if you reduce the 3D window to 1/4 screen like it is there?

 

(edit) Actually, if you look at it, there's a pretty steep limit on the depth as well... if you went black earlier, you could speed distant rays.

Yes I'm going to reduce the size, but C64 has a full screen resolution of 160x200 in multicolor mode, while we have only 64x192, so it's best not to reduce the horizontal resolution any further. 

 

Moving into a dungeon is going to reduce the distance the rays have to travel in most cases. But unlike the demo everything will be textured - also floor and ceiling. Unfortunately the 9918A has few dark colors, so it might end up looking like a very shiny dungeon.

 

I'm not sure that EOB was using a ray caster. Maybe there is a faster algorithm for the case with only 4 directions where you always move a whole square?

 

[artrag]

I think that all the walls/surfaces in EOB are pre-rendered and "composed" on the screen. A given wall can have only 3 distances and 3 orientations in the field of view.

You can scan the 3x3 cells from the farther to the closer line while plotting on the screen the pre-rendered pieces

Edited August 17, 2020 by artrag

[Asmusr]

On 8/16/2020 at 11:25 AM, artrag said:

Naturally reducing the view port can speed up the rendering but before that, another option could be unrolling the column rendering creating a different routine for each height of the rendered column.

You can generate them with an offline script before assembling and include them in a large "case of" 

In this way you can also embed in the code the offsets in the column of the texture corresponding to scale and height within the viewport.

At cost of a few KB of automatically generated code you would skip this part

It took me a while to understand what you're suggesting, and it sounds like an excellent idea, but I think it would take more than a few KB: A half height column is 96 pixels, and the lower limit per pixel is one 2 byte instruction, so that's 192 bytes per column, or 18 KB for all 96 different heights that fit on screen. But there are also oversized columns that don't fit on screen, but still need to be rendered to the full screen height, which takes a lot more bytes. 

 

The simplest code is when the height of the texture is the same as the texture height. Then each instruction is writing exactly one byte:

movb *r0+,*r3+ ; Write to screen buffer and increment
movb *r0+,*r3+ ; Write to screen buffer and increment
movb *r0+,*r3+ ; Write to screen buffer and increment
...

If the screen height is taller than the texture height, some of the texture bytes will be written more than once:

movb *r0,*r3+  ; Write to screen buffer 
movb *r0,*r3+  ; Write to screen buffer 
movb *r0+,*r3+ ; Write to screen buffer and increment 
...

If the screen height is smaller than the texture height we have to skip some texture bytes:

movb *r0+,*r3+ ; Write to screen buffer and increment 
inc r0         ; Increment
movb *r0+,*r3+ ; Write to screen buffer and increment 
inc r0         ; Increment
...

If we need to skip multiple bytes it will be faster to use ai (add immediate) instructions.

 

I assume that in most cases groups of instructions would repeat themselves periodically, so we could add loops, which may be what we need to fit the code into memory.