Sega Saturn Development > Project announcement
Virtua Skimmer
XL2:
Would you mind showing me (if you can just do a short private youtube video or something as I'm not on my computer now)?
If the planes are single plane, I think they will get culled for more intense rotations, and that's a big problem.
ponut64:
https://youtu.be/M00oA1ZEKU0
This may not be conclusive but it was easy to do.
You know what, I'll just try and throw in something that really should break it if it works like we think it does. Give me a minute.
/e: Yep, as you expected, things get culled when they would be otherwised blocked in the models' rest position.
https://i.imgur.com/2JassMX.png?1
I'd guess some way of compressing the normals is important
There is probably a really good reason why the animations in Quake are like they are.
Hopefully we can at least prevent writing redundant textures.
corvusd:
--- Quote from: XL2 on May 17, 2018, 09:35:28 pm ---You can easily put one light source per model, but not more.
SGL can only register one source.
The way around this would be to not use SGL, or maybe it's possible to use offsets, but I don't know.
I might compute lights offline for static lights, which should allow much better colors.
Maybe you could then use the SCU DSP to calculate the additions/substraction on top of static lights, but I think it would be slow.
I already tried with colors, it's super easy.
For this demo, I'm using "semi white", but you can put any color you want.
It's already using the 2 CPUs. As soon as you call slPutPolygon, it will look to see if the slave is busy, and if not it will transfer the command so that the slave handles everything.
--- End quote ---
I know for you, the easy way right now is use the SGL. For 1 Light Dynamic the SGL is very well implemented.
But my questions was for this data extract from https://segaretro.org/Sega_Saturn/Technical_specifications#Graphics, for the theoretical maximum capacity for SS in this type of process:
DSP geometry processing: 188 MIPS (million instructions per second)
Fixed-point operations: 114 MOPS (million operations per second)
Additions: 85 million adds/sec
Multiplications: 85 million multiplies/sec
16-bit divisions: 5 million divides/sec
Geometry calculations: 114 MOPS fixed-point calculations
Vertex transformations: 2,400,000 vertices/sec
Polygon transformations: 1,800,000 polygons/sec
T&L flat lighting: 800,000 polygons/sec
T&L Gouraud lighting: 700,000 polygons/sec
Polygon rendering performance: Lighting
800,000 polygons/s: Flat shading, 32-pixel polygons
500,000 polygons/s: Flat shading, 50-pixel polygons
200,000 polygons/s: Gouraud shading, 32-pixel polygons
Texture mapping performance: Lighting
300,000 polygons/s: 32-texel textures
200,000 polygons/s: 70-texel textures
140,000 polygons/s: Gouraud shading, 32-texel textures
XL2:
The main issue with SCU DSP is that you need to DMA everything, wait for the dsp to complete the operation and then stop it, DMA the data back.
It really requires perfect syncronization else you just waste time waiting or DMAing little data.
Plus it's in assembly only...
XL2:
--- Quote from: ponut64 on May 18, 2018, 09:05:08 pm ---https://youtu.be/M00oA1ZEKU0
This may not be conclusive but it was easy to do.
You know what, I'll just try and throw in something that really should break it if it works like we think it does. Give me a minute.
/e: Yep, as you expected, things get culled when they would be otherwised blocked in the models' rest position.
https://i.imgur.com/2JassMX.png?1
I'd guess some way of compressing the normals is important
There is probably a really good reason why the animations in Quake are like they are.
Hopefully we can at least prevent writing redundant textures.
--- End quote ---
Textures are only stored once in memory using my tool. Plis they are 4 bits per pixel, so you really don't need to be worried as I'm sure you have a ton of VRAM left.
Even with Quake maps and 1000 textures I still have some VRAM left.
For the normals, you could also just use dual_plane for now, but that's not an option for me.
I will try to read more on the subject.
EDIT : Just looked at your video, it still looks quite smooth! If you don't use that many polygons, you can probably just use dual plane quads and keep the current implementation.
Navigation
[0] Message Index
[*] Previous page
Go to full version