Castoric : Raycasting on Oric computers

Since we do not have native C compilers on the Oric, this forum will be mostly be used by people using CC65 or the OSDK. But any general C related post will be welcome !
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Castoric : Raycasting on Oric computers

Post by jbperin »

Hi all,

Here, at Oric Software Studios, we are very very very very glad today to give birth to the very first (as far as I know) open source ray casting library for Oric computers.

CASTORIC

We are glad because:
  • This library is totally open source so that any Oric developer can use it in its own game production.
    We just invite game makers to name the library in order to promote its usage.
  • This library is innovative:
    The raycasting algorithms that are used are not just rewriting of former 16 bits solutions written in the 90's for PCs and just smartly ported to 8 bits computers. This is a real 8 bits designed solution which has been exactly dimensioned to best fit Oric's computers capabilities. All mathematics behind raycasting principle was rethought from scatch in order to match 8bits machine capabilities.
  • This library is 100% Oric and is insanely fast:
    Thank to this library, it is possible, with production line Oric, to provide 8bits retro-gamers with unprecedented game experience. No need for external GPUs or extension to provide the gamer with an astonishingly immersive and realistic 3D game experience. C64 and Apple II c gamers are getting jealous of Oric's owners !!
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Castoric : Raycasting on Oric computers

Post by Dbug »

I'm not sure who owns https://github.com/oric-software but it makes me sad to see all these projects cloned without any attribution: Oricium, Player Mym, Nyan Cat, etc...

I don't have any problem with people cloning repositories, if they need to do changes to make stuff work on their system, but please, pretty please, always start by giving attribution to the authors, not doing that is just not nice at all.

Regarding Castoric, the page is lacking screenshots, demos of how the whole thing looks like, and simple to use sample code.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Castoric : Raycasting on Oric computers

Post by xahmol »

Well done and congratulations on release!
Not the genre I can and like to build, but very curious what others can do with it.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Castoric : Raycasting on Oric computers

Post by Chema »

Great! I will have to give this a look in deep!
Dbug wrote: Sat Mar 20, 2021 2:20 pm I'm not sure who owns https://github.com/oric-software but it makes me sad to see all these projects cloned without any attribution: Oricium, Player Mym, Nyan Cat, etc...
I think Jede owns this one... maybe to patch things so they load with orix or something like that
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Castoric : Raycasting on Oric computers

Post by jbperin »

Sorry, I had forgotten to merge the develop branch into the main branch.

So now sources in main branch are up to date.

Sorry for the mistake.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Castoric : Raycasting on Oric computers

Post by Dbug »

The discussion about the CEO github has been split to a new topic: https://forum.defence-force.org/viewtop ... =23&t=2257

Sorry for the off-topic JiBé!
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Castoric : Raycasting on Oric computers

Post by jbperin »

Recent pushes on main branch:

- Bug fix in viewport resizing: Some lookup table were not properly generated when viewport size was changed.

- Configurable color for ground and sky: The color of sky and ground are now patchable so that it's possible to change the atmosphere of a scene by acting on the sky and ground color

- Generic collision detection: the ray casting engine now incorporates a function which deals with collision detection based on scene data. The game developpers is provided with a function isInWall(X, Y) which indicates if a position is occupied by a wall or not and it is based on current scene data (if walls move along time, the collision detection adapts at each frame :-)).

I thought that such a brut force approach would badly affect the performance but it turns out that it is not so that perceptible.
Oric computer are definitely some very powerful machines.

The following little screencap shows how it behaves.
teaser.gif
teaser.gif (366.58 KiB) Viewed 14198 times
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Castoric : Raycasting on Oric computers

Post by jbperin »

Hi all,

Just a quick post to inform that a prototype of items handling is available for the Castoric ray casting engine.

It is in a development branch named addSprites here : https://github.com/oric-software/castoric/tree/addSprites

It is not yet optimised and it will only be if some people feel interested with this feature.

The anim below was captured with overclock x2 to show what items are made for.
RayCastingWithItems.gif
RayCastingWithItems.gif (248.35 KiB) Viewed 12233 times
The key is an item that can be grabbed by going onto it.
Once the player has the key, it can open the door by pressing space while beeing close to the door.

Find below the demo tap file if you want to experiment.
Don't forget that it is work in progress (not optimisedd) and needs to use overclok x2 to better figure what it would once it is optimised.
proto.tap
(28.36 KiB) Downloaded 241 times
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Castoric : Raycasting on Oric computers

Post by Dbug »

Just tried the demo you sent me, looking good :)

Two things I noticed:

- You are still clearing the entire column to draw the background before you actually draw the walls, which is why we see these refreshing artifacts, which also means that you write the entire hires screen twice. My suggestion is still the same: Don't draw the background, instead just draw the wall, and fill up the top and bottom of the column if needed, this will look better, and be a tad faster as well :)

- The fish-eye effect is almost gone, except when you are just in front of walls (or close to corners) in which case it bends a lot, to the point it's not even recognizable as a wall anymore (noticed that when I moved to the "door" to open it with the key).
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Castoric : Raycasting on Oric computers

Post by jbperin »

Dbug wrote: Sat Oct 16, 2021 10:48 am - You are still clearing the entire column to draw the background before you actually draw the walls,
Yes .. you're right .. but I'm not sure it is so easy to avoid that because I work with "half-columns".
I clear columns but I write "half-columns"..
The best thing would to use the principle that you had used in your raycasting code here:
https://forum.defence-force.org/viewtop ... 985#p16985

where you use a routine with varying entry point depending on the height of wall.
But I wonder how it could be done in the context of castoric.

The routine that clear a column is here:
https://github.com/oric-software/castor ... column_s.s

Do you have an idea of how to clean only the part of the column that's not going to be used by wall ?
Dbug wrote: Sat Oct 16, 2021 10:48 am - The fish-eye effect is almost gone, except when you are just in front of walls
Once again you're totally right.
And the most worrying is that I don't know how to fix this issue. Except by preventing the player from going too close from the wall.
In this demo I use a generic collision detection mecanism that comes with the raycasting engine.
Castoric can check if a point (x,y) belongs to a wall of its list.
If the developer creates his own detection collision function, he can prevent the player from getting too close from the wall and thus avoid this problem.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Castoric : Raycasting on Oric computers

Post by Dbug »

I was thinking about that last night.

A possibility could be to use a single column back-buffer, render the background in it, then render the walls, then render the sections of sprites, and finally copy all that to the screen, that would be enough to avoid all the flickering problems.

Obviously there are two possible formats for the back-buffer:
- Like the screen, with all the fancy RGB interleaving
- One third of the screen, with only the color value of the big pixels

The advantage of using color values, is that instead of having 200 entries you can just use one third, so you only have 66 bytes to write to paint the background, the raycaster logic become a lot easier since all you have to write are the actual colors from the texture instead of having to do the RGB split at the same time, and same thing for the sprites.

Then you can use an optimized "column to screen" which generate the proper RGB patterns to the hires screen.
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Castoric : Raycasting on Oric computers

Post by jbperin »

Dbug wrote: Tue Oct 19, 2021 12:08 pm I was thinking about that last night.

A possibility could be to use a single column back-buffer, render the background in it, then render the walls, then render the sections of sprites, and finally copy all that to the screen, that would be enough to avoid all the flickering problems.
This is actually a very smart idea💡.
I don't think that sprites could be integrated that way because the rendering is somewhat different. But for walls and background, that definitely makes sense.
The only point is that I fear it will go a bit slower because of the intermediary buffer to deal with. However the rendering quality without flickering would be a nice compensation.
For now, I prefer to save some cpu because I would like to add some cpu consuming activities over the rendering. So I won't do this enhancement at first. But I shall keep it in mind for later improvement. And I thank you for this suggestion. You've already given me so much good ideas as I was making this raycasting engine. Just one more :D

PS: Of course, if you offer to implement your idea in a dedicated git branch, this would definitely help to make this very smart idea become true. And it would help the Oric community to have one of the best textured 3d render engine available on 6502 based machine.
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Castoric : Raycasting on Oric computers

Post by jbperin »

Dbug wrote: Tue Oct 19, 2021 12:08 pm A possibility could be to use a single column back-buffer, render the background in it, then render the walls, then render the sections of sprites, and finally copy all that to the screen, that would be enough to avoid all the flickering problems.
That's definitely a good idea.

My recent works on castoric made me realise that :
  • It is possible to add sprite handling without altering too much (in noticeable way) the frame rate.
  • the flickering effect is really repellent as soon as we have mooving NPC (Non Player Characters) that implies permanent refresh of the display.
The following gif shows how disastrous it is not to have used this column buffer
MVocidFullGame.gif
MVocidFullGame.gif (707.27 KiB) Viewed 10931 times
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Castoric : Raycasting on Oric computers

Post by jbperin »

Dbug wrote: Tue Oct 19, 2021 12:08 pm I was thinking about that last night.

A possibility could be to use a single column back-buffer, render the background in it, then render the walls, then render the sections of sprites, and finally copy all that to the screen, that would be enough to avoid all the flickering problems.
I found a lazy way to make a dirty implementation of your great idea of a single column buffer for wall rendering (unfortunately not for sprite).

Results are shown in this little remake of the game M.Vocid
MrVocidWithAntiFlickerOnWall.tap
(36.21 KiB) Downloaded 120 times
It indeed solves flickering problems .. and that's cool :D
I'm now thinking of how I could use the same principle for sprite but it looks to be lots of deep rework.
Post Reply