Welcome, Guest!

Here are some links you may find helpful

Dreamcast Kamui Direct!

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
Last year I wrote a wrapper that enables modern PCs to a few old KAMUI demos, and promised to release the source as soon as I could. Today is that day - you may find it at https://github.com/sifting/kamuidirect.

I apologise that it took so long to release, but the past few months have been interesting to say the least. The code is not as tidy as I would like, so I beg forgiveness - it was written during what free time my previous job allowed me between the grueling 50-60 work weeks. A big shout out goes to @Sega Dreamcast Info for approaching me about this project in the first place. It would have not been done without him.

You will need premake5, direct3d9 and gcc to build the source. Clang should work as well, but I have not tested it.

As an aside, while writing this wrapper I realised that the Kallistios API doesn't support the PVR's on chip accumulation buffer - am I correct in this assertion? I saw no functionality for it when I looked over the source code. KOS seems to have support for it in the headers, so it should be quite possible to add the functionality if needed. It would enable homebrew developers to implementation a whole new class of effects on the DC if so - I believe it's how urban chaos and alone in the dark 4 managed to do shadowmapping, and also how raster managed to get quake3 running so well.
 

T_chan

Well-known member
Registered
Jun 6, 2019
80
64
18
AGName
T_chan
AG Join Date
Apr 13, 2008
Thanks for all the work, very impressive !

Concerning Kallistios & co: there are certainly improvements to be done & things to be added still.

In the past, I started & stopped building my own DC 3D engine several times (or a beginning of an engine you should call it),
but these days I've switched to try helping the bigger ongoing efforts.
For the moment I'm in the works of helping GLdc to add eg GL_TEXTURE_1D & to let nehe37 glut version compile as-is with kos & GLdc. Other things will probably follow.
I'm also cleaning & converting its examples so that they can be compiled with glut/..., for easy comparison between OpenGL on a pc & GLdc on DC.

I can only suggest to also have a look at GLdc & consider helping improving that, so that all efforts are concentrated on having the best /most complete possible graphical open source lib for the DC...

P.S: ALdc has a nice base, but I'm pretty sure it could also need some help :)
 
Last edited:

Anthony817

Well-known member
Community Contributor
Registered
Jun 2, 2019
415
563
93
AG Join Date
May 12, 2010
So this means it should be possible to get the Scud Race demo working on Dreamcast right?
 
  • Like
Reactions: Sifting

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
I can only suggest to also have a look at GLdc & consider helping improving that, so that all efforts are concentrated on having the best /most complete possible graphical open source lib for the DC...

P.S: ALdc has a nice base, but I'm pretty sure it could also need some help :)

I've done a lot of hacking AICA in the past - I feel the sound part of KOS is needing the most love - so I'll check it out!

GLdc is more interesting. I gave it a look over and it does not support the accumulation buffer either - which makes sense, as the documentation on it is poor, and I only managed to find one talk on it by Sega EU in files that were supplied to me.

a quick summary: the pvr has an on chip accumulation buffer, in addition to the basic color buffer. when you draw a polygon, you may specify which buffer it will be drawn into, as well as how two buffers should be combined to produce the result.

this may not seem that useful at first, but a practical application is doing lightmaps. right now the only way to do it is to draw the scene once as opaque polygons, then again with the lightmap textures as transparent polygons - this works, but forces the PVR to use its more expensive transparency pipeline. by using the accumulation buffer instead, you may redraw the scene twice as opaque polygons, letting you use the much more efficient pipeline. compare quake 3's performance against a homebrew port of quake for a rough idea of how much faster this method is. if you are a more clever, you may also implement real time shadow mapping, projection textures, decals and so on in an efficient manner. depending on your game you may not even need to dedicate vram to supporting transparent polygons at all!

this brings me to the caveat for us though - implementing support for it using an opengl style API is quite awkward. I know at least opengl 1.5 supported an accumulation buffer, but the API for it is different from how the PVR expects it. the best way might be through using some custom extensions? I'm unsure. my personal feelings are that opengl is a poor fit for the hardware. a direct3d like API would be better, as much as it pains me to say!

So this means it should be possible to get the Scud Race demo working on Dreamcast right?
Unfortunately, no. It means we can get it running on PC though. Currently the demo that I have crashes mysteriously, so some part of the API is probably missing, or needs to be implemented more strictly.
 
  • Like
Reactions: Anthony817

T_chan

Well-known member
Registered
Jun 6, 2019
80
64
18
AGName
T_chan
AG Join Date
Apr 13, 2008
a direct3d like API would be better, as much as it pains me to say!
That made me smile :)
Did some D3D back in the days. I don't want to ever do that again :)

Extensions are probably indeed the way to go then, cfr. Kazade's documentation:
"The aim is to implement as much of OpenGL 1.2 as possible, and to add additional features via extensions."
"Things I'd like to do: <...> Define an extension for modifier volumes"

Kazade, the main author of Simulant/GLdc/Aldc is quite reactive on twitter (@kazade) if you have any questions

I'm pretty sure there are also other things lesser known that need implementation, eg I think an eternity ago I played with non-square textures on the DC.
 
  • Like
Reactions: Sifting

Anthony817

Well-known member
Community Contributor
Registered
Jun 2, 2019
415
563
93
AG Join Date
May 12, 2010
Unfortunately, no. It means we can get it running on PC though. Currently the demo that I have crashes mysteriously, so some part of the API is probably missing, or needs to be implemented more strictly.

Ah, I originally didn't think it would be possible but your talk about source code made my heart skip a beat lol. The PVR was only slightly like 25% of the final PVR capabilities on DC for the original GPU test card so I was doubtful.
 
  • Like
Reactions: Sifting

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
Did some D3D back in the days. I don't want to ever do that again :)
I'm not a fan either, even though it is 'industry standard'. I only mentioned it because windows CE mapped some ancient d3d version on top of the pvr - d3d6 I think? In general the KAMUI api is similar to d3d as well. something like glide would be fine too, or power's own api they had for a while. the biggest difference is kamui is designed around tristrips, to something of an awkward effect.

I believe the square texture thing is a limitation of the current pvr texture tools. I think most (all?) of them just reimplement the same code from the one in kos. there's nothing in the hardware that should prevent it as far as I know.

this forum is the only social media account that I have, unfortunately!


Ah, I originally didn't think it would be possible but your talk about source code made my heart skip a beat lol. The PVR was only slightly like 25% of the final PVR capabilities on DC for the original GPU test card so I was doubtful.
that doesn't surprise me. there were so many weird discrepancies that I kept seeing between DC hardware and sdks and the test stuff! you know though, seeing all this stuff about decompiled mario and zelda games recently in the news, it should be possible to do the same thing for the PC scud demo, then port the decompiled code over to KOS!
 
  • Like
Reactions: Anthony817

Anthony817

Well-known member
Community Contributor
Registered
Jun 2, 2019
415
563
93
AG Join Date
May 12, 2010
Yeah, I mean honestly there should be anough here to at least attempt to port it. Since the wrapper is trying to make it convert for modern hardware, I wonder if a fully native port could be possible. I mean having the source is a huge piece of the puzzle, so theoretically I think we could be much closer to actually seeing this thing run natively on Dreamcast than we have before. And who knows, maybe there is enough in the source to get the cars controllable too? I know that sounds like a long shot, but stranger things have happened.

And yeah it was DirectX 6 that the Dreamcast used for Windows CE ported games.
 
  • Like
Reactions: Sifting

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
Yeah, I mean honestly there should be anough here to at least attempt to port it. Since the wrapper is trying to make it convert for modern hardware, I wonder if a fully native port could be possible. I mean having the source is a huge piece of the puzzle, so theoretically I think we could be much closer to actually seeing this thing run natively on Dreamcast than we have before. And who knows, maybe there is enough in the source to get the cars controllable too? I know that sounds like a long shot, but stranger things have happened.

And yeah it was DirectX 6 that the Dreamcast used for Windows CE ported games.
I think now that laurent has released the demos, yes. someone would have to run the exe through IDA pro, ghidra, or some other debugger capable of decompiling assembly into C code, once they have that it's a matter of clean up and setting it up to use kos functions instead of katana stuff. compared to a full retail game this should be relatively easy for someone with a bit of motivation and time. the assets and models sit in the same folder as the exe, if I recall correctly. the textures are the usual pvr format, and the models are text files, I believe?
 
  • Like
Reactions: Anthony817

T_chan

Well-known member
Registered
Jun 6, 2019
80
64
18
AGName
T_chan
AG Join Date
Apr 13, 2008
KAMUI api is similar to d3d as well. something like glide would be fine too, or power's own api they had for a while.

The biggest question would be... who would use (just) that ?

That's also a mindset change I had, instead of focusing on DC, I'm doing things first on Linux (glut/glfw/...) nowadays.
And once I have something that works ok, I'm trying to have it work on DC.
Gets me to a result much faster.

So I'd recommend a solution that's not 100% DC... even if that means an extra layer...
 

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
The biggest question would be... who would use (just) that ?

So I'd recommend a solution that's not 100% DC... even if that means an extra layer...
Valid point! the idea that I've been toying with is a new api that runs native on DC, but on PC is backed by opengl - to make programming easier. it would be a ton of work though, and realistically the opengl api is good enough for most people. however, for anyone who really wants to get the most out of the system, it would be the way to go
 
  • Like
Reactions: FamilyGuy

T_chan

Well-known member
Registered
Jun 6, 2019
80
64
18
AGName
T_chan
AG Join Date
Apr 13, 2008
It all depends on your interests, motivation & free time of course :)

If you like tinkering with super-low level hardware, creating a driver is fun... and extremely difficult :)

If your purpose is to make a game, the time spent on writing a new driver is time lost for building/improving the game... and the chances of not having a working game in the end is big (been there, done that... life as a student was a bliss... :))

The possibilities I see:
1) client app -> custom api -> native DC / opengl, or
2) client app -> well-used standard -> native DC / nothing (because the "well-used standard" already uses PC libs & drivers)

1) is not for me anymore...
2) makes porting existing things super-easy... it's more motivating to be able to port a full game quickly, than to have to rewrite them to make them work on the custom api
Disadvantage is of course that it's not 100% optimized for the DC... but if really needed, this can always be achieved by conditional compilation for that specific part.

Another hybrid possibility, would be eg an extra back-end for GLdc for example.
It currently has kospvr & software as back-ends, you could imagine a 3rd one that bypasses kos.
That would cut off a lot of development time, and allows to profit from all the current & future work done in eg the examples/... (still not an easy task though...)

PS: to be clear, I'm not trying to demotivate you, on the contrary :)
Just talking about my mistakes/personal experiences :)
 
  • Like
Reactions: Sifting

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
yeah, I understand where you are coming from. my thoughts are the same - I'm grateful for the opengl support that we have, since as you pointed out, it's a well understood standard, and it makes porting preexisting code way easier. where I differ is I lean more toward drivers than games - even my job now is writing 'close to the metal' software. I would also like to emphasise the point you raised too, for anyone else who might be reading this with similar ideas - it's really only possible to either write a driver, or a game - you can't do both at the same time! it's a great way to end up in burn out land!

I think the ideal situation would to be to have both opengl, and a new API along the lines I wrote above. that way we keep all the benefits of having a standard api, as well as the efficiency of a custom api designed for the hardware - but this is all just a fun idea for me at the moment. I have way too many things that need my time before I could commit to a project like this.
 
  • Like
Reactions: T_chan

T_chan

Well-known member
Registered
Jun 6, 2019
80
64
18
AGName
T_chan
AG Join Date
Apr 13, 2008
I think you were also thinking about a 3D skinning and animation library ?

Are you thinking about a full custom one, or also something based on some specific standard ?
 
  • Like
Reactions: Sifting

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
I think you were also thinking about a 3D skinning and animation library ?

Are you thinking about a full custom one, or also something based on some specific standard ?

That is actually an idea I've toyed with before, though I'm unsure I've ever actually mentioned it. I have experience with animation and skinning, so it would be relatively easy for me to get something going. GLTF with some preprocessing tool, vertex weights, blending... maybe blend shapes? I suspect most people would just use like Half-Life quality features though... if there's an audience for it all?
 
  • Like
Reactions: T_chan

Make a donation