Messages

121

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

« on: June 05, 2018, 04:46:02 am »

Ok, good news!

I got the vertex animation working with compressed vertices (6 bytes each instead of 12 bytes) and linear interpolation (so that you can display a 60 FPS animation with only 15 frames or less if you wish).
Vertex animation allows you to do animations as complex as you want.

I got 40 frames of animation down to 10 KB with 175 vertices (the Sonic model) at 15 fps interpolated to 60 (so 10 frames of animation instead of 40).
I still need to add normals with (maybe, could be overkill) interpolation as well.
It should be possible to compress the normals to 3 bytes instead of 12, but I'll need to see the results as it could be bad.
For the Sonic model, I could probably have 240 frames worth of animation down to less than 100 KB.
While it's a lot, Sonic moves fast so I need more frames, but for a slow moving caracter (like a human) you could probably get good results at 1/6 animation or less if you dismiss 60 FPS.

I still need to improve everything and the user interface is quite complicated right now (you need both your base OBJ model with material and the animation OBJ files numbered in a linear fashion - but Blender can generate those easily).

I'm also worried about the impact on CPU.
Sadly I don't know assembly so I won't be able to fully optimize the function or offload it to the SCU DSP, but I hope to keep the cost to a minimum.

I also added an option to reorganize the 3D model so that you can easily add bone-animation to it if you wish to (for manual animation only).

I hope to release the new version of the converter tool this week.

122

General Jo Engine Help / Re: Usage of GFS_NwFread (you probably expected this...)

« on: June 03, 2018, 05:45:43 am »

Ok, I will support 2 ways to do animation : per vertex and by matrix.
The per vertex will require the user to set up his own table to know which frames to play.
The per matrix animation allows the user to manually set the meshes ID, so this way you can make all your models match the same IDs and keep one hierarchy format.
Then you will have to write your own animations, but it saves a lot of memory and you can reuse the same animations on several models.
Both ways require some work, but anyway I think it's nice to have 2 options.

123

General Jo Engine Help / Re: Usage of GFS_NwFread (you probably expected this...)

« on: June 02, 2018, 02:24:50 pm »

On my end I got vertices animation export/import working, but the more I look at it the more I hate this.
While vertices animation is more flexible, it takes a lot of memory and it's quite complicated to set up using .OBJ files.
Again, I won't have time for Collada support, but it would be way better.
The main issue is that it's a complicated format and it takes forever to get it right.

124

General Jo Engine Help / Re: Usage of GFS_NwFread (you probably expected this...)

« on: May 31, 2018, 09:14:34 pm »

My functions overwrite the texture data after transfering to VRAM, so it doesn't work because you don't update the currentaddress correctly.
Look at your byte offset : you initialize it by calling itself, which doesn't work.
That offset is for cd sectors, which doesn't work here since all the data is dumped in RAM.
Your current adress should be : sizeof (mod data) + Texture size.
But it's bad practice because you don't need the textures in work RAM.

125

General Jo Engine Help / Re: Usage of GFS_NwFread (you probably expected this...)

« on: May 31, 2018, 04:21:20 am »

I'm getting close to have animation support.
The new version and code should be out in a few days if all goes well (I could encounter deal breaking bugs as I know very little about animation).
DAE would have made my life way easier if I just focused on that format a while ago, but now I won't have time for it, so let's hope everything works OK!

126

General Jo Engine Help / Re: Usage of GFS_NwFread (you probably expected this...)

« on: May 30, 2018, 06:31:00 am »

I didn't look at it for very long, but you put everything in your loop.
It loads textures and everything you don't need and loops these functions over, causing crashes.
In think you should just ditch the loop, load data until textures like I did, then start the async loading using the sector offset that I already had.
Then just load all the data in the cd buffer, wait until it's done and then fetch the data to your start address.
You could then call the other functions.
I never played with streaming functions, but the cd ram buffer can hold 512 KB (crazy that they put so much ram there and the Saturn still had crappy video support).
For your animations, it just wouldn't work, but you could try with images, maybe allowing you some kind of pseudo Resident Evil game where you could always cache the next backgrounds in RAM and transfert it to VRAM when you swap backgrounds.

127

General Jo Engine Help / Re: Usage of GFS_NwFread (you probably expected this...)

« on: May 30, 2018, 01:05:24 am »

I didn't take a huge look.
For the function, I never used it myself, but I think the Jo Engine async loading uses it, so you should look there.
You don't need to load small segments since I aligned all the model data to just be dumped in memory, which is way faster.
You also return before closing the file, which is wrong.

128

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

« on: May 29, 2018, 04:37:41 pm »

The default workspace can process 2000 quads max, but it will display less because of backface culling.
In my FPS demo I could display over 1000 textured quads at 20 fps.

129

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

« on: May 29, 2018, 05:51:36 am »

Here is my model converter (and source code) with my custom binary file format I made for my Sonic Z-Treme Engine (ZTP for Z-Treme Polygons).

The code is bad, I just quickly coded this and didn't spend much time cleaning up or removing all the globals.
I will revisit the code and try to add precalculated lightning and per vertex animation support. (done 2018-06-10)
I also added a demo I originaly made for our friend Virtua skimmer.
I would like to ditch OBJ files for DAE, but it's quite hard to implement so I might stick with OBJ for now.

New in version 0.05 : I rotated all the quads 180 degrees and flipped the normals so that the textures are in the proper direction (it was just an annoying issue that didn't cause problems). Updated the demo to add a few features. If you just want to use the converter, update your model loader c file in the ZT folder else you will get alignement issues (the sprites are now in ZTI format).

New in version 0.10 : Animation support! The tool can read a chain of OBJ files and do vertex animation (similar to Quake 2 MD2 format) with interpolation. The normals are also compressed. The demo's animation is bad simply because my own animation is bad, so don't mind it!

130

Share your code / Re: Spreadsheet data analysis SS featured games UPDATED: 28-05-2018 80% Complete

« on: May 29, 2018, 01:32:30 am »

Thanks for the update.
Have you seen a single game doing paletted gouraud?
Also, have you seen a game using RBG1?

131

General Jo Engine Help / Re: More on ZTP

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

132

General Jo Engine Help / Re: More on ZTP

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

133

Project announcement / Re: Sonic Z-Treme

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

134

Project announcement / Re: Sonic Z-Treme

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

135

Project announcement / Re: Sonic Z-Treme

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