My 3D game engine

[MigDps]

Hello everyone, for some time I have been developing a small 3d engine for Dreamcast in my spare time, the initial idea was to develop a simple tool that would allow me to make a game for Dreamcast, I love this console and I was looking forward to develop something for it. But then I thought that maybe dedicating some more time, I could make a more advanced tool that other developers could use to make their homebrew 3d games.

I'm still not sure if this project will continue or not and there is still a lot of work to do, but I would like to know your opinion.
I know that the Dreamcast scene is still very much alive, but I also know that there are already very good alternatives like Simulant engine, that engine is really good and has been in development for a long time.
For now there is no downloadable version, (as I say there is still a lot of work to do) I would like to show you a little bit about the state of the current prototype version.






It uses blender as editor, you can export models, lamps, cameras, animations, armatures and materials (for now it doesn't support multitexture) the exporter converts tiangles to triangle strip whenever possible to make it more efficient, The engine is written in c++( and some assembly) and uses directly the pvr api to render.

At this moment, only supports infinite static lights, but obviously the idea is to support dynamic lights too.
It uses bone animations, up to 4 weights per vertex, I know that's too much for the poor Dreamcast, I'll probably cut it to 1 or 2 weights per vertex
As for the textures, for now it only supports png and jpg, but my idea is to add some more formats.
It also supports ttf fonts for texts.

At this moment there is no sound, nor vmu support.

I leave you a little demo of the scene you see in the images, there is really not much to do, just a funny animation, but maybe someone wants to try it. https://drive.google.com/file/d/1xBtyMy ... share_link


And that's all, I hope to read your opinions, any doubt, opinion or suggestion is welcome.

[Ian Robinson]

Hey really nice i did test it love to see more like the fact it's direct pvr api as well .. Yes supporting dtex and new format from TapamN would be ace.. Pvr vq makes a big change when using textures speed and memory use.

small test
https://streamable.com/cuqqp2

[MigDps]

Thanks for posting! Interested to see where this goes

[GyroVorbis]

My opinion? That it looks amazing! Keep up the good work!

[MigDps]

Thanks! And thanks for your work with Kos, without that it would not be possible to do these things, or at least it would be much more difficult.

[GyroVorbis]

OoOo btw, I just noticed you're one of our C++ developers. What revision of the language are you using? You going pretty hard on the stdlib? We should have all the way up to partial support for C++23 in there with everything minus std::filesystem working. If you run into any issues, please don't hesitate to file a bug on the github repo!

Give me a few to get my new capture card set up, and I'll check this baby out. The static lighting stuff looks damn good to me, and I wanna see it animate!

EDIT: Saw it! Looking damn good! What kind of stuff are you using ASM for in your engine? Is all rendering with the PVR API or are you going outside of it for some stuff? Since I started contributing to KOS, I've been kind of starting at the lowest-level and working my way up the driver stack, planning to eventually look into the PVR API and improvements that can be made on the graphics front.

[MigDps]

Thanks! that encourages me to continue with this project. I'm using c++11 for now, but it's good to know that I can also use some of the enhancements of c++ 23. and for stdlib, I don't think I'm using any functions other than atoi and atof now. I'm using ASM mostly for some heavier mathematical calculations, dot product cross product, interpolations, etc... stuff like that.

And for rendering, yes, I'm using only pvr, and plx for multiplying internal matrices and stuff like that. at first I started using opengl, I even made a small demo, https://youtu.be/VWXNiqCsh2w?si=qUkwB9PBryGB4aCS but it was a bit slow in some aspects and I didn't have much control to optimize it (for example lighting) so I switched to pvr directly. xD I'm still learning to use it, in fact clipping at the moment doesn't work very well, as you may have seen. The truth is that it's quite a challenge to try to squeeze all the juice out of this console, but it's really fun.

[Ian Robinson]

Looking forward to it might want to look at Dreamhal and TapamN's sh4lib for matrix abd other things like that..
https://github.com/ianmicheal/dreamhal/ ... sh4_math.h

[MigDps]

Oh, I didn't know about Dreamhal, it looks very interesting, I will definitely take a look at it. Thanks!

[rpk]

This looks awesome! The HarleQuest! engine also started life as using blender as an editor, it got us quite far before we moved on to a custom editor. Near plane tri strip clipping was a headache for us (and Simulant too), but it's doable. There's a paper in one of the Game Programming Gems books called "Model Space Triangle Strip Clipping" that should give you a head start!

I'd like to discuss your rendering implementation in more detail

[MigDps]

Oh my goodness, clipping is being a real nightmare, it would be much easier to work with triangles than with strips, I'm still a bit stuck on that part. I will certainly take a look at that paper you mentioned. Right now what I'm trying to do is to copy only the clipped triangle vertices and draw the resulting triangles at the end, but it still doesn't work very well.

By the way, congratulations for HarleQuest, it looks great! some time ago I saw a devlog in your youtube channel, it's an amazing work, also a multiplatform engine, wow!

[rpk]

Thanks, best of luck with your engine + project.

[MigDps]

Hi everyone, it's been a while xD Unfortunately I haven't had much free time to dedicate to this project, but there has been some progress.
For the near plane tri strip clipping problem, I managed to implement a more or less efficient algorithm (at least it's memory efficient)
I also improved the static lighting and added support for dynamic lighting, this last one was also a headache, it's really complicated to maintain the framerate using dynamic lighting. I still have to try to optimize that part a bit more. Actually both lighting and clipping are a big bottleneck in this system.
I have also added support for transparency models and optimized the animation system (now it only supports two weights per bone max).

I think that's all for now, here are some screenshots of a small scene I created to test the new changes.




You can also download the demo from here: https://drive.google.com/file/d/1JBA0_C ... sp=sharing (the controls are a bit bad xD the stick to move the camera, and the dpad to move arround )

[Ian Robinson]

Hi everyone, it's been a while xD Unfortunately I haven't had much free time to dedicate to this project, but there has been some progress.
For the near plane tri strip clipping problem, I managed to implement a more or less efficient algorithm (at least it's memory efficient)
I also improved the static lighting and added support for dynamic lighting, this last one was also a headache, it's really complicated to maintain the framerate using dynamic lighting. I still have to try to optimize that part a bit more. Actually both lighting and clipping are a big bottleneck in this system.
I have also added support for transparency models and optimized the animation system (now it only supports two weights per bone max).

I think that's all for now, here are some screenshots of a small scene I created to test the new changes.




You can also download the demo from here: https://drive.google.com/file/d/1r9MuWi ... drive_link (the controls are a bit bad xD the stick to move the camera, and the dpad to move arround )

Really nice progress!! link to download demo says access denied

[MigDps]

Really nice progress!! link to download demo says access denied

Sorry I had put the link incorrectly, you should be able to download it now.

[GyroVorbis]

Fantastic work as always, my friend! Love it!!! The lighting looks so good. That's something you don't see often enough in DC homebrew!

By the way, Ian tells me that you're running this KOS revision:

Code: Select all

[INFO]  SH4     KallistiOS Git revision v2.0.0-489-gfae2358:
[INFO]  SH4       Sun Jan 10 18:04:16 GMT 2021

I just wanted to see whether this is just whatever the version was back when you initially set up KOS and your toolchain or whether you had any issues or regressions with any later versions and chose this version specifically because it was working better for you? Wanted to make sure to capture any issues you may have run into so they don't get missed, if that is the case.

EDIT: So for lighting equations, are you implementing the full Phong equations including diffuse and specular? Is this in pure C and C++? Yes, from everyone I've spoken with, it's quite challenging and requires a very optimized T&L renderer stage to do dynamic lighting with 3D scenes. My own gamedev and engine project makes heavy use of dynamic lighting on PC, and I'm hoping to some day get that portion on DC, so I'm always interested in hearing about the low-level specifics as to what is required for decent framerates.

[MigDps]

Thanks, yes it seems that lighting is not used much in DC, but I'm starting to understand why, it's very expensive. Right now in this demo there is only one object with dynamic lighting, the sphere, it has 480 vertices and there are 4 points of light. With three simultaneous light points the fps already drops to 30 in this scene.
So I had to apply some "tricks" for example the illumination is not processed in all the frames and it is not calculated in all the vertices (this is provisional, it only looks good in some models) let's say that the illumination is calculated in some vertices and in others the value of the previous vertex is assigned... it is not a very good solution For now it only uses diffuse light.

About the sdk version, the truth is that it's the first version I installed, I think I haven't updated it since then, but it's about time to update I guess I use windows to develop on dreamcast so for convenience I used DreamSDK R2 to install everything, I guess that's the version it installed back then.

[GyroVorbis]

Thanks, yes it seems that lighting is not used much in DC, but I'm starting to understand why, it's very expensive. Right now in this demo there is only one object with dynamic lighting, the sphere, it has 480 vertices and there are 4 points of light. With three simultaneous light points the fps already drops to 30 in this scene.
So I had to apply some "tricks" for example the illumination is not processed in all the frames and it is not calculated in all the vertices (this is provisional, it only looks good in some models) let's say that the illumination is calculated in some vertices and in others the value of the previous vertex is assigned... it is not a very good solution For now it only uses diffuse light.

Wow, that's really interesting! Hey, man, if it works, it works! I would've believed you were doing full phong for every vertex.

About the sdk version, the truth is that it's the first version I installed, I think I haven't updated it since then, but it's about time to update I guess I use windows to develop on dreamcast so for convenience I used DreamSDK R2 to install everything, I guess that's the version it installed back then.

Ah, okay! No problem and no rush! There's a LOT of new stuff in KOS these days but not much has been added to the PVR API or on the graphics side. I just wanted to make sure you hadn't encountered some issue with a later version that we needed to address.

[Ian Robinson]

Thanks, yes it seems that lighting is not used much in DC, but I'm starting to understand why, it's very expensive. Right now in this demo there is only one object with dynamic lighting, the sphere, it has 480 vertices and there are 4 points of light. With three simultaneous light points the fps already drops to 30 in this scene.
So I had to apply some "tricks" for example the illumination is not processed in all the frames and it is not calculated in all the vertices (this is provisional, it only looks good in some models) let's say that the illumination is calculated in some vertices and in others the value of the previous vertex is assigned... it is not a very good solution For now it only uses diffuse light.

About the sdk version, the truth is that it's the first version I installed, I think I haven't updated it since then, but it's about time to update I guess I use windows to develop on dreamcast so for convenience I used DreamSDK R2 to install everything, I guess that's the version it installed back then.

Looks great the way you have done it.. I mean it looks like AAA game engine from the time. I know for fact sega asked for dynamic lighting on red dog and if it did not have it would been canned..

[MigDps]

Thanks! Wow, they were really strict! I remember that game, it had very good graphics, even the vehicles had shadows and the physics were very good too, in the end they more than fulfilled what Sega asked for.
About my engine, well, it still doesn't have a physics system, nor sound, nor game logic, probably when I add these things, it will be more difficult to reach that quality.