Messages

16

Project announcement / Re: Sonic Z-Treme

« on: August 23, 2018, 09:40:11 am »

Yeah, but the solution is to subdivide the map further. The PS1 had that feature in the sdk from day one. The Saturn, as usual, doesn't and can't really do it. I'm trying to find a way to clip textures in vram to subdivide it in 4, but I'm not sure it will work.

17

Project announcement / Re: Sonic Z-Treme

« on: August 23, 2018, 02:29:35 am »

The engine does push quite a bit of quads!
Without the LOD, it would destroy performances, but it holds up nicely.
I hope in the future to implement a hidden surface removal, but for now that will do.
Here is the new wireframe mode (hidden in options - Just L+R+Up to active it) plus the pseudo fisheye (the projection plane is closer to the camera, giving a larger FOV and little distortion).

18

General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn

« on: August 22, 2018, 02:53:12 am »

I guess one "easy" solution to transparency involves the following trick :
-Calculate your 4 vertices. Sgl has a function to do it and return the results (something like slConvert3dto2dfx).
-Get your min x and max x.
-Build an array [max x - min x] containing your min y and max y (so 2 unsigned shorts).
-Doing a bit of interpolation, calculate your min y and max y for each x value.
-If you are feeling on fire, interpolate your gouraud shading too.
-Use MANUAL draw commands (slSetSprite in SGL) and use 2 points lines, with your current x value and min y for point A and your current x and max y for point B. Set your color, select transparency and in your draw priority put your z value (max or center usualy).

Now it won't work correctly with scaled sprites because your minimum width is 8 (but I never tried with zero, it might just work too even if Sega says it doesn't. If it does your points x width should be 1 ).
Your "covered" data in the framebuffer must be in rgb code (16 clut or rgb) else the transparency won't even be processed and you will waste precious cycles.
Like usual, expect slower performances with transparency, so make sure you have no overdraw if you use it.
Cpu wise it shouldn't be too demanding unless you do it for like 20 objects or more.

19

Project announcement / Re: Sonic Z-Treme

« on: August 19, 2018, 12:07:25 pm »

As far as I remember it was an unsigned char, but I will look it up once I'm back from my vacations. But most likely is that the source audio is just bad. I just ripped the music from youtube and converted it to wav after, so it's not very good.

20

Project announcement / Re: Sonic Z-Treme

« on: August 19, 2018, 08:57:37 am »

I'm using SBL for the audio.
You mean only the left or right speaker is outputting cd audio?

21

Project announcement / Re: Sonic Z-Treme

« on: August 19, 2018, 06:59:20 am »

Yes, you will see in 5 days.

22

General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn

« on: August 18, 2018, 07:14:01 pm »

It's not about if you can find the proper angle. You would need that only for square objects, so probably only for the world objects or maybe some platforms. Each pixel takes 6 times the time it takes to draw a normal pixel. It doesn't make sense to have slowdowns for such a small details. And you increase cpu calculations as well. You could just use a msb  distorted sprite if you framebuffer is palette only, you could just precalculate that shadow and use palette swaps to create a shadow (which is what I do) or use another vdp1 color calculation function (like gouraud or half luminance). There are reasons why very few games used half transparency, and it's because of both the bug and the slowdown.
The mesh effect looked ok on crt with composite, which is what people used back then, so it just made sense to use that instead of decreasing your framerate.
Even Burning Rangers used the mesh effect very often.

23

General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn

« on: August 17, 2018, 11:00:35 am »

I agree with Corvusd.
It's easy to come up with ideas, but it seems nobody else ever actualy try to write the code themselves.
I've got ideas myself for more transparency (even if my game is filled with vdp2 transparency), but until it's written it's not worth much.
Like if you use vdp2 for sprite over sprite transparency, how do you solve the priorities?
It's super complicated, but most people don't think about these.
Like sure, I can use the NBG0 as a framebuffer, but then all my other sprites need to have the correct priority.
Even Burning Rangers struggled with it, and it was made by one of Sega's best studio.

24

General discussion about the Sega Saturn / Re: Sega Basic Library 6.0

« 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.

25

General discussion about the Sega Saturn / Re: Sega Basic Library 6.0

« on: August 14, 2018, 06:28:08 pm »

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.

26

Project announcement / Re: Sonic Z-Treme

« on: August 14, 2018, 08:25:52 am »

I have a newer version for sage, but only a couple more physics and graphical additions.

27

Share your code / Re: I burn my ISO on one CD, but it's don't run on my Saturn... :-(

« on: August 12, 2018, 07:38:41 pm »

If your pseudo Saturn has ram, it will crash with Jo Engine becauseJo engine tries to allocate memory to a non-existant adress.
Use the workaround in the makefile or change the adress of the ram to the correct values.

28

Share your code / Re: Model converter (.ZTP) -0.1 - WIP

« on: August 08, 2018, 07:26:30 pm »

No, I don't intend to release it

29

Share your code / Re: Model converter (.ZTP) -0.1 - WIP

« on: August 08, 2018, 07:17:28 pm »

That version (old one) isn't supported by me anymore, it was 16 bpp.

30

General Jo Engine Help / Re: Making a 'corrected texture' on a triangle.

« on: August 03, 2018, 07:00:06 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.