Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - corvusd

Pages: [1] 2 3 ... 5
1
General discussion about the Sega Saturn / Re: Sega Basic Library 6.0
« on: August 14, 2018, 11:59:10 pm »
Unless you want to hack his account and steal his code, he won't share Sonic R's code, Sega owns it.
The scu dsp is super hard because of all the restrictions around it, it has its own assembly language, you need to dma data to its own ram, it has no division unit, you need to either scu dma data somewhere or fetch it with the sh2, it has very little ram and it's running at half the clock rate of the sh2. It's probably faster 99% of the time to just use the sh2.

To corvusd, the quad count isn't that relevant. A draw command takes something like 70 cycles minimum. The rest depends on the texture size, the drawn pixels, the color calculation functions used, etc.
So lots of small polygons won't hurt performances that much, except maybe on the cpu side.
The key is to reduce overdraw.
Sonic R used a pvs, so it didn't eliminate overdraw but that's fast enough.
Slavedriver engine games reduced the overdraw to a minimum, but it came at heavy cost for the cpu, with a complex portal system.
In Sonic Z-Treme, I still don't have a pvs so there is lot of overdraw, but thanks to the mipmapping and lod, it's still very fast, drawing something like 1000 quads at 30 fps in some situations. In some scenes, the quad count is low (300-400), but so many quads are merged that it would otherwise be maybe 1200 quads.
But the overdraw is still what's preventing even more polygons on screen, more than the cpu.
So using the scu dsp wouldn't have such an impact right now.

Good! this value "70 cycles" is my nightmare. I can not understand this value and the rest of formula from SoE Tutorial. In same way, if it is possible to make a formula, it is possible to calculate the max data to VDP1. Really I think that is very difficult. For SS, but equal for PSX. I am convinced, to the point that the only thing that helped to optimize your GPU in PSX was the Performance Analyzer, which extracts and shows a great amount of data, for better all the data flow in the system and focus in draw GPU state.

EDIT:
About SCU-DSP
Quote
SEGA SATURN TECHNICAL BULLETIN #SOA-10
Saturn SCU DSP Demonstration Program

The DSP sample program performs 3D point transformation, i.e. it multiplies a 4x3
homogeneous matrix by an arbitrary list of 3-element vectors (the fourth element of each
vector is presumed to be 1). The program attempts to take full advantage of the
parallelism built into the DSP, and the transformation matrix, the input points, and the
output points are transferred using the SCU’s DMA capability. The sample code
performs point transformations roughly a third faster than the equivalent code written in
SH2 assembly language
, even allowing for the time spent transferring data into and out of
the DSP’s memory. It is hoped that this program is general and useful enough to be used
in an actual development environment.

Quote
SEGA SATURN TECHNICAL BULLETIN #SOA- 8
Saturn SCU DSP Tutorial



1.2 Advantages of Using the DSP
The DSP is a highly specialized processor intended to efficiently calculate sums of
products, as when performing matrix and vector calculations such as 3D point
transformations or lighting calculations. When performing the sorts of tasks for which it
was designed, the DSP can be faster than the SH2, because it can load operands for one
calculation, perform a second calculation, and store the results of a third calculation in
parallel.
It can also perform a 32x32 multiply, yielding a 48-bit result, in a single cycle.
The DSP gains an additional advantage when performing fixed-point calculations, since,
when it stores its results to its data RAM, it can store either the lower or the upper 32 bits
of its 48-bit accumulator, whereas the SH2 must take time to explicitly reformat the
results of fixed-point calculations by using the “xtrct” instruction.

1.3 Disadvantages of Using the DSP
The DSP runs at half the clock speed of the SH2, so, while the DSP can multiply in a
single cycle, that cycle is twice as long as one of the SH2’s cycles.
The DSP’s doesn’t have much memory, and the memory it does have is not mapped onto
the system bus, which means that the DSP must continually take time to copy its data
between its own data RAM and the SH2’s work RAM.
The DSP is difficult to program. A routine that could be coded in SH2 assembly
language in half an hour might take half a day to write, debug, and fully optimize on the
DSP


6. Parallelism
The DSP’s two main functional units (the ALU and the multiplier) can operate in
parallel, as can its four buses and its four banks of data RAM. As a result, the DSP can
execute up to six instructions in a single cycle,
including any or all of the following: one
ALU instruction, an instruction to load the RX or P register, the MOV MUL, P
instruction, an instruction to load the RY register or the accumulator, either the MOV
ALU, A instruction or the CLR A instruction, and a D1-bus instruction. These are the
only instructions that can be used in parallel with each other; other instructions require a
cycle of their very own.

All the rest Totally agree whit you. But if we unload the SH2 from calculations that the SCU-DSP can do asynchronously. We could use the SH2 slave with the J. Burton code to reduce the overdraw. As? Part of my idea is the following algorithm sketch. According to those criteria:

Starting data for my hypothesis:
Taking as a basis the Sonic R (or your project) in this case I have the data already:
1 Player: 1.266max@30 = 37.980
2 player Splitscreen: 1.374 max @ 30 = 41.220
 
Of which (Rounded data):
Gouraud Distorted Sprite = 1000
  a) Illuminated = 500
  b) Pre-calculated = 500
Flat Distorted Sprite = 200
Sprite Scaled = 100

Requirements:
- Using the raster software by J. Burton. Rasterized part of the "distorted sprites". Converting them into Normal Sprites with the exact pixels. Like PSX. In my estimate up to 200 quads, 400 triangles. According to the R of the initial screen.
- HSS always activated for distorted sprites or scaled sprites = or greater than 32x32
- Do not use textures + large 64x64. Or the minimum ones on the screen.
- Using Pre-clipping Enabled for quads outside the System Clipping Coordinates.
- Using Pre-clipping Disable for quads that are always inside, whole or for the most part, of the System Clipping Coordinates.
- User Clipping Coordinates always.
- Use User Local Clipping if zones such as: Interiors, houses, tunnels, caves ... etc ..
- Use End Code in textures with mascara or transparent more
- Use Transparent Pixel only for distorted sprites with texture
- Using ECD and SPD is the most optimal, but less colors.

Now, we follow a typical Viewing frustum Clipping case:
A) Near Clipping Zone:
1) If the quad forms an angle between 90 and 45deg.
  a) Draw with VDP1 without mipmap.
  b) Gouraud is drawn.

2) If the quad forms an angle.less than 45deg with the camera view.
  a) Draw with VDP1 with level 2 of mip-map.
  b) Gouraud is drawn.

3) If the quad forms an angle.less than 30deg with the view camera:
 a) Change the texture quad to a flat polygon whit a precalculated base color(representative of the entire texture)
 b) Gouraud is not drawn.

B) Medium Clipping Zone:
1) If the quad forms an angle between 90 and 45.
 a) Draw with VDP1 change to mipmap Level 2.
 b) Gouraud is drawn.

2) If the quad forms an angle less than 45deg with the camera view.
 a) Draw with VDP1 change to mipmap Level 2.
 b) Gouraud is not drawn. Flat Lighing(pallete CLUT levels luminance).
 c) Change the texture quad to a flat polygon whit a precalculated base color(representative of the entire texture)

3) If the quad forms an angle.less than 30deg with the view camera:
 a) Raster SH2 slave with precalculated flat color(representative of the entire texture).
 b) Gouraud is not drawn. No lighting

C) Far Clipping Zone:
1) If the quad forms an angle between 90 and 45.
  a) Draw with VDP1 change to a flat polygon whit a precalculated base color(representative of the entire texture)
  b) Gouraud is not drawn. Flat Lighing(pallete CLUT levels luminance).

2) If the quad forms an angle less than 45deg with the camera view.
 a) Raster SH2 slave with precalculated flat color(representative of the entire texture).
 b) Gouraud is not drawn. No lighting.

3) If the quad forms an angle.less than 30deg with the view camera:
 a) Raster SH2 slave with precalculated flat color(representative of the entire texture).
 b) Gouraud is not drawn. No lighting.

I am convinced that we can reach the limit of optimizing the problem of overdraw.

And this is just an idea. There is still margin.

Greetings!

2
General discussion about the Sega Saturn / Re: Sega Basic Library 6.0
« on: August 14, 2018, 07:41:28 pm »
Well... I think the copyright. It possible that it not are under property of TT only. Maybe also of SEGA. Wherever, J. Burton not are all TT... and this code is very valuable. If you want try to contact whit him and try to that He share to the community. Let Go! :D

3
General discussion about the Sega Saturn / Re: Sega Basic Library 6.0
« on: August 14, 2018, 07:01:05 pm »
"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! :)

4
General discussion about the Sega Saturn / Re: Sega Basic Library 6.0
« on: August 14, 2018, 02:29:41 pm »
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! :)

5
Very good ideas! Are you think about How make the change of shape when the camera rotate above the shadow?

6
So, I've seen an Atari Jaguar game, Supercross 3d, and it has a billboard that shows the screen on it. Is there a way to do that on the Saturn?

In "theory" yes. A few games make a render-to-texture from VDP1 framebuffer, CPU or both VDPs... but only whit static images. Only can make a speculation about it. Is possible this feature would be to expensive to the graphic+cpu Saturn pipeline. Are be to many jumps of type of buffer, type of data... etc... I mean, is possible make it, but whit a very very slow result.

The most similar case, is Tempest 2000. This is a direct port from Jaguar to Saturn. It have in main logo screen a similar effect in the title. A render and blur in the logo. In Saturn go very low FPS, maybe 10/8FPS in Jaguar run quite well. In this case, is a render-to-texture over VDP2 layer from CPU render.

Greetings!

7
No. I explain in my post:
http://www.davidgamizjimenez.com/inpostivegames/sega-saturn-to-the-limit-i/ ->  1.1 Triangle vs Quadrangle – EXTRA Ball: UV Mapping

Well, I try to explain. XD

8
Hello

Let's see. Your idea is interesting.

The problem is that you raise it is practically programming a rendering engine of polygons. Because from somewhere the mask texture has to come out.

What you propose is practically what was done for Sonic R. Maybe in a more original way. But in the end, as I say, something must draw those masks, those "triangles"

At the UV point you can see it: http://www.davidgamizjimenez.com/inpostivegames/sega-saturn-to-the-limit-i/ ->  1.1 Triangle vs Quadrangle – EXTRA Ball: UV Mapping

Regards,

9
Sorry Jorhlok. I totally pass your great contribution!

It is a great project! You have thought about the possibility of adding your real preview of the graphics of the VDP1 to the work of @XL2 to export 3D geometry to SS from Blender 3D.

The possibility of creating 3D graphics in a tool with Blender, and really being able to visualize how the graphics will look. In addition to being able to later export the data to a format as optimized to the machine. It is one of the tasks that remained pending in the past. There were no plugins, or at least I have not seen for 3DS max or others for SS graphics. However for PSX there were many. This facilitated and potentiated taking advantage of both the possibilities of the artist and the machine.

What do you think?

10
General Jo Engine Help / Re: Making a 'corrected texture' on a triangle.
« on: August 03, 2018, 07:14:26 pm »
Ponut is right about that solution, but use caution as even if it has invisible pixels, the Saturn still needs to "render" them, so it can make things way slower quickly. The way around that is to use end codes, which none of my tools support. The other solution is to pre-distort the texture, but again I don't know much about it.

This assault me this dubt:
Is need it config register=0 Trasparent pixel disable, to avoid draw pixels in a texture/pattern used only to make a mask?
Or can be used End code draw in texture/pattern pixel data to avoid draw this pixels?
Or need both of then "activated"
For CC VDP1 is need both activated. But if you only need a mask texture... what option is the best to gain maxium time or use less cycles?
Wherever, I undestand that is necesary generate the data(pixel data or command table data) for this features to avoid waste cycles in draw VDP1.

The End code tells the VDP1 to stop processing that line, while transparent pixel just writes nothing to the framebuffer.
So if you have lots of transparent pixels, the processing speed is the same as an image full of colored pixels.

But the End code just tells the VDP1 to stop processing the line, so it's faster to render.
You need 2 end codes to stop processing a line, so the way to do it is to put one in front of your first colored pixel on each line and one right after your last colored pixel.

With clut sprites, you need to waste 2 colors for the transparent pixel and the end code.

Then, not it is possible gain speed or not "process" the transparent pixel, some way? I understand, that it save cycles in the fill pixels in the framebuffer? It not write nothing not would have cost... but in the same way to process texels data no?

11
General Jo Engine Help / Re: Making a 'corrected texture' on a triangle.
« on: August 03, 2018, 05:36:56 pm »
Ponut is right about that solution, but use caution as even if it has invisible pixels, the Saturn still needs to "render" them, so it can make things way slower quickly. The way around that is to use end codes, which none of my tools support. The other solution is to pre-distort the texture, but again I don't know much about it.

This days assault me this dubt:
Is need it config register=0 Trasparent pixel disable, to avoid draw pixels in a texture/pattern used only to make a mask?
Or can be used End code draw in texture/pattern pixel data to avoid draw this pixels?
Or need both of then "activated"
For CC VDP1 is need both activated. But if you only need a mask texture... what option is the best to gain maxium time or use less cycles?
Wherever, I undestand that is necesary generate the data(pixel data or command table data) for this features to avoid waste cycles in draw VDP1.

12
Hi community!

Thanks for the feedback! I will hope the next part more interesting. SCU use and polycount. :D

I have some minor corrections and update to the first part. I added this paragraph:
"By putting specific numbers in the situation. We would be talking about 35.65% of the study that I have done have some kind of lighting. 27.13% of the games have lighting with a source similar to that of PSX. And equal or superior to PSX, 3 sources of light or more with source and with color, a 5.42%. If we extrapolate to the catalog total, as we can see, in relation to PSX only a few games. Without going into how well optimized they are."

And correct some grammar and word translate mistakes.

Greetings! :D

David Gámiz Jiménez

13
Finally I can go presenting my "tribute" to #SegaSaturn. For now this first part in my blog. :)

http://www.davidgamizjimenez.com/inpostivegames/sega-saturn-to-the-limit-i/

Greetings!

David Gámiz Jiménez

14
UPDATED: 25-06-2018 81% Complete:
- 1 New game: Command Conquer. -- Interesting Proprietary Format Video and use of Transparency layers.
- Complete analysis for Street Racer -- Very interesting use of the transparency possibilities of SS. Possible very first game of make use of Near Clipping fade(3 levels) to VDP2, like Sonic R for Far Clipping, but one year before.
- Complete forbidden data analysis of VDP2 CC in Sprite Screen and VDP2 Screens use in Guardian Heroes.
- Improve a lot of games.
- Complete more games.
- Add more credits games.
- Improve Lighting column data.

15
Thanks for the update.
Have you seen a single game doing paletted gouraud?
Also, have you seen a game using RBG1?

Sorry I see the post today.

Have you seen a single game doing paletted gouraud?
Yes, but only for Normal Sprite, Polygons or Line. Not for distorted sprite or scaled sprite.
Also, have you seen a game using RBG1?
Yes, not are analysed deeply all games. And are possible that I confused RBG1 whit RBG0 or named RBG2. But are sure in this two example: Street Racer and Mechwarrior 2

Greetings!

Pages: [1] 2 3 ... 5
SMF spam blocked by CleanTalk