Real Time 3D example

Want to discuss about Demos on the Oric, here you are !
jbperin
Pilot Officer
Posts: 105
Joined: Wed Nov 06, 2019 11:00 am

Real Time 3D example

Post by jbperin »

Hi every body,

Here are two sample demos that I made to illustrate the use of an hyper fast 3D projection routine written in 6502 assembly and recently published on glOric project at Oric Software .

These sample demo consists in:
- an intro in which the camera position and orientation is animated
- followed by an interactive phase where you can manually move the camera in order to test real time interactive mode.

In text mode sample demo, the camera is moved with the following keyboard commands:
  • Arrow (up / down) to go ( forward / backward )
  • W / X to shift (left / right)
  • Arrow (left / right ) to rotate the camera
  • Q / A to pitch (up / down)
  • P / ; to go (up / down)
Image

In hires mode sample demo,the camera is moved with the following keyboard commands:
  • Arrow (left / right ) to rotate around the object
  • Q / A to go (up / down)
Image

Do you find it goes fast ?

Source Code of these little demo

Learn how to create demos like these on the related programming interface thread

Merry Christmas to you all ;-)

PS: comments, advices, feedback , questions ... welcome
Attachments
glOricHiresSample.tap
demonstrates use of fast projection routine in hires mode
(24.55 KiB) Downloaded 68 times
glOricTextSample.tap
demonstrates use of fast projection routine in text mode
(24.55 KiB) Downloaded 55 times
Last edited by jbperin on Mon Dec 23, 2019 3:00 pm, edited 1 time in total.

jbperin
Pilot Officer
Posts: 105
Joined: Wed Nov 06, 2019 11:00 am

Re: Real Time 3D example

Post by jbperin »

I forgot to say:

- It is a proof of concept stuff .. it is stongly bugged. For exemple there's a bug in the text version which makes that, when a shape reach column 0 of screen, it kind of erases the rest of the line. I would be thankful to anyone that can help me solve this issue.

- The text in the text demo is "MERCI RENE" which means 'THANKS RENE" in the name of Rene the fench guy who maintains some Oric alive for newcomers like me. Thanks to him.

- The code contains some parts that i found on the internet:
The fact that this hyper fast projection routine is so Oric orignal comes from this own made euclidian norm (which i must admit i'm somewhat proud of) which is explained here (in french) and which only exists on Oric.

User avatar
iss
Wing Commander
Posts: 1081
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Real Time 3D example

Post by iss »

Congrats, @jbperin!

Both demos are definitely cool and good basis for further evolution - for instance into a 3D-game. :)
I follow your development progress on orig.org but thank you for posting here too, so more people can try and have fun with your demos!

User avatar
ibisum
Wing Commander
Posts: 1292
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Real Time 3D example

Post by ibisum »

Looks really cool but I can't seem to get it to load on Oricutron. Maybe I have a problem with my build, but perhaps others can verify .. anyway I'll check it out on a real Oric later this afternoon when I head to the lab and plug in my new Erebus for the first time. ;P

User avatar
mikeb
Flying Officer
Posts: 224
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: Real Time 3D example

Post by mikeb »

jbperin wrote:
Mon Dec 23, 2019 1:32 pm
when a shape reach column 0 of screen, it kind of erases the rest of the line. I would be thankful to anyone that can help me solve this issue.
I don't know if this is rated "too obvious" or "why did no-one tell me?", but in TEXT mode (not LORES 0/1) the first two columns are usually protected, as they contain the paper and ink colour serial attributes. You cannot overwrite these without losing the text mode "black-on-white text" look -- the *default* colour scheme of the ULA is always white fg (ink) on black bg (paper) until it is told otherwise.

In LORES 0, these columns are free for use, which is why the standard colour scheme is white on black: No attributes needed in the left two columns, so you can use all 40 columns.

If you must use TEXT mode, don't write to the first two columns, this may make the "bug" go away.

User avatar
kenneth
Flight Lieutenant
Posts: 317
Joined: Fri Nov 26, 2010 9:11 pm
Location: France PdD
Contact:

Re: Real Time 3D example

Post by kenneth »

Nice christmas gift 8)

jbperin
Pilot Officer
Posts: 105
Joined: Wed Nov 06, 2019 11:00 am

Re: Real Time 3D example

Post by jbperin »

iss wrote:
Mon Dec 23, 2019 1:37 pm
Congrats, @jbperin!

Both demos are definitely cool and good basis for further evolution - for instance into a 3D-game. :)
I follow your development progress on orig.org but thank you for posting here too, so more people can try and have fun with your demos!
Thanks you very much iss !! It's very nice to read that you're interested in what I do :-)
I think i got one of my most used tool from your site ;-)
I don't think I'm able to do a game for now .. I'm too beginner in Oric programming.
So I'm first going to create tools for game creators and demo makers in the hope that one of them want to use my work (and put my name in credits).
ibisum wrote:
Mon Dec 23, 2019 1:41 pm
Looks really cool but I can't seem to get it to load on Oricutron. Maybe I have a problem with my build, but perhaps others can verify .. anyway I'll check it out on a real Oric later this afternoon when I head to the lab and plug in my new Erebus for the first time. ;P
I hope your new Erebus works fine. If you managed to make my demo running on a real Oric, please tell me .. because you'll be the first one to do that. Cause I haven't yet been able to run it on my Oric (I still hasn't received the cable to read tape from a jack).
I long to have my code running on a real Oric .. and you might actually do that before me :-)
So keep me posted :-)
mikeb wrote:
Mon Dec 23, 2019 6:35 pm

I don't know if this is rated "too obvious" or "why did no-one tell me?", but in TEXT mode (not LORES 0/1) the first two columns are usually protected ...

In LORES 0, these columns are free for use ...

If you must use TEXT mode, don't write to the first two columns, this may make the "bug" go away.
WAOU MAN !! It fixes the issue !! I knew that there was something weird in column 0 on text mode and I had put a check on it in my rasterisation.
But I was ignoring that the TWO first columns was condamned. Thank you so much !!
I give you this commit number : 81eea6fbe4bcb190b69514f762495b7daba8d298

With it, you're welcome in France ;-) It's your ticket to come and visit me in France (I might have my own house next year).

kenneth wrote:
Mon Dec 23, 2019 11:02 pm
Nice christmas gift 8)
Thanks kenneth .. ;-)

User avatar
Chema
Game master
Posts: 2665
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Real Time 3D example

Post by Chema »

Really nice! I wish someone managed to implement filled polygons.

Congratulations!

User avatar
ibisum
Wing Commander
Posts: 1292
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Real Time 3D example

Post by ibisum »

Really nice! I wish someone managed to implement filled polygons.
I know, right! At first I was all "BATTLEZONE" for the Oric, but now I'm like "SPECTRE VR" for the Oric! :)

User avatar
Dbug
Site Admin
Posts: 3345
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Real Time 3D example

Post by Dbug »

Well, there's been filled polygons demos already, just nothing in a game :)

jbperin
Pilot Officer
Posts: 105
Joined: Wed Nov 06, 2019 11:00 am

Re: Real Time 3D example

Post by jbperin »

Chema wrote:
Wed Dec 25, 2019 11:19 pm
Really nice!
Congratulations!
Thank you very much Chema :D
I'm fond of your work on Oric. I learn a lot from your code. It's really cool to see that you appreciate these samples.
Chema wrote:
Wed Dec 25, 2019 11:19 pm
I wish someone managed to implement filled polygons.
The polygon rasterizer at Defence-force is so easy to use that I've quickly managed to integrate it in order to render a few faces.
Please have a look here.

Here are the TAP files of:
- the Face Rendering attempt
- the corrected text version (big thanks to mikeb !!)
Attachments
glOricLoresSample.TAP
(25 KiB) Downloaded 47 times
glOricFaceSample.TAP
(25 KiB) Downloaded 58 times

User avatar
mikeb
Flying Officer
Posts: 224
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: Real Time 3D example

Post by mikeb »

jbperin wrote:
Wed Dec 25, 2019 11:10 pm
But I was ignoring that the TWO first columns was condamned. Thank you so much !!
I give you this commit number : 81eea6fbe4bcb190b69514f762495b7daba8d298
Glad that sorted it :)

Mike.

ThomH
Flying Officer
Posts: 215
Joined: Thu Oct 13, 2016 9:55 pm

Re: Real Time 3D example

Post by ThomH »

Cool, I've written homebrew 3d on an Atari Lynx, which has a separate maths unit including multiply with accumulate that makes life very easy, and on a Z80-based machine. So naturally I stuck my nose into your code.

It looks like your fast project ejects the classic linear algebra solution of dividing by z in favour of a trigonometric solution, using atan to determine the angles between a point and the horizontal and vertical planes, then using those angles to look up the 2d point through which the relevant ray runs? Have I understood that correctly? If so, very devious!

If you can come up with that, I'm sure you're ahead of me on almost everything else, but on the off-chance: definitely using a binary search for display-area edge clipping. I do them in 3d, before projection, to offer guarantees about range at the next stage but I've also read persuasive arguments that if your objects are generally 'small' then it's more efficient to clip after projection.

I keep meaning to stop being lazy and write a quick tunnel game based on fixed height walls, 2d map geometry, a 1d 1/z buffer and partial redraws — in the special case of fixed-height walls the 1/z buffer is nothing more than a "put this column into this slot only if it is bigger than the one that's already here", and you end up with a 240-entry table of height + pattern per screen column. So if you still have the previous table sitting around, it's pretty trivial to draw only the differences — completely redraw any column with a different pattern, just adjust the height of the others up or down a bit.

You're obviously a much more productive person than I am.

User avatar
Chema
Game master
Posts: 2665
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Real Time 3D example

Post by Chema »

jbperin wrote:
Thu Dec 26, 2019 5:55 pm
Chema wrote:
Wed Dec 25, 2019 11:19 pm
Really nice!
Congratulations!
Thank you very much Chema :D
I'm fond of your work on Oric. I learn a lot from your code. It's really cool to see that you appreciate these samples.
Chema wrote:
Wed Dec 25, 2019 11:19 pm
I wish someone managed to implement filled polygons.
The polygon rasterizer at Defence-force is so easy to use that I've quickly managed to integrate it in order to render a few faces.
Please have a look here.

Here are the TAP files of:
- the Face Rendering attempt
- the corrected text version (big thanks to mikeb !!)
I also tried this idea for 1337, but found it not too good for a game. The trick used to speed things up resulted in half vertical resolution and models looked really bad in the distance. Also, other elements flickered wildly (stars) kot looking very good. I posted some demos and discussed this in the development forum here, at Defence-Force, if you're interested.

I always wanted to find a proper polygon routine, but never found ideas to go for it, and ended up finishing the game with wireframe graphics only, as the original Elite.

ThomH
Flying Officer
Posts: 215
Joined: Thu Oct 13, 2016 9:55 pm

Re: Real Time 3D example

Post by ThomH »

On polygon filling, I've never come up with a completely compelling solution for dealing correctly with clipping against z=1, which can induce additional polygon edges that are not parallel to an edge of the screen and which do not connect on-screen vertices. On a 16-bit machine you have time to just do the right thing — clip once to z=1 possibly increasing the number of vertices on your polygon by one — then do [x/y]=[+/-]z by not generating extra edges and being intelligent in screen space, but I've always felt there's probably a cheaper solution that just evades my imagination.

You could just not do z=1 as a separate step and let your clipped polygons possibly erroneously fill to screen corners. It's only an issue if you get your camera actually to intersect a polygon, not merely for the polygon to hit one or more of the clip planes. So maybe you can hand-wave it away.

And, otherwise, I guess, on edge tables one rediscovers the benefit of polygon strips.

Post Reply