forum.defence-force.org

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)

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)

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

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:

• Rasterizing in hires mode comes, on advice by DBug (thank you), from Defence-Force public line routine,
• Atan2 comes from codebase 64

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.

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!

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

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.

Nice christmas gift

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

Thanks kenneth ..

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

Congratulations!

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!

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

Chema wrote: ↑Wed Dec 25, 2019 11:19 pm Really nice!
Congratulations!

Thank you very much Chema
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 pmI 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 !!)

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.

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.

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
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 pmI 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.

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.