Little raycasting demo

[Mikket]

Hi !
I made this little raycasting demo:
[ Show youtube player ]
There's the source code also.
Mikko

[Dunny]

Very nice. Get that up to say, 15fps (in AMOS!) rather than the 1 fps you currently get and this will make a very nice attempt at Wolfenstein!

[Mikket]

Thanks, I will try

[pipper]

Looks rather impressive for something written in a BASIC dialect! And it’s already far above 1fps if the video is not deceiving.

[britelite]

Not bad at all! Would be interesting to see how it would perform with the raycasting done in pure AMOS and the rendering done with optimized asm-routines.

[Mikket]

Thanks !
Really the frame rate is only 1-2 now. Video is misleading , sorry (It's accelerated trough emulation).
I think, Amos could benefit asm routines from your demos, Britelite !

[Master484]

Nice job.

Last year I too made a small raycaster test with Blitz Basic:
http://eab.abime.net/showthread.php?t=90765

[roondar]

Every time I read about raycasting on the Amiga I start wondering if it'd be possible to write a raycaster so that it plots 16 horizontal pixels at a time. I'm pretty sure the answer is no or "yes, but it doesn't help you" (as being able to plot 16 pixels at once would be a pretty obvious optimisation given the architecture).

Still, good stuff to see an AMOS implementation. I wonder how it would run on a moderately expanded A1200 (i.e. 68030@33-50Mhz with some fast ram).

[Mikket]

Your version is much faster, Master484 !
Roondar, maybe there is a way, I don't know.

This Zoom command that demo uses, is faster than I expected and I didn't have to make any bobs. Just copy and scale with zoom from texturescreen.

[saimon69]

What are performances if you use no texture or one or two bitplane textures?

[Mikket]

No noticeable difference using 16 colour screens or drawing with Bar.

[robinsonb5]

Originally Posted by roondar

Every time I read about raycasting on the Amiga I start wondering if it'd be possible to write a raycaster so that it plots 16 horizontal pixels at a time. I'm pretty sure the answer is no or "yes, but it doesn't help you" (as being able to plot 16 pixels at once would be a pretty obvious optimisation given the architecture).

I had an idea a year or so back, when one of these discussions sprang up, about making a raycaster that plotted horizonal rather than vertical spans. The idea was to make something a bit like a massively simplified Descent, or maybe something like the mobile game Smash Hit. In that case it might be possible to plot 16 pixels at once, but it might also be possible to pull some tricks with the scroll registers and bitplane pointers in a copperlist to avoid texture scaling with the CPU.

[britelite]

Originally Posted by robinsonb5

In that case it might be possible to plot 16 pixels at once, but it might also be possible to pull some tricks with the scroll registers and bitplane pointers in a copperlist to avoid texture scaling with the CPU.

Yeah, this would definitely be worth trying out, the rendering (as shown by several demos) would definitely run in full framerate. Adding realtime raycasting would slow it down, of course, but I'd say 25fps would definitely be doable, especially with some trickery

[chb]

If you can live with 16 pix wide (or high? anyway, limited only in one dimension) textures, a technique like in the opening tunnel/hallway of Arte by Sanity is also possible: Use pre-scaled 16 color stripes where you set the colors for each line with the copper like with a copper chunky mode. Maybe even using different sets of stripes would look good? Like one set with a 16 pix texture repeated several times (as in Arte) and one with non-repeated or mirrored 16 big pixels? Or even combining the approaches and use the repeated copper-chunky textures for the walls and the scroll register method for some special textures? The latter method has the disadvantage that you can only shrink by max. 16 pix and therefore need a lot of pre-scaled images, eating away chip ram, so it may be beneficial to use it only for a few textures. And a horizontal raycaster can just switch between those two approaches in every line without a problem.

Displaying other objects would be slightly hard, though - you could either use sprites or limit yourself to 8 colors / 8 pixel textures and go dual playfield. But the same problem applies for a pure scroll register based approach.

[Master484]

Your version is much faster, Master484 !

Yes, but of course my demo cheats a little bit; it uses no pixel plotting at all, instead it just draws pre-made "fake texture wall blocks". And also the raycaster skips some 75% of the rays.

The ADF has the Blitz source code, and it contains a detailed explanation of the tricks used. The code tries it's best to avoid floats and complex math, and in fact the rays move much like some bullets in a shoot'em up, with teleports and all sorts of cheating going on. So it's a little bit weird system, but some of the techniques may be useful in a real pixel plotting raycaster too.

No noticeable difference using 16 colour screens or drawing with Bar.

This most likely means that the pixel plotting in your demo is fast, but it's the raycaster code that is slowing things down.

The one trick that helped me the most, was "loop unrolling".

So maybe you should check which Gosubs or Functions in your code get executed the most times during a loop.

In a raycaster the inner routines can get over 100 execution times. And if those routines are in a Gosub or a Function, then that's 100+ Gosubs and Returns, or 100+ function setups. And all those commands are just pure slowdown.

So what I did in my demo, was to take the routines that were in Gosubs, and copy paste them to the places where the Gosubs were. This way I got rid of hundreds of Gosub and Return commands in the loop, and the speed of the raycaster code almost doubled.

But of course removing all Gosubs can make the code totally unreadable, so if you decide to do this, then always have a code version that still has the gosubs.

And also if AMOS has "macros" (compiler generates code when it sees a certain word), then they can be used to do this whole thing; just replace all gosubs with macros.

[Mikket]

Thanks, I have only two Gosubs/Procedures. The distance of two points and other for finding out intersection point in a line. And they are not long.
I try unrolling them.
One test come also to my mind. Amos 3d has command to convert 3d point to screen point. If I replace wall-lines with series of points in a line, I can place texture stripes in
right places. Amos 3D has also range command for finding out distance(size of stripe).
I tried that once with wireframe objects, and it worked quite fast.

[Master484]

I looked at your source code, and here are some ideas that might bring more speed.

1.
The wall sorting routine now calculates the middle points of every wall line, every frame.

And right now both the X and Y middle point calculations have an addition and division " (X1+X2)/2 ". And divisions are the slowest operations possible, so they should be avoided in the main loop if possible.

These middle points should be pre-calculated when the program starts, and then in the main loop they can be simply read from an array.

You could just add the pre-calculated middle points to the LINEDATA array, but that is a 2-dimension array, which makes it somewhat slow.

So maybe it's better to make two new 1-dimension arrays, one for the X and one for the Y middle points.

2.
And about the LINEDATA array, this is the most used array in the program. And it's a two dimensional array, and at least in Blitz Basic two dimensional arrays are much slower than one dimensional arrays.

So you could test if replacing the LINEDATA array with five 1-dimensional arrays would bring more speed. And if it does, then do this to all other arrays as well, if possible.

So have something like:
Dim LINEDATATEXTUREID (LINES)
Dim LINEDATAXSTART (LINES)
Dim LINEDATAXEND (LINES)
Dim LINEDATAYSTART (LINES)
Dim LINEDATAYEND (LINES)

This makes the data handling a little bit more complicated, but the code speed should improve, because now stuff like X1=LINEDATA(F,1) can be replaced with X1=LINEDATAXSTART(F).

I counted quickly that in the wall sort and distance sort routines the LINEDATA array is accessed around 500+ times. So it's definitely worth it to test if using single dimensional arrays bring more speed.

3.
Also right now you clean the screen with CLS. This is OK, but in Blitz Basic I have noticed that it's faster to do the clean in this way:

Make a separate "clean bitmap", which is the size of your screen, and then instead of CLS, copy this bitmap to your current drawing buffer using the blitter. In Blitz I would do this with a command called BlockScroll, which is the fastest command for copying stuff from one bitmap to another.

And also to this "clean bitmap" you can put the floor, the printed texts, the map, and the boxes that surround the map and the 3D view. This saves a lot of drawing.

And in fact you don't even have to clean the whole screen. It's enough to clean only those two small view boxes that you have. So maybe just clean them with box drawing, or by blitting square images on top of them, whichever is faster.

---
---

Also analysing the program speed would be easier if the program would print on screen how many frames it took to make the last frame.

In Blitz I usually put a simple "framespassed" variable to a vertical blank interrupt, so that this variable increases every frame. And then in the main loop I print this value to screen, and reset it to 0 at every screen buffer switch.

And to support this I also use a command called VPOS, which tells the current Y position of the screen drawing ray, and this value too I print to screen.

This way I can see the speed effects of even small code changes, which might be hard to notice otherwise. Maybe AMOS has these sort of commands too.

[Mikket]

Thanks again. I will defenetly test those speed ups. They are logical.