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 - XL2

Pages: [1] 2 3 ... 22
1
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.

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

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

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

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

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

7
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

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

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

10
General Jo Engine Help / Re: Making a 'corrected texture' on a triangle.
« on: August 03, 2018, 01:36:15 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.

11
Project announcement / Re: Sonic Z-Treme
« on: August 01, 2018, 02:31:51 am »
Sorry to say that but it looks a bit...special.
Robotnik is way too flat too, his arms are a sheet of paper.

12
Project announcement / Re: Sonic Z-Treme
« on: July 31, 2018, 10:35:41 pm »
For the animation it does because it compresses the vertices, so you lose precision, mainly at the higher bits.

13
Project announcement / Re: Sonic Z-Treme
« on: July 31, 2018, 06:23:48 pm »
What do you mean by "they are acting up"?
If you mean a "round" quad, you can use the DUAL_ flag in front of your texture to make it dual plane, then it won't be affected by the normal.
Only do that for as little quads as possible else you will increase the VDP1 workload.

14
Project announcement / Re: Sonic Z-Treme
« on: July 31, 2018, 04:30:31 pm »
Good job!
I see you're having fun with my converter :P
Edit : The normals are recalculated with the converter because of the scaling btw. It also uses compressed normals, so the precision isn't that high.

15
Project announcement / Re: Sonic Z-Treme
« on: July 31, 2018, 04:24:35 pm »
Wow, that's nice.
But are you sure you only have quads/triangles?
Anything with more than 4 faces won't work on Saturn, so I'm just making sure.
I would suggest also to make his nose untextured but in 3D.
Overall that looks really nice!

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