Amiga 3D Render Engine PORTED to PlayBasic

[stevmjon]

i have been working on this ported code for 2 months. this is version 1, with only enough active menu's to re-create the cover of the book.

the original book is called "Amiga 3D Graphic Programming in BASIC"  published in 1989.

i purchased the book in 1990 when i owned an Amiga 500. i never got around to coding the book back then, but over the last several years i have studied up on 3D, so thought i would give it a try.
well, success. i got the ray tracing up and running, the main scene (with default objects to re-create book cover) working, and the editor is active enough to see the objects from the main scene.
i will get the editor and main scene running more complete in version 2. i did notice it will be a learning curve to use this program, because of the way it is set up...

to port the code took time because i needed to use another 5 books for reference to know the commands and libraries etc in this 3D book.
the other books i referenced are:
> AmigaBASIC Inside and Out
> Amiga Graphics Inside & Out
> AMIGA ROM KERNAL REFERENCE MANUAL: Libraries & Devices
> AMIGA ROM KERNAL REFERENCE MANUAL: Includes & Autodocs
> Amiga Machine Language

i am sure glad i had all these books from the old fashioned days.
also the book had obsolete sections of code that are not relevant to modern day computers.
to get some scope of old computers vs new computers, the book said to allow up to 3 days to render if using full res (640 * 400) or 1 day at half res. well... my computer rendered at 1600 * 960 and took 22 seconds, lol.

NOTE: to look at the 'editor' to see the scene objects in it, select it from the drop down menu : Editor > Start Editor.

enjoy, stevmjon

[kevin]

 Steve,

  There's only one word for this and that's  Incredible,  thanks for your continued efforts in bringing this to PlayBASIC community.

  If you knew what's going through my mind in recent times,  attached is my projects folder list.  I've been wanting to write a tracer for PB for years, then a few days ago somebody posted one for the spectrum on one of the basic groups on facebook.  Tiny code footprint and was going to port and post the other day, but ran into dramas with BB2PB which derailed any fun projects.  Looking at screen shots I wonder if that was based on this,  as it'd was really code.  
   
   Anyway enough of my drivel.  Your screenshot is simply glorious, the type of eye candy we're in desperate need these days.   Moreover, the program will be a good way to test future performance of PB while rendering a standard scene.

   So was the original written in Amiga BASIC ?  calling system stuff to augment it ??  

i am sure glad i had all these books from the old fashioned days.
also the book had obsolete sections of code that are not relevant to modern day computers.
to get some scope of old computers vs new computers, the book said to allow up to 3 days to render if using full res (640 * 400) or 1 day at half res. well... my computer rendered at 1600 * 960 and took 22 seconds, lol.

     lol, back in the day those float operations are done via a math library.  No one really thought floats were practical in Amiga 500 days (no hardware fpu).  But things change by the 040/060 days.    Today we have sqrt built instruction on the fpu in silicon,  crazy.    

      Had a lot of troubles running this, all the normal driver related stuff.  Namely that my system doesn't like lots of lock/unlocks on the video surface.   Which will be very common today, as modern drivers are pants.   What I would do is render everything on FX buffer and translate that to the screen.  Which gets rid of 99.99% of the driver implementation issues and will let the user run in a screen size that's different to the physical screen size..  


 

[stevmjon]

i am glad you like this ray tracer.

yes it was made for Amiga BASIC, and it was calling libraries, and was even using machine code for the color crunching. lucky i had the reference books.

i did forget to use lockbuffer / unlockbuffer / fastdot, and i just drew each line directly to screen while testing so you could see the progress, rather than waiting.
i didn't think FX surface would be faster for lots of drawing, like dotc. i only use FX surface when blending / alpha images.
while i think of it, you did tell me to draw to an FX image for my 3D engine, and it did work faster. i should have remembered this.

to update this demo, should i just use lockbuffer / unlockbuffer / fastdot directly to the screen, if that will help for drivers, or should i still draw to an FX image using lockbuffer / unlockbuffer / fastdot?
i still want to sync each line so you can see the progress because i like the effect.
i wasn't overly concerned with speed as todays computers are so much faster than 30 years ago.

out of interest, how long was it taking on your system to render?

stevmjon

[stevmjon]

here is an updated version of the 3D ray tracer.
this version uses drawing to an FX image, using lockbuffer / unlockbuffer / fastdot , then drawing from the FX image to the screen using CopyStripH.
i hope this fixes the driver issues.

for a comparison test i compared 3 methods:
method 1 : (26 seconds) using post #1 drawing dots directly to the screen
method 2 : (19 seconds) using lockbuffer / unlockbuffer / fastdot drawing directly to the screen
method 3 : (19 seconds) using lockbuffer / unlockbuffer / fastdot drawing to an FX image, then using CopyStripH to draw to the screen

stevmjon

[stevmjon]

i just updated the 3D render engine again to version 1.2

this version uses drawing to an FX image, using lockbuffer / unlockbuffer / fastdot , then drawing the FX image to the screen.

what this will fix, is in case a driver 'swaps' the front & back buffers, which will cause flickering of the lines i am drawing 1 at a time while the screen renders.
so, now the whole FX image is drawn to screen each loop, with no flickering effects. also, it only takes 1 second longer to complete compared to using CopyStripH in v1.1.

enjoy, stevmjon

[kevin]

   Amiga 3D Render Engine PORTED to PlayBasic - Ep01 - First Look

 

  What On YouTube

[stevmjon]

thanks very much Kev for the hints and tips. i have implemented them all.

> version 1.3 : added lockbuffer / unlockbuffer to the main scene screen & editor screen. changed fonts to FX to keep colors for menu use.

at least the render engine itself works well on your computer, so my changes there worked in v1.2.
i am glad you made the video to explain these things. you are very helpful in the PB community. i like posting stuff, because i always learn a new hint & tip here and there.

i hope this version works well for people.

  enjoy stevmjon

[kevin]

 Stev,

     Yep this version pretty much runs out of the box,  the shadow render seems is quicker also.   So cool !
     
     Found this link before, which looks like an OCR of this bock.  (login required)

     Only picked through your and the original code mind you, but for some stuff you might as well just make a little emulation layer of functions.  It'd make rest of it smaller without costing you much in the process. 

      Was thinking for stuff like emulating the text output.  ie.  Locate.  etc etc   It;s prolly easier to just wrap up some display functions to do those repetitive tasks.     

      For the menus you can map the display menu to a function name and just call them.   eg Simple Menu  for such an example. 

      in your case you could prolly just name the GUI functions "MENU_"  with the name of the action after the underscore. 





     

[stevmjon]

hey Kev.

interesting link to the book as text (no images though).

i actually made coding this a little harder on myself, because i was trying to port the code as original as i could, even including the authors comments the same.
there was areas i would liked to have changed, but originality is what i was going for.

thanks for the menu example. i just wanted the menu's to work, so was quick setting it up.
i couldn't find a single image on the net to see what the main screen or editor should look like, so i winged it making it look nice with colors, lol.
even i found the code hard to follow when bug finding. there was so many functions jumping around and looping back to the same ones but with different conditions. i needed to revert to taking notes using a text editor to keep track.

i would like to make my own version, using the theory of ray tracing i now understand, and make a version i can follow. it was a learning experience.

   stevmjon

[kevin]

 Stev,

   You know what i've been meaning to do for a while is put together some 3d math libraries.    In case of the Ray Tracing, stuff like ray to sphere / ray to plane /  ray to triangle / ray to mesh style intersection functions.   

   Could then build a light mapper,  as that's one common usage is baking lighting into textures.  Eg  Quake. 
   
   Come to think of it, if he ray to sphere intersection was an internal math library, then you could prolly almost do real time tracing of that sphere scene in a low resolution.   That'd be trippy

thanks for the menu example. i just wanted the menu's to work, so was quick setting it up.
i couldn't find a single image on the net to see what the main screen or editor should look like, so i winged it making it look nice with colors, lol.
even i found the code hard to follow when bug finding. there was so many functions jumping around and looping back to the same ones but with different conditions. i needed to revert to taking notes using a text editor to keep track.

   I only mentioned it as interface building tend to produce a lot of boiler plate code, setting stuff up, catching clicks and stuff.   Those simple menus are ugly as hell, but can be dropped in and off you go.  You know not a conclusion really,  more a starting point.

   For the record I like the orange of blue colour scheme..