Messages

31

Project announcement / Re: Sonic Z-Treme

« on: May 23, 2018, 09:22:47 pm »

Yeah, I think it would make more sense to use textured lightmaps instead of gouraud for speed reasons, but it takes a lot of VRAM.
And the Color RAM is super limited, so I don't know.
If I had more color RAM I would just pick gouraud on everything.
Maybe I will use a technique similar to John in the end, or maybe I'll just not care about the transition between gouraud/no gouraud...

Yes, texture with the light "painted" is the most cheap and nice solution. The cost is it need more space data in VDP1 VRAM in pattern, and color data in VDP1 or VDP2 area VRAM. And more, if you need 4 or more variant color grades for ratio CC function for fade over VDP2 foreground, more data. In this case direcly in VDP2 color VRAM.

For Gouraud with texture, distorted sprite, only you can use color of the VDP1 RAM. The Gouraud tables store in specify boundary in VDP1 VRAM. John for Sonic-R seem convert in the fly the color palettes to Color Bank for the pattern in far clipping to fade area. Maybe the transition area is for this reason... I think.

In other hand, this issue is a good reason to gain speed. Because in some Z value in far clipping, the game not draw Gouraud distorted sprite, more expensive that distorted flat quad.

For me the ideal situation is a system lighting with a base ambient color , with at 3 lights parallel lights sourced color to affect a 3D model in real time. Very nice effect, and pretty usual in PSX games. And in other hand totally possible in SS. For the scenery, pre calculated Gouraud table lighting in some point in the scenery, is are a nigh or point lighting in the design. This point are at the 3 Light parallel that can affect at 3D models, not all models, only a controlled quantity, for not recharged the CPU lighting calculate. In someway Burning Ranger, Loaded(Point Lights) and Lobotomy Slave(Point Lights) engine archive this type of final render in SS.

The problem of use Gouraud with your LOD scenery system is we can see the change in the geometry shading, but for me is a low cost, to have lighting shading 3D real time game, and with a good compromise with the final speed.

Only share with you, my ideas, not are that I want say that need it your project. Right now, I think is a wonderful gift for the lovers SS, and possible the most advanced homebrew realtime engine for the system.

Regards!

32

Project announcement / Re: Sonic Z-Treme

« on: May 23, 2018, 07:45:15 am »

Nice, I didn't see it.
I use the same technique for CBANK sprites, but I admit that his solution for CLUT sprites could work, but then why even put gouraud shading if it's so limited? I could just write the lightning value directly on the textures and it would be faster for rendering.
Of course it would take way more VRAM, but it might work.
Another solution is to use the gouraud on CRAM sprites bug to produce pseudo bump mapping.

Your current implementation is very good.
I think that John's implementation is a bit more complex than yours.
In this way you have the scenarios with the same illuminated light, already pre-calculated. And characters with light Source Gouraud plus the stage static lighted looks very good.
Obviously he does not use Gouraud with Color bank in distorted sprites for the final Fade on the VDP2, because of the bug there is. At least that's what I think.

Anyway, I think that even we can get more with SS. Have a Depth cueing with fade like the one you have implemented, and use the transparencies of VDP1 plus the VDP2. As soon as I have a little time, after advancing the game analysis. I will start to design my idea to share it with the community.

Let's see if for future homebrew games we put the limit even more to the SS.

Regards!

33

Project announcement / Re: Sonic Z-Treme

« on: May 22, 2018, 11:47:26 pm »

I do plan on having static lights (the quads closer to screen use CLUT while the quads with CC use CRAM banks), but I'm quickly running out of time.
But if I think I can implement it in 1 or 2 hours I will sure try it!

fyi
https://www.youtube.com/watch?v=FdD0GvVRSMc&feature=youtu.be

34

Project announcement / Re: Sonic Z-Treme

« on: May 18, 2018, 09:35:17 pm »

Still a very long way to go : I'm not done with the rendering part and I haven't started to put gameplay back in (you can just move the camera around now), but I think it looks rather good so far.
You can see the draw distance is quite good!
I might have to reduce it a little bit, but it shouldn't impact too much the visual as the draw distance is a bit too far now (it should still be fine at 30 fps).
Plus with the transparency effect, I think most people won't mind and will instead appreciate the effects

Absolutely great improve.
Your new build whit the far fade clipping whit the VDP2 CC ratio and priority is great, same that Sonic-R or very similar. Sonic-R use static source Gouraud in all the rest scenery before fade.
And the Sonic and Tails whit Real Time Gouraud Light is amazing! All together look very nice an promising! Go Go!
You can see that me, are capable to appreciate all this effects and your GREAT efforts!! Thanks!!

35

Project announcement / Re: Virtua Skimmer

« on: May 18, 2018, 09:30:41 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.

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

36

Project announcement / Re: Virtua Skimmer

« on: May 17, 2018, 08:57:51 pm »

I tested it on real hardware, I tried with 7 models (around 180 quads per model) and the results are rather good, with 60 fps with 4 models, then the VDP1 can keep up, but the CPU doesn't. By not updating each frame, it might be possible to keep 60.

https://youtu.be/XapzA2yPEAU

Very interesting implementation XL2. You are using one light Dynamic source for all models. 1200 quads lighted whit source. Really nice. You think if is possible improve the performance or use of the CPUs? More Lights and whit color? Thanks!

37

Project announcement / Re: Sonic Z-Treme

« on: April 22, 2018, 10:58:16 pm »

Maybe is to soon to say something. XL now are learning and improve your engine, to put at limit SS. All your ideas are great and maybe possible. But, now not is the time to this. And this type of design, maybe, is too big for the machine or the actual technical resources. Thanks for your apports. 👍

38

Project announcement / Re: Sonic Z-Treme

« on: April 14, 2018, 10:42:01 pm »

The flat shaded quads in SGL can use flat lightning both in RGB and palette format.

Perfect!

I'm not using the SCU DSP yet, so it's SH2 only.

Not mention SCU in the next two years. I promise XD

I can't do realtime light with color bank sprites, but I'm now doing like in Sonic R and Bulk Slash.

Why not? What refer exatly that doing like this games?

I can't use the high res mode, it's super hard to setup, so I don't want to waste time on it.

It is possible, the requirements are many and both VDPs. It is normal that you choose not to get involved in this. But is very attractive, have it full resolution SS in a Sonic game.

39

Project announcement / Re: Sonic Z-Treme

« on: April 14, 2018, 10:52:32 am »

I just did a small video (it's not public as there isn't much to show) for the split screen mode and the removal of gouraud shading/use of CRAM sprites.

https://youtu.be/jHaXoe9lfMc

Really nice improvements!! Congratulations.

We can see source lighting in models no? Yo are calculate level of luminance or brightness, by VDP1 CC or change color palette for this face??

For calculate lighting use SH2 or SCU-DSP?

And finally. You can apply this lighting to scenery faces?

If you can all this without use CC, is possible you can use Full HiRes mode in VDP1 and VDP2.

Greetings!

40

Project announcement / Re: Sonic Z-Treme

« on: April 11, 2018, 09:10:18 am »

Haha, just using the SCU DSP would be a great start!
It has really limited memory, so it can't do that much.

Update on the project, I've now moved from 16 colors Lookup tables to 16 color bank (CRAM). That means no more gouraud shading...but I will be able to use transparency, which is better.
I'm not sure if you can do color calculation over the back screen, but if you want the same effect as depth gouraud shading you can just put a black background and use the VDP2 transparency to have the same effect.
It also offloads work from the VDP1.
The only issue is that the color RAM is really limited, but so far it seems all the maps I tested got everything within about 1000 colors, and if it can't fit in CRAM I put a "safety" measure where it just uses CLUT.

I haven't made much progress on Sonic Z-Treme yet, so the game is currently improving only on a technical level, but I hope to be able to integrate everything in the game soon.

You not said that is possible use gouraud whit palleted color like chrome demo? You are check? I can't because I don't  have compiled and mastered iso the demo, and I don't know make it, for analysis in Yabause for see how work it.

In other hand, you can make also liike sonic R. Use gouraud whit lut from near clip to medium distance and change to whitout gouraud whit paleted to make fog fade to foreground vdp2.

Greetings!

41

Project announcement / Re: Sonic Z-Treme

« on: April 07, 2018, 03:13:06 pm »

You can issue program change commands, but I highly doubt it can process programs in parallel.

[EDIT] Well, is a fact the SCU-DSP are capable to process at 6 process per cycle. A program well design and using concrete types of RAM and DMA, could be possible make two parallel task.

42

Project announcement / Re: Sonic Z-Treme

« on: April 07, 2018, 02:00:27 pm »

Well, I will try.

But I think that SCU-DSP can be process the two task in parallel. In my analysis table data you can see that are free memory and registers for that.

 

43

Project announcement / Re: Sonic Z-Treme

« on: April 07, 2018, 11:29:08 am »

Hello community!

[EDIT] For Overhead in sound stuff, From: ST-166-R4-012395

Overhead During Data Transfer

Since the PCM playback slot is fixed at 44.1 KHz, 1 sample is played back every 22.68 μs from the start of playback. Therefore when Vint is used, 735 samples (16,666 μs ÷  2.68μs) need to be rewritten (transferred) every 16 ms for one stream playback channel.

During DMA burst writes:
1 word transfer = 4 clock cycles (1 clock cycle = 35 ns)
Assuming 1 word transfer = 6 clock cycles to allow a margin of safety, then 6 clock cycles x 735 words = 4410 clock cycles (= 154.35 μs).
The SH2 requires approximately 154 μs to transfer 735 words (1,470 bytes).

However, if other sounds are being generated, or if the DSP is being used, the sound chip can only access the sound memory 20% to 30% of the time per one sound chip cycle (22 μs). This requires extra wait time, and since only 16 words can be transferred in one cycle (22 μs) of the sound chip, about 1 ms is required to transfer 735 words.

The 735 samples referred to by the equation above is for mono playback at 44.1 KHz. Overhead can be reduced to half if playback at 20 KHz is acceptable (equivalent to 368 samples).

When using DMA, avoid long, continuous transfers so that the sound CPU can operate. The sound CPU cannot operate during DMAs if data is transferred continuously.

For the ADPCM by CRI, the only stuff that exist in the web is this links:
https://wiki.multimedia.cx/index.php/CRI_ADX_file
https://wiki.multimedia.cx/index.php/CRI_ADX_ADPCM
https://en.wikipedia.org/wiki/ADX_(file_format)

If you see the principal part of code in examples decoder:

Code: [Select]

#define M_PI acos(-1.0)
 double a, b, c;
 a = sqrt(2.0) - cos(2.0 * M_PI * ((double)adx_header->highpass_frequency / adx_header->sample_rate));
 b = sqrt(2.0) - 1.0;
 c = (a - sqrt((a + b) * (a - b))) / b; //(a+b)*(a-b) = a*a-b*b, however the simpler formula loses accuracy in floating point
 
 // double coefficient[2];
 coefficient[0] = c * 2.0;
 coefficient[1] = -(c * c);

Are a lot the operations, that the SCU can be process really well. The theory that Burning Rangers uses the SCU-DSP is give a push, that whit this need it the SCU can be process this data.

Greetings!

44

Project announcement / Re: Sonic Z-Treme

« on: April 05, 2018, 06:40:12 pm »

Thanks.
But if anyone wants to do it, it would be more than welcome for the whole community!
I need to finish the model converter I promised and continue working on the engine for a long overdue update.

Edit : Just added an image of PCM-ADPCM CPU overhead. Note that playing small sounds from memory is less expensive since you don't need to transfer data from the CD, but it still requires DMA and hogs the B-Bus.

I know this table data.

But I have a doubt. The overhead are for 1x SH2, for 2x. For the M68000? For all?

And more. The formula use it to calculate this value % is this: R = (100 X Ttask) / Tplay

Whit this, really not know, which CPU refer, or quantity of cycles used for DMA transfers or decompress the ADPCM data... And another doubt is, use it DMA transfers via SCU or directly SH2 to 68EC000 or SCSP. Or both.

Last. ADX form CRI, is possible better implementation of ADPCM for SS. Burning Rangers or Deep Fear, play BGM all time, and use it also for speech or dialogues. I don’t know if is possible play more than one stream or more, play directly from RAM and mix "like" PSX. I cant find the SS library functions form ADX in the web.

Greetings!

45

Project announcement / Re: Sonic Z-Treme

« on: April 04, 2018, 09:45:21 pm »

Good work!

SS not is the 32bit “easy machine” but in other way, it is a constant give challenges to a clever brain!

I think that issues: “the CPU overhead” and “a little Sound memory”. In count part to PSX, for me is very similar situation. Is true that PSX is capable of use ADPCM, and have more sounds or more quality, or medium sound and quality. But in SDK PSX the sound program have CPU overhead, the access to DMA same situation. And the dev should fight whit this little memory to read on fly ADPCM track or mix ADPCM sound in Memory. In conclusion, for SS is very similar situation, but whit more processor run at same time. In this path the key is a good control of the all flow program bucle data management. Nothing that you not know. XD

For me the big problem, is the need it of specialize hardware to create sound or music in SS. More to load DSP program like, reverb, echoes, surround like or Qsound, 3D Qsound o Yahama 3D. And more, whit a MAC machine?? More good software and without extra hardware, It could been a better situation to compete whit PSX SDK, and sure make easy the life to de devs

Ideally, for your project and/or jo-engine in this area is build tools like you said. A tone editor for a modern PC. And we will can get: audio program bank, sequencer or DSP programs, and finally compile sounds in SS format like. I prefer that all this tools develop it whit toolkit open source and multi-platform, to guarantee the long life and maintained. But that you decide this aspect, is your project.

Greetings!