Raycaster

[artrag]

I made it work even with software sprites. Set to 255 the bytes in the height buffer of columns where objects are plotted. 

In this way, floor and ceiling of those columns are always entirely updated. 

 

PS

If you want to be smarter than me, set in the buffer the column height corresponding to the sprite distance. In this way you will save a fraction of the floor and of the ceiling that is certainly not corrupted by the sprite

As software sprites are ordered by distance you should get the correct height  even if multiple sprites are plotted in the same column, as you plot last the closest to you (with the maximum height)

 

Edited August 25, 2020 by artrag

[artrag]

Differential plotting can be extended to walls if you have a reasonable amount of flat walls.

 

You need to store an additional array with 64 bytes for the colours of the columns from the previous frame.

Actually, I've stored in it an index to a buffer of texture data, where indexes from 0 to 15 are flat colours, higher values are actual indexes to texture data. 

 

If the new column or the old column have textures, or if both columns are flat but the colours are different, you fall in the previous case, were only ceiling and floor are traced differentially.

If both columns are flat of the same colour, if the new column is shorter, you can fill (differentially) only ceiling and floor, if the new column is taller, you can fill only the difference between the two heights (and skip updating ceiling and floor).

 

All the testing is just a comparison between the colour indexes, if they differ, optimise the plot of ceiling and floor according to the heights and plot the new column.

If they match and the value is <16 (flat colour), you can plot differentially or the column or the floor and ceiling according to the comparison between the new and the old height.

If they match but the value is >16 (texture), again, optimise the plot of ceiling and floor according to the heights and plot the new column.

  

Edited August 25, 2020 by artrag

[+jedimatt42]

On 8/17/2020 at 1:29 PM, artrag said:

Not having examined the sources, I cannot say what is the technique used by msx games, but for sure there is no raycasting involved

This is a V9938 game that use something very close to what we said, probably using 4 distances

 

 

Another (craptastic) msx game using this 3d view and moviments (this time for msx1)

 

I've found this too

 

This other comes with sources in basic

https://www.msx.org/news/software/en/3d-maze-written-in-basic

 

I vote for your raycaster

 

A better MSX example would be : 

 

 

 

[artrag]

1 hour ago, jedimatt42 said:

 

A better MSX example would be : 

 

 

 

ToP was already mentioned earlier and it is a true raycaster with smooth rotations ( this is its latest version https://github.com/santiontanon/talesofpopolon-ext )

We were telling about games with fixed view and movements per squares like EoB 

 

Edited August 30, 2020 by artrag

[Asmusr]

This version has textured ceiling and floor. There are 8 directions, and you're moving 1 square at a time so the textures don't have to move. The whole 6K background with the textures is simply copied from ROM to the screen buffer before drawing the walls, so I was surprised that it's running as fast as this, but the old ceiling/floor drawing must also have taken a lot of time.  

 

 

texcaster8.bin

[artrag]

Awesome! So there is room for other savings by copying only the needed part, but it the speed is already excellent.

I see that, while walking in diagonal, the doors in the walls seem to strife with respect the tiles on the floor.

It is due to the fact that the ceiling and floor do not move with the player.

Maybe if you make the size of the tiles on floor and ceiling exactly equal to one square on the map (that is the current step of the player) you should avoid the effect.

 

PS

they seem already one square... nevertheless when moving diagonally, something isn't fully convincing 

Look in the video at 0:50 - 0:53 how the blue door on the green wall seems to move with respect to the black lines on the floor

Edited September 2, 2020 by artrag

[Asmusr]

8 hours ago, artrag said:

Awesome! So there is room for other savings by copying only the needed part, but it the speed is already excellent.

I see that, while walking in diagonal, the doors in the walls seem to strife with respect the tiles on the floor.

It is due to the fact that the ceiling and floor do not move with the player.

Maybe if you make the size of the tiles on floor and ceiling exactly equal to one square on the map (that is the current step of the player) you should avoid the effect.

 

PS

they seem already one square... nevertheless when moving diagonally, something isn't fully convincing 

Look in the video at 0:50 - 0:53 how the blue door on the green wall seems to move with respect to the black lines on the floor

It seems fine to me.

[artrag]

2 hours ago, Asmusr said:

It seems fine to me.

I am referring to these frames. The door is supposed to be perfectly aligned to the floor tiles (look at frame 054b, front view).

As you can see in frames 052 and 053, it loses its alignment with respect to the floor while the player is moving.

 

[Asmusr]

8 hours ago, artrag said:

I am referring to these frames. The door is supposed to be perfectly aligned to the floor tiles (look at frame 054b, front view).

As you can see in frames 052 and 053, it loses its alignment with respect to the floor while the player is moving.

Right. So the diagonal speed has to be sqrt(2) instead of 1 for the floor to be fixed. 

[artrag]

2 hours ago, Asmusr said:

Right. So the diagonal speed has to be sqrt(2) instead of 1 for the floor to be fixed. 

YES! The player has to move on a grid passing on the center of the map squares or floor/ceiling and walls will misalign each other as soon as you walk in diagonal

[Tursi]

Pretty impressive though!

 

[artrag]

Rasmus you could be interested in this

https://opengameart.org/content/first-person-dungeon-crawl-art-pack

And maybe in this

https://github.com/SaffronCR/msx-rpg/tree/48ab711640864c79c5fce5aad38470f96b485b51

 

[Asmusr]

I implemented the incremental drawing of the floor and ceiling that @artrag suggested, and the frame rate is quite good now when you move in the same direction. I also adjusted the movement so you are always placed in the centre of a square. That helped with the sliding of floor texture relative to the walls, but did not solve it completely. 

 

 

There is a small issue that you can see at the end of the video: because I'm drawing all even column pixels as movb (with the right nibble zeroed) and the odd column pixels as socb (like OR, with the left nibble zeroed) I really need to draw both the odd and even pixel next to each other for the correct result, but when the height of the wall in the two columns differ I don't draw both pixels at the top and the bottom, so the result is a few pixels with wrong colors. Drawing the pixels 'correctly' by first removing the old pixel with szcb and then setting it with socb would take twice as long, so probably not worth it.

 

A bigger issue is that because I cannot execute code in one ROM bank that reads data from another ROM bank I either have to give up some of the optimization, or invent a new ROM cart that can bank switch two 4K banks independently, or move to SAMS. I'm reluctant to do the latter because I don't really need more RAM - just the bank switching - but it's probably the path I have to take.

 

texcaster8.bin

[artrag]

It looks much better now and the speed has improved even if I was expecting something faster especially when walking in corridors.

Do you apply differential plotting only in the ram buffer or also in the VRAM transfer?

 

 

[Asmusr]

7 hours ago, artrag said:

It looks much better now and the speed has improved even if I was expecting something faster especially when walking in corridors.

Do you apply differential plotting only in the ram buffer or also in the VRAM transfer?

No I didn't optimize the VDP transfer yet.

[artrag]

Apart from the incremental drawing of floor and ceiling, you can totally skip the plotting of entire columns of textures if you are able to index them globally and recognize that at a given position there is already on the screen the very same column of texture at the very same scale you need.

While walking along corridors one square at time, the 90% of the screen doesn't change (look e.g. at 0:22-0:24 in the video), you can get such a speedup that you will end to introduce a system for dynamic speed regulation.

Edited September 8, 2020 by artrag

[artrag]

ps

Is there a s.c. strife mode ? I.e. when you walk sideway while facing the opponent 

[Asmusr]

On 9/8/2020 at 6:22 PM, artrag said:

ps

Is there a s.c. strife mode ? I.e. when you walk sideway while facing the opponent 

Not yet.

[Asmusr]

On 9/8/2020 at 5:49 PM, artrag said:

Apart from the incremental drawing of floor and ceiling, you can totally skip the plotting of entire columns of textures if you are able to index them globally and recognize that at a given position there is already on the screen the very same column of texture at the very same scale you need.

While walking along corridors one square at time, the 90% of the screen doesn't change (look e.g. at 0:22-0:24 in the video), you can get such a speedup that you will end to introduce a system for dynamic speed regulation.

Here we go. It's skipping drawing and upload of columns where the wall has unchanged height and texture. It's also skipping upload of the top and bottom 3rd of a column if the wall height before and after is lower than 64.

 

 

[artrag]

The speedup is visible when you walk in corridors or close to a wall.

I think that if you aim to an EoB type game the levels will be mainly corridors and doors.

I see that the frame tearing is slightly more visible, probably because even if you plot less data, you work on each column from left to right where before you was going from top to bottom on the whole screen... no idea on how improving this

[MueThor]

Dear Asmusr,

 

In your video below a problem can be seen in the sequence from 0:37 min to 0:42 min: Parts of the door seem to vanish and reappear or not in an illogical manner. Maybe you can somehow settle this problem.

 

 

Regards 

On 9/2/2020 at 9:44 PM, Asmusr said:

This version has textured ceiling and floor. There are 8 directions, and you're moving 1 square at a time so the textures don't have to move. The whole 6K background with the textures is simply copied from ROM to the screen buffer before drawing the walls, so I was surprised that it's running as fast as this, but the old ceiling/floor drawing must also have taken a lot of time.  

 

 

texcaster8.bin 256 kB · 9 downloads

 

Edited September 10, 2020 by MueThor

[Elia Spallanzani fdt]

but if you want to make a version of eob, where speed is not critical, wouldn't it be better to use pre-calculated backgrounds at a higher resolution?

[Asmusr]

3 hours ago, MueThor said:

In your video below a problem can be seen in the sequence from 0:37 min to 0:42 min: Parts of the door seem to vanish and reappear or not in an illogical manner. Maybe you can somehow settle this problem.

In this low resolution (64x192) with only 16 colors you will get aliasing errors where details disappear. The earliest texture mapped games like Wolfenstein were using 320x200 in 256 colors.

[Asmusr]

3 hours ago, Elia Spallanzani fdt said:

but if you want to make a version of eob, where speed is not critical, wouldn't it be better to use pre-calculated backgrounds at a higher resolution?

Maybe you could get a better result, but I don't have any way of producing those backgrounds, and it would mean starting all over again. This project is going in the direction where the possibilities take it, and the chance it will end up as a version of EOB is close to zero.

[MueThor]

Now some stupid questions: You write that the resolution is 64x192. Not 192x64 (the images in your videos are broader in comparison to their height)? And will the Raycaster be really much slower, if you worked with a resolution of 128x192?