Raycasting interactive 3D demo

Want to discuss about Demos on the Oric, here you are !
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Raycasting interactive 3D demo

Post by jbperin »

Hi all,

Little interactive demo of forthcoming version of Castoric embedding the marvellous Rax game engine .. and the anti flicker mecanism suggested by Dbug.
CastoricNoFlicker.tap
(33.89 KiB) Downloaded 130 times
Last performance profiling shows an average 1.85 FPS

Please .. give feedback
User avatar
ibisum
Wing Commander
Posts: 1646
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Raycasting interactive 3D demo

Post by ibisum »

Its pretty cool, but the wipe is distracting. Is there some way you could make the wipe go in the direction of the keypress - like, LEFT = swipe left, etc.? Maybe there's something about the calculation that requires it, but I feel like the user experience would be better if the swipe was somehow associated with the direction key pressed ..
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Raycasting interactive 3D demo

Post by iss »

jbperin wrote: Thu Apr 07, 2022 6:17 pmPlease .. give feedback
It's cool and definitely performance is improved - I like it! :)

ibisum's idea for swipe is interesting and worth to try.
Just keep track of program size (so far: #0600 ... #8D78).
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Raycasting interactive 3D demo

Post by Chema »

Almost 2 fps is most impressive!

I imagine it would improve enormously if the render window were smaller. In any case, it is looking better and better.

Really nice!
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Raycasting interactive 3D demo

Post by jbperin »

Thank you all for your feedback

I'm very puzzled at the moment because I feel that the more I optimize performance and reduce flicker and the fatter the engine becomes.

For example, last performance optimisation on the antiflickering took almost 3 kb in mem !! :shock:

It consisted in changing this routine into this one. It's unroling the loop to avoid additions and comparison of the loop control.
It goes very faster but takes far more space in memory. :? So I don't know which strategy to follow

Especially because I have an alternate solution for the routine which is a compromise in term of performance / size ratio.

So it's very hard to make a choice.

I need to test on different viewport dimension to check how performance and size change accordingly.

For now, I stick to the full screen display in order to keep focus on the "worst case"
But, by reducing the viewport size, it is possible that performance will go higher and memory consumption go lower.

ibisum wrote: Thu Apr 07, 2022 6:45 pm Is there some way you could make the wipe go in the direction of the keypress
That would, for sure, be the best solution. Unfortunately, the design is not flexible enough to allow an easily implementation this idea. And it would be too much work to redesign the whole. I wish I had thought of that when I started working no castoric (message for next generation .. )
iss wrote: Thu Apr 07, 2022 7:02 pm Just keep track of program size (so far: #0600 ... #8D78).
That's a major point of concern at the moment.
I feel like I will end up with a very powerful 3D game engine that takes all the memory and let no space for the game itself :-(
Chema wrote: Thu Apr 07, 2022 7:14 pm I imagine it would improve enormously if the render window were smaller. In any case, it is looking better and better.
I hope you're right .. it's my only change to end up with something usable. :mrgreen:
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Raycasting interactive 3D demo

Post by Dbug »

Well, the obvious solution is to move to DSK format, get 16K more free memory, and you can dynamically load stuff when you need it, so you can have different maps, textures, the intro, etc... loaded from disk instead of having all in a single monolithic executable.
User avatar
ibisum
Wing Commander
Posts: 1646
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Raycasting interactive 3D demo

Post by ibisum »

Thanks for giving us your insight, jperin - this is a very exciting project from the perspective of us Oric fanboys. :) Still quite amazing to see this level of software on the Oric, to be honest.

I concur with DBug - why not a .DSK version? Seems sensible anyway - since it would open the door for much, much bigger levels/world design if its possible to load them from disk ..
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Raycasting interactive 3D demo

Post by Chema »

Yep, I was about to suggest using disk too :)

I think (Dbug is the expert in this area) that there is no way to prevent the code getting bigger and bigger as you try to make it faster. The usual tricks are using tables, unrolling loops, creating several specialized routines instead of one general with parameters, precompute values and store them in memory, etc. All of that consumes memory. Of course, in absence of a new algorithm that could reduce the complexity.

I also remember Dbug told me once: the most wasted memory is unused memory, so it's almost always better to expend it in optimizations, then deal with other matters (as long as you don't run out of it, that is).

The basic idea is try to move as little memory as possible, try to make as little calculations as possible. After that, there will come the small fine-grain tweaks with the assembly code.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Raycasting interactive 3D demo

Post by Dbug »

It also does not hurt to have numbers regarding what is the fastest possible code (even if it uses all the memory), if only to have an idea of the upper boundary that can be achieved. If it's still too slow in the best case scenario, it means other tricks have to be used, which in this particular case could be reducing the size of the display, or possibly display half of the lines and alternate on each frame, etc...
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Raycasting interactive 3D demo

Post by jbperin »

I admit that the .DSK is very convenient when it comes to create a game with lots of dynamically loadable content.

But, in my situation, there are a few cons that are not neglictable:
- I'm not doing a game, I'm doing a 3D game and render engine. And for sake of development, I find it useful to have some system routine available (such as printf, zap, hires, get, etc ...).
- I have no gear to read DSK file on my Oric (my Orix box is not up to date and can't read DSK :-( )
- On my PC, building a .TAP file is far faster than building a .DSK file .. and as I compile, build and execute very very often when I work on castoric, using DSK would lower my already poor productivity.

That being said, I must be aware that , if one day someone feel like using Castoric to create a game (don't break my dream), he will feel the need of using it in a .DSK game. So I must think of how to use Castoric in a .DSK context.

I must think of memory organisation. How to store things in a perfectly aligned way. What to put in the extra 16Ko.. what to keep in user code area..
So many questions to answer that I have no clue at all.

Thanks all for your remarks, advices and comments .
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Raycasting interactive 3D demo

Post by jbperin »

Chema wrote: Thu Apr 07, 2022 7:14 pm I imagine it would improve enormously if the render window were smaller. In any case, it is looking better and better.
I've just made a measurement on two different viewport sizing configuration:
  • with a 74*60 texels viewport, 34 697 bytes, 1.85 FPS
  • with a 48*32 texels viewport, 32 853 bytes, 3.36 FPS

But well .. that's only with two sprites in a basic scene only containing 5 walls. So .. not really relevant ..
Post Reply