Playing around with 3D in RB+

[Sporadic]

I just thought I would post a quick message on what I've been playing around with. Whenever I'm working on a big project (such as AstroStorm or Notoutrun) i always like to have a mini side project too as it serves as a nice break from the norm. This time i started tinkering with 3D in RB+. It's not much, just a cube but you gotta start somewhere.

 

I started with wireframe;

 

 

Then added backface culling, solid triangles and basic lighting.

 

There is a known issue: A rounding error exists which means after a while the cube shrinks. I know where it's happening i just haven't looked into correcting it.

 

Binaries attached too.

 

SporadicSoft 3D Cube in RB+ 040317.abs

SporadicSoft 3D Cube Solid in RB+ 130317.abs

[Zerosquare]

Is there a limit to what can be done in rB+? It just keeps getting better and better

[saboteur]

So RB+ Mercenary, Carrier Command etc is possible

 

I've never got my head around 3d math so would love to know the in's and out's of how this is done.

 

I'm assuming the backface culling adds extra slowdown as your having to do more steps ?

[saboteur]

Forgot to say - Excellent work

[+Stephen Moss]

I've never got my head around 3d math so would love to know the in's and out's of how this is done.

 

I'm assuming the backface culling adds extra slowdown as your having to do more steps ?

 

I may well be wrong but if it could implement the use if .J3D/.N3D models and their texture maps and provides the BASIC equivalent of the necessary 3D commands from the original Atari 3D examples then I think a lot of that would be taken care if for you and all you would basically need to concentrate on is X,Y,Z and rotational position of the 3D objects.

 

I have not yet had the opportunity to play with RB+ (too many other things on the go) although from what I have seen of manuals and work produced I so far think it was created more as a 2D powerhouse than for producing 3D although I would love it if it could support J3D &/or N3D models as I am much better at modelling than drawing sprites.

Edited March 14, 2017 by Stephen Moss

[ggn]

First of all: kudos to sporadic! I did have a vague idea what he was up to and slightly extended rb+ for this, but I was really surprised when I saw the cube spinning .

 

Now, about the whole 3D thing: the cube is calculated and drawn from Basic (with the blitter helping out with the draws). The GPU is not involved at all here, with the exception of making the object lists busywork for us (although hey, maybe sporadic could add some sweet screen shakes in sync with music ). And this is the main point: the core rb+ doesn't do objects, or animations, or music playing, or joypad reading. It relies on other people's code to do that. Raptor is used for the graphic bits, U-235 and Zerosquare's routines are used for audio and pads, gcc 4.6.4 is used to compile the final code into binary executable... the list goes on and on.

 

Adding "the use if .J3D/.N3D models and their texture maps" would imply that somehow the Atari reference rasteriser is somehow added into rb+. From what I understand, that code is a mix of 68000 and GPU code. Since raptor occupies the GPU, someone would have to make raptor work alongside with Atari's code (provided there's enough GPU ram for both of them to coexist). Since that's very unlikely, raptor would have to be removed and Atari's code used instead. Which is not impossible to be honest, but rb+ would have to be made aware of the fact. Somehow the basic code has to interface with the surrounding libraries, which means see how assets can be imported, how Atari's code can be made to interface with Basic, and probably a ton more stuff I can't think of at the moment.

 

The thing is though, from what I hear, Atari's rasteriser is on the slow side - so would anyone actually want to use this? The last thing I'd do is put up hours and hours of work with 0 net result (i.e. everyone seeing that it's slow and not bothering with it. Or simply not bothering with it at all).

 

rb+ is really not my main priority, not by a long shot. But when people come with mature projects asking how can we speed them up I will put up the effort to explain and suggest things. Coming back to the cube, it took me and sporadic (and a certain Scot who likes to port doom engines on 030) a few hours of playing around with ideas until we could work around gcc's slow multiplications. I would not have done anything if sporadic just asked me to do this because it would have been "good to have". I do expect to see some progress first - rb+ driven is driven by its users, not feature creep .

 

So to wrap this up, if people want 3D in rb+ they'd have to show me something more than promises .

[+CyranoJ]

Just to add:

• I do plan on adding the matrix math and more powerful blitter control into RAPTOR API, and this will (eventually) feed down into rB+, I guess, which should provide a pretty significant speed boost for this and other blitter reliant applications.
• rB+ is nowhere near my top priority, and, other than the API, I have very little input into it.
• RAPTOR API is not near the top of my current priority lists - there *is* a new version (and, actually, rB+ is using a more recent version than the current API release) but I have not packaged it and don't know when I will get around to it either.
• I absolutely LOVE what I have seen people do with this - and with that, I mean everyone who has had a go. I am really looking forward to see what else people make with this!

Now, carry on and keep dropping nice surprises like 3D in basic!

 

For a package that ggn and myself joked about making and threw together almost as a laugh, this has blown both of us completely away! I know ggn hates basic_functions.c, and I'm super lazy about RAPTOR.INC - so the fact that this even runs makes us giggle.

[Sporadic]

Lets not get ahead of ourselves. Its a cube

 

Having said that, i do want to keep playing around and see what's possible. It's not really using any lookup tables and everything is calculated in real time. I'm sure optimisations can be made.

 

Thank you ggn for the help and new functions, appreciated as always. The good thing about doing something like this is that you learn new things and how stuff works.

 

CyranoJ, if this was truly thrown together as you say then what a throw it was I couldn't be having more fun deving on the Jaguar.

 

I'm assuming the backface culling adds extra slowdown as your having to do more steps ?

This depends how you look at it and where slowdown might occur. Yes it adds a bit of extra computation for each triangle but at the same time, it's drawing roughly half the amount of triangles it would otherwise be drawing, so there's less calculations done after the culling and less stuff being drawn to the screen. The net result should be that it's faster. Also, i'm using the result of the culling calculation to perform the lighting effect and no extra cost so it's being used for two things

 

Thanks for the responses, if I make any other progress i'll post it here.

[saboteur]

Well, this has made me stop procrastinating and I just installed RB+ on my proper dev machine.

 

Gonna work my way through the examples this week and try and match that against the OP thread.

 

And then... well who knows - I fancy doing and old school flip screen platformer a la manic miner.

 

In my case it's not the coding I have a problem with ( though i'm sure i'll manage to cock it up ) it's the graphic generation/conversion and OP list that has me shaking in my boots

 

But i guess i'll not know until I try.

Edited March 14, 2017 by saboteur

[ggn]

 

In my case it's not the coding I have a problem with ( though i'm sure i'll manage to cock it up ) it's the graphic generation/conversion and OP list that has me shaking in my boots

 

 

rb+ has you covered more or less. If you feed it with bmp files of the correct bit depth, it'll auto convert and import them for you, ready to be included in raptor object lists.

[+CyranoJ]

And then... well who knows - I fancy doing and old school flip screen platformer a la manic miner.

 

Hell yes!

[sh3-rg]

Thanks for the responses, if I make any other progress i'll post it here.

 

Amazing stuff, Rik, looking forward to seeing more goodies like this, your side projects are my favourites

[Shamus]

Just wanted to chime in regarding Atari's 3D rasterizer: it's garbage.Currently doesn't work in VJ, and it's a pig on real hardware. It's a curiosity at best, waste of time at worst.

demo.cof.zip

Edited March 16, 2017 by Shamus

[Fredifredo]

Hover Strike sources ( aka TANK dev name ) use C ...

 

edit : not for the 3D engine ...

Edited March 16, 2017 by Fredifredo