Recent Posts

Pages: 1 ... 8 9 [10]
91
General Jo Engine Help / Re: More on ZTP
« Last post by XL2 on May 26, 2018, 07:06:04 pm »
About gouraud, I meant when you do ztLoad3dModel, the last option is to use gouraud or not. Just set it to 0 (off) as you will overflow the limit and erase textures.
92
General Jo Engine Help / Re: More on ZTP
« Last post by ponut64 on May 26, 2018, 04:25:52 pm »
The problem is some models (as frames of an animation, but they are models all the same) do not display and/or load. There's something wrong with how I convert them.

- IIRC slInitGourad would be what you are talking about, and it is the last thing that main does.
- I was afraid that Blender would do that.
- 564 KB is being loaded to the best of my knowledge
- I changed the directory order and ... i think that was it, gimme a sec

/e: Yes, it was too many files in the same directory. Thanks for the tip. I figured it was something simple.
I do wonder what the upper limit really is because some animations may end up being around 30 frames.
Eh, things can always be chunked up.
As always I appreciate what you do.
93
General Jo Engine Help / Re: More on ZTP
« Last post by XL2 on May 26, 2018, 03:55:44 pm »
I'm not sure I understand what your problem is, but some ideas :
-When you load, put gouraud at off, else it will overflow.
-The vertices order could be different from one Obj file to the next, which can cause issues.
-Make sure you don't load over 1 MB in total.
-You have too many files in your root folder, causing issues (like 20-25 files or folders).
94
General Jo Engine Help / More on ZTP
« Last post by ponut64 on May 26, 2018, 03:40:17 pm »
Hello mostly XL2,

As your tool is a work-in-progress I'd like to share a project file where I am having some issues.

Some models exported from my animations to be converted in to ZTP files are not loading. This seems non-nonsensical, as the only thing that has changed about the model is its pose.
Another conundrum is it happens in a way spread out across the range of entities. Some in a range stop loading, then models start loading again, then they have problems again.
There is something wrong with my OBJ files and I am not sure what it is.

The issue can be found in &entities[5] through to &entities[10] (and other sequences). In the binary model converter folder (starting from top level), this is RTURP05 to RTURP10. It does NOT happen for those same frames when mirrored (pose copied from L bones to R bones, some other numbers inverted some not, then exported as OBJ) on LTURN05 to LTURN10 / &entities[15] to &entities[20]. Should be noted that the LTURN is the original animation that was copied.

Thank you for reading.
95
Project announcement / Re: Sonic Z-Treme
« Last post by XL2 on May 25, 2018, 12:17:06 am »
I think I found a solution!
By using gouraud shading on 8 bits paletted sprites, I could simply register 8x 256 color banks with different light intensity. By using gouraud changing the color value of bits 9 to 12, it would just switch the color banks!
That means I could get gouraud lightning AND transparency.
Of course, only 8 intensities is a bit of a bummer, but it's better than none and it should look smooth enough.
I'm not 100% sure that it could work with realtime gouraud as it would require to register the 8 values and tell SGL to onpy choose among those.
Another benefit is that if your quad has flat lightning, you don't need to use gouraud, saving VDP1 rendering time.
I think it's a much better solution than what Sonic R does, but fitting all my colors in 256 values isn't that easy and it might not look that great and it prevents differently colored lightning (so you only have 8 intensities for any given levels), but we'll see I guess.
Of course, if I could somehow fit all my colors in 128 values, I could get 16 intensities, and full 32 intensities if I make it fit in 64, but I doubt it.

Edit : Ok, so the answer is that it wouldn't work for full gouraud (only flat lightning). I'm now looking at other solutions with 32 colors and green gouraud or 256 with red gouraud.
96
UPDATED: 23-05-2018 79% Complete:
- New games. Up to 257. No comment.  ::)
- Improve a lot of games, in various columns.
- Improve title columns.
- Improve some most important SEGA games.
- Complete more games.
- Add more credits games.
- Improve Lighting column data.
- Basis Analysis to Altron games.
97
Project announcement / Re: Sonic Z-Treme
« Last post by corvusd 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!
98
Project announcement / Re: Sonic Z-Treme
« Last post by XL2 on May 23, 2018, 04:30:07 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...
99
Project announcement / Re: Sonic Z-Treme
« Last post by corvusd 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!
100
Project announcement / Re: Sonic Z-Treme
« Last post by XL2 on May 23, 2018, 12:20:44 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.
Pages: 1 ... 8 9 [10]
SMF spam blocked by CleanTalk