# Raycasting on msx2 screen 5

Pagina 4/27
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

Or just maby not use casting at all.

Casting is quite nice since it's independent of the size of the map. This is a good attribute for an engine that is used on a system with the insane amount of memory that many MSX2 has.

I don't really see the benifit of using such a high resolution with the big stepsize, perhaps you can save some rendering time by changing to multicolor and pushing the data with the cpu.

Then of course the casting setup can be optimized, take a look at how the variables actually changes between each iteration of the loop. Probably a lot of the calculations can be omitted if you save some of the values between the iterations.

Oh, and you probably have a multiplication by 24 in the worldMap[mapX][mapY] lookup, perhaps changing this to worldMap[mappos] and scale stepX and stepY accordingly would save a few cycles. ( Replacing mapX += stepX with mappos += stepX and mapY += stepY with mappos += stepY )
This is the absolute innermost loop of the casting so this lookup is done a lot.

A quick optimization tip: reduce screen size to 192 x 192 (in a Zanac-like layout). Since raycasting uses vertical steps, that will optimize rendering in 25%.

A quick optimization tip: reduce screen size to 192 x 192 (in a Zanac-like layout). Since raycasting uses vertical steps, that will optimize rendering in 25%.
Am I completly missing something now or are you talking about another algoritm? I can't fins anything in the source that indicates that this would actually speed up anything.

What you should do however is to change all those doubles to fixpoint math, and if that is too much work, change them to float or at least make sure that the compiler you use don't differ between float and double.

Hey, I don´t know Assembly, but...

Raycasting in Wolf 3D is about dividing the player field of view in n vertical stripes, where n is the desired resolution. Basically if the player FOV is about 120 degrees, the screen is rendering by dividing an arc of 120 degrees in 192 steps, checking if an imaginary line crosses a wall, and draws a vertical line scaled according to the distance.

I don´t understand why raycasting runs so slow in a Turbo-R, since it Wolf 3D worked faster than that in a 286, and with texture walls.

BTW, I saw some decent raycasting for MSX2 sometime ago here at msx.org. The program rendered screen at 4x1 pixels, and that would indeed make things faster.

I don't really see the benifit of using such a high resolution with the big stepsize, perhaps you can save some rendering time by changing to multicolor and pushing the data with the cpu.

for the same reason change to screen 2 and draw one of the 768 tiles. But's what the challenge.
screen 3 is too blocky.
And actually the vdp/vram size is far from be the bottleneck.....
calculation speed is.

...not usng casting?...

Just draw walls like one single line. The screen is just an array of depth (z-buffer) one for each column.
Additionally you could have another array wich holds color information.

Now calculate endpoints x and z, and draw a line between in 2D plane (like you would do manually).
Meanwhile update z-buffer and check for depth.

Checking if a line is in players view, or needs to be drawn at all, should ofcourse be sped up by smart
management and handy additional info like a normal vector.
With a normal vector it is easily determined if a wall needs to be drawn (positive vector).
With management you would not have to test for hundreds of lines, but only the ones that could appear.
So store lines in smaller maps like rooms and such (in a smart way to avoid pop-up).

And than there is portal rendering (at the bottom of the article manuel mentioned):

It is quite simular I think. Or maby even smarter, I can't figure it out, maby you can.

rip from maze? naaa
Sorry for my extremely lame idea.

I'm pretty bad in 3D graphics, but I was just wondering, that maybe you could gain some speed by skipping lines on x-axis...

If you end up to same wall in x and x+8 for example, you can propably calculate the lines in between with less CPU power than going trough every possibility.

OK, if you are sure that the vdp is a minor part of the render time than it's mostly a mattor of first changing all the doubles to fixpoint and then hunt down multiplications..

For now it is!
my code is here
http://gist.github.com/166406
anyone willing to suggest improvements for the fix point & ASM conversion ?

Pagina 4/27
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9