Castoric : Raycasting on Oric computers

[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 !!

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

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

[Chema]

Great! I will have to give this a look in deep!

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

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

[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é!

[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 (366.58 KiB) Viewed 20917 times

[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 (248.35 KiB) Viewed 18952 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 580 times

[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).

[jbperin]

- 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 ?

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

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

[jbperin]

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

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.

[jbperin]

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 (707.27 KiB) Viewed 17650 times

[jbperin]

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 407 times

It indeed solves flickering problems .. and that's cool
I'm now thinking of how I could use the same principle for sprite but it looks to be lots of deep rework.

[jbperin]

Next version of castoric will contains a new projection function to use for hires graphics.
The goal is that the perspective matches as much as possible the one from the raycasting.

glcast.gif (190.48 KiB) Viewed 1169 times