Recent Posts

Pages: 1 ... 8 9 [10]
91
General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn
« Last post by ponut64 on August 16, 2018, 01:26:48 am »
There are a few possibilities.

- They did not conceptualize the shadows as polygons, whether or not they actually were.

- Development for the system never got to the point where such a thing was conceived (remember, it was premier on the market for far less time than the PS1 and N64)

- Developers of the period hadn't a grasp of perspective correction well enough to understand that any method short of absolutely correct perspective correction has its applications compared to other methods. In other words, the Saturn doesn't have to use affine texture mapping, and the PS1 is worse for it, so the thought would be counter-intuitive.

- Developers were concerned with contextual overdraw, wherein interrupting the Saturn's perspective correction meant a part of the entire polygon pipeline, which could have drastic effects on the numbers of polygon's rendered if anything went wrong. (Most critically, because the texture warping on the Saturn is more or less because non-visible vertices are no longer calculated)

- Most likely, some developers of the time actually did do this, and we just don't know.
92
Project announcement / Re: Sonic Z-Treme
« Last post by 20EnderDude20 on August 16, 2018, 12:54:51 am »
So, to prevent someone from finding out that you're using mix ratios for metal sonic, can you use NBG2 as a mirrored version of NBG1, and set the mix ratio to that?
93
Wait, if the ps1 used affine texture mapping for everything 3d, and if the shadow looks the same even with the warping, why didn't any developers program shadow polygons to turn off perspective correction (calculating q value, tessellation, etc.) on the Saturn?
94
Project announcement / Re: Sonic Z-Treme
« Last post by SubCog on August 15, 2018, 06:59:19 pm »
Does that include the loop-de-loop physics?

He mentioned on the sonicretro forum that there won't be any loops in this build.  Check out post #71 https://forums.sonicretro.org/index.php?showtopic=36886&st=60
95
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 with 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.266 max @ 30 = 37.980
2 player Splitscreen: 1.374 max @ 30 = 41.220
 
Of which (Rounded data):
Gouraud Distorted Sprite = 1000
  a) Light source Color = 500
  b) Light 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 masked or transparent areas.
- Use Transparent Pixel only for distorted sprites with texture.
- Using End Code Draw and Transparent Pixel Draw 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 with 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) Change the texture quad to a flat polygon with a precalculated base color(representative of the entire texture)
 b) Gouraud is not drawn. Flat Lighing(pallete CLUT levels luminance).

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!
96
Free talk / Re: Would a module player (.it, .xm, .mod etc.) be possible?
« Last post by 20EnderDude20 on August 14, 2018, 10:15:31 pm »
How do I emulate the sound board? I know it's possible because a person made interaction between GEMS in DOSbox and Gens before. Can we do the same with Yabause and Basilisk II?
97
General discussion about the Sega Saturn / Re: Sega Basic Library 6.0
« Last post by 20EnderDude20 on August 14, 2018, 09:06:53 pm »
I don’t understand how a barrel shifter takes up a lot of space on a die, but I guess it’s enough to even make the dsp for the n64 have no barrel shifter for the new instructions. Comparisons aside, is the RAM for the dsp slower than the RAM for the sh-2’s?
98
General discussion about the Sega Saturn / Re: Sega Basic Library 6.0
« Last post by XL2 on August 14, 2018, 08:25:28 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.
99
General discussion about the Sega Saturn / Re: Sega Basic Library 6.0
« Last post by 20EnderDude20 on August 14, 2018, 07:57:47 pm »
Why are dsp’s so hard to grasp, demonstrated especially by the infamous difficulty of programming the dsp’s on the Jaguar?
100
General discussion about the Sega Saturn / Re: Sega Basic Library 6.0
« Last post by corvusd 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
Pages: 1 ... 8 9 [10]
SMF spam blocked by CleanTalk