Sega Saturn Development > General discussion about the Sega Saturn

Sega Basic Library 6.0

(1/2) > >>

XL2:
I think it's fair to say that SBL was really overlooked (except for some functions added in SGL as well).

But it is really interesting in that it includes the source code for everything it does.
It includes a sprite (polygon) library (under SPR), with processing using the SCU DSP for matrix transformation.
It's probably slower than SGL overall, but since the source code is included, I think it's very interesting.

Has anyone ever given it a good look?

I haven't found any demos for it.

The 3d part seems more complete than SGL even if it was slower in the end, so I think it's a good starting point.

Things like "inbetween polygons" fix the issue of duplicated vertices after a map subdivision (octree, bsp, grid, etc.), while just making use of the SCU DSP at all is something SGL didn't even bother doing (unlike the high-end games like Burning Rangers, Quake and Sonic R using it).

corvusd:
I think it is possible that there is something example code whit SCU-DSP transforms libraries. Some time ago, in segaextrem someone free to iso, whit a Sample games for SBL 1.1. This samples used intensely one SH2 and SCU-DSP for transform matrix coordinates. Inside the iso image, are code and libraries I remember. This afternoon when I return from work I try to look better inside.

In this post forum: https://segaxtreme.net/threads/sega-saturn-sample-by-sega.24264/

You are here! :)

XL2:
Yes, there is, also the full source code.
But the main issue is that it DMA the data to vram, causing interruptions for the vdp1. It's just faster to use a buffer and do it all on sh2 like SGL does.
Finding a good use for the scu dsp isn't easy, but lightning was the usual choice.

corvusd:
"Yes, there is, also the full source code."
Okay this is good! source code! :D

"But the main issue is that it DMA the data to vram, causing interruptions for the vdp1. It's just faster to use a buffer and do it all on sh2 like SGL does."
It's true, in another post you told me that.

"Finding a good use for the scu dsp isn't easy, but lightning was the usual choice."
It is not easy, not at all. I know. What is true, that well used can shoot performance. The case of the Sonic R is clear. Reaching the 1300 quads visible at 30 stable FPS. It is true that it also adjusts the types of primitives to use the VDP1 well. But the SCU-DSP is definitely doing work in this game. Not to mention that the engine is very good, with the use of the second SH2 to rasterize. Everything in assembler. If J. Burton shared the code it would be great! :)

20EnderDude20:
What’s stopping us from obtaining the source code from him?

Navigation

[0] Message Index

[#] Next page