English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. AMOS

 
 
Thread Tools
Old 23 May 2019, 00:55   #1
Mikket
Registered User

 
Join Date: May 2019
Location: Perttula
Posts: 7
Little raycasting demo

Hi !
I made this little raycasting demo:
[ Show youtube player ]
There's the source code also.
Mikko
Mikket is offline  
Old 23 May 2019, 01:20   #2
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 1,377
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!
Dunny is online now  
Old 23 May 2019, 02:56   #3
Mikket
Registered User

 
Join Date: May 2019
Location: Perttula
Posts: 7
Thanks, I will try
Mikket is offline  
Old 23 May 2019, 05:55   #4
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 168
Looks rather impressive for something written in a BASIC dialect! And it’s already far above 1fps if the video is not deceiving.
pipper is offline  
Old 23 May 2019, 08:47   #5
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 642
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.
britelite is offline  
Old 23 May 2019, 10:11   #6
Mikket
Registered User

 
Join Date: May 2019
Location: Perttula
Posts: 7
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 !
Mikket is offline  
Old 23 May 2019, 13:15   #7
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 418
Nice job.

Last year I too made a small raycaster test with Blitz Basic:
http://eab.abime.net/showthread.php?t=90765
Master484 is offline  
Old 23 May 2019, 14:46   #8
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,596
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).
roondar is offline  
Old 23 May 2019, 15:36   #9
Mikket
Registered User

 
Join Date: May 2019
Location: Perttula
Posts: 7
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.
Mikket is offline  
Old 23 May 2019, 20:00   #10
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 1,249
What are performances if you use no texture or one or two bitplane textures?
saimon69 is online now  
Old 23 May 2019, 22:58   #11
Mikket
Registered User

 
Join Date: May 2019
Location: Perttula
Posts: 7
No noticeable difference using 16 colour screens or drawing with Bar.
Mikket is offline  
Old 24 May 2019, 01:34   #12
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 655
Quote:
Originally Posted by roondar View Post
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.
robinsonb5 is offline  
Old 24 May 2019, 10:44   #13
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 642
Quote:
Originally Posted by robinsonb5 View Post
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
britelite is offline  
Old 24 May 2019, 11:30   #14
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 223
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.

Last edited by chb; 24 May 2019 at 11:41. Reason: clarification
chb is offline  
Old 24 May 2019, 15:35   #15
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 418
Quote:
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.

Quote:
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.
Master484 is offline  
Old 24 May 2019, 18:27   #16
Mikket
Registered User

 
Join Date: May 2019
Location: Perttula
Posts: 7
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.
Mikket is offline  
Old 25 May 2019, 15:18   #17
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 418
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.
Master484 is offline  
Old 25 May 2019, 18:53   #18
Mikket
Registered User

 
Join Date: May 2019
Location: Perttula
Posts: 7
Thanks again. I will defenetly test those speed ups. They are logical.
Mikket is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
To all demo experts: Trying to identify a music demo from '89 or '90 hoderer support.Demos 4 05 January 2018 10:16
Maniac Mansion Demo Disk - Onslaught releases the demo of a classic for C64! Neil79 Retrogaming General Discussion 0 16 January 2015 11:40
Yet another "plz help me find a demo" thead! AGA demo w/ texturemapped building ruinatokyo request.Demos 1 26 September 2013 17:29
Old Amiga Demo Wanted -- Music Track "The last ninja demo" scribbleuk request.Demos 13 23 April 2012 14:35
CU Amiga #75/Simon The Sorcerer Demo + CU Amiga #99/Amazon Queen Demo MethodGit request.Old Rare Games 12 16 February 2004 18:16

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 01:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.08636 seconds with 13 queries