Messages

196

General Jo Engine Help / Re: Couple beginner questions on rotation around origin and model conversion

« on: March 11, 2018, 02:34:25 pm »

Ok! According to your video, the Saturn can't complete the drawing. You are at 60 fps, but with all the textured quads, it's too much. You can set dynamic framerate : DynamicFrame (On);  (I'm not in front of my pc, so it might have a different spelling or with sl in front, just look at the demo I made for ponut)

Also try 30 fps :
extern Uint8 SynchConst();
SynchConst=2;
(Again, I'm not on my pc, but take a look at the demo I sent ponut64).
Always use Single_plane!
Else it will still draw backfaced quads.

Also don't use real transparency.

If you really want 60 fps, use low quality textures : 16x16 or even 8x8, but with more than 450/500 quads on screen it might start to enter the draw end mode, which just tries to draw as much as possible before the v-blank.

Also, I forgot to mention, but use Window_In in the attributes.

197

General Jo Engine Help / Re: Problem after the Sega Logo.

« on: March 10, 2018, 04:32:20 pm »

It can be fixed, so I wouldn't worry too much about it for now.

198

General Jo Engine Help / Re: 3D 3rd Person Camera -- Issue with rotating camera face using jo_3d_set_target

« on: March 10, 2018, 01:18:25 pm »

Just be careful with the warping.
If you are, let's say, over 16384, remove 32768 instead of doing = -16384.
Because you could be at 16444, going to -16384 won't be smooth.
There are no issues with the RBG0, but if you warp under, it will become higher than you.
The framerate timer is based on the internal timer. The Saturn has v-sync, so you won't get over 60 fps on real hardware.
I don't understand your odd/even frame thing, but if it's to keep track of the framerate, it's useless.
Since one frame could take 1/60 seconds, the other one 2/60, etc. Doing ++ won't take into account the elapsed time.

199

General Jo Engine Help / Re: Problem after the Sega Logo.

« on: March 10, 2018, 01:10:35 pm »

The issue comes from the Jo Malloc allocating memory to wrong addresses on your AR+ 4 MB RAM. You can add a line in your makefile to support Pseudo Saturn Kai, which won't allocate memory on it and will allow you to boot the game.

200

General Jo Engine Help / Re: 3D 3rd Person Camera -- Issue with rotating camera face using jo_3d_set_target

« on: March 09, 2018, 11:21:30 pm »

I only took a short look at your code (I didn't try to compile it), but the way you warp around the world doesn't work :
-If you say when you are > 32677, you become -32677, then the issue is that if you are in fact 32700, you will still go to -32677, which will look like it's jerking.
-You are warping the Y value, which will cause isses as the VDP2 plane will become "over" you.
-You are using stuff like : when you press right, rotation ++. The problem is that at 60 FPS it won't behave like at 30 FPS. You want to move at the same speed regardless of the framerate. Take a look at the code I gave you, use the framerate instead and multiply it with a value (slMulFX).
-You put everything in the main file. You will have issues at one point where it won't compile because you will have too much stuff in one file. I really suggest you take what I did last time an re-use that (I learned the hard way, I tried to avoid having you get in the same problems I had).
-You mix the Jo engine matrix functions with the SGL matrix functions. Be super careful : Jo Engine takes integers and multiply them by 65536.0 (toFIXED), while SGL takes in already fixed values. If you mix both, you will get issues.
-Functions like Jo_div_by_2 are OK for unsigned numbers, but not for signed numbers (it will cause issues where one direction goes faster than the other). You can either divide or, even better, multiply by 0.5 using the fixed library, like this : slMulFX(value, 32768)

201

General Jo Engine Help / Re: Couple beginner questions on rotation around origin and model conversion

« on: March 08, 2018, 10:29:02 pm »

For the zdisp level, you can set it up to 7 so that it clips closer to the camera.

Make sure your model as the UseNearClip option for each quad in the attributes.
Also choose Windows_In so that only objects in your current window gets sent to the VDP1.
Both will do pre-clipping before sending it to the VDP1, helping you with keeping up the framerate and prevent issues.

For the memory, reduce in your makefile the jo_malloc memory. Something like 256 kb should be enough.
You can also load data to the low work RAM.

For the issue you are having, try to add stats about the amount of quads and vertices on screen.
It could be an issue because you have too much for the default workarea (2500 vertices and 1800 quads).
You can use the slCheckOnScreen function to check if the object is on the screen (if the returned value is >= 0) and discard what is not.


If not, if you are using real transparency, it won't work well. Either set the framerate to 30 fps  (jo_framerate) or remove the VDP1 transparency and use the mesh effect only.

202

General Jo Engine Help / Re: Couple beginner questions on rotation around origin and model conversion

« on: March 08, 2018, 05:41:10 pm »

For the collision tool/map converter, you can just open de cbp file in Code::Blocks and compile from there.

For the Blender tool, I haven't tried it yet, but I will soon, I'll let you know if it works for me.

203

Project announcement / Re: Sonic Z-Treme

« on: March 07, 2018, 09:17:48 pm »

My big next things :
-Custom view frustum culling function
-PVS and/or portals!
-Improve the collision detection
-Add basic ennemies/shooting collision
-Add (maybe) splitscreen  -done

(Don't mind the Sonic face, it's just a placeholder)

204

Project announcement / Re: Sonic Z-Treme

« on: March 07, 2018, 08:19:27 pm »

You mean with the Jo Engine functions?
I think it's just how it reads one sector (2048 bytes) at a time and puts it in a buffer.
I just transfer everything right into memory without any intermediate buffer.
As you can see, the loading is super fast.
I could work hard to make it load 1 or 2 seconds faster, but it's not worth the extra work I think since it's super fast already.

For the mipmapping, I don't generate the texture now if the 2 quads are too different. It increases the geometry, but it looks much better.

205

General Jo Engine Help / Re: Couple beginner questions on rotation around origin and model conversion

« on: March 07, 2018, 08:12:01 pm »

Have you tried this?
https://github.com/polygon-studio/Blender-to-Saturn-Model-Exporter

It has some issues with duplicated textures, but it should do what you need.
You can also try my FPS demo's map converter (old old version when I was just starting to learn to code) and play a bit with it to output your player's model.
It imports the textures too, so you would just need to play a bit with the export format to do what you need.

I will share my new FPS demo and map converter in a few weeks, you could also use that, but sadly it's not fully ready yet.

206

Project announcement / Re: Sonic Z-Treme

« on: March 07, 2018, 03:45:21 pm »

No for the homing attack.
I'm not sure I understand the question about the camera.
You mean free floating camera?
Maybe, but only if an analog pad is detected, else I'll keep it fixed at 90 degrees angles.

For the Robo Blast maps, sorry but it won't happen.
It's just too much work converting maps' geometry to fit the Saturn, I'll stick to Sonic X-Treme maps and maybe some Sonic Jam-style maps (just maybe).

207

Project announcement / Re: Sonic Z-Treme

« on: March 07, 2018, 01:05:48 am »

I'm just using the GFS_Load function from SBL.

Here is the game running on stock hardware (30 fps) :
https://youtu.be/VsHibSGWKuw

208

Project announcement / Re: Sonic Z-Treme

« on: March 03, 2018, 03:01:35 am »

 So I used a basic SBL cd function to load the maps instead.
The result? The maps now load in...5 seconds! 1.4 MB in 5 seconds instead of 100-120 seconds.
I couldn't believe my eyes how fast it was.

209

Project announcement / Re: Sonic Z-Treme

« on: February 26, 2018, 03:29:29 am »

The VDP1 limit is pretty well known, but there are ways to speed it up : use VDP2 CRAM, avoid overdraw, use lower quality textures, avoid some effects, do preclipping, etc.

For the difference, SGL is just poorly designed for memory counsumption. 4 bytes vertices (16.16 Fixed) is fine I guess (vs 2 bytes - 8.8 Fixed - for Slavedriver), but the quads are wasting way too much memory. One quad in SGL (using realtime light) is taking, without considering the vertices, 44 bytes. If you add an average of 2 vertices per quads (since some vertices are reused), that's 68 bytes.
There is nothing to be done, it's just how it is with SGL.

For lightning, again that's how Slavedriver works : they use 8 bytes for vertices, 2 for each axis (x,y,z) and 2 for the color.
You can do the same thing (static light) with SGL and gouraud shading without major issues simply by re-using the same gouraud adresses. For dynamic light, you need another vector (12 bytes). Even if you have the normals, you still need that extra vector as Sega found out their method had issues, so they just added something else on top of everything else.


Duke Nukem 3D is using 16 CLUT, not 16 bits RGB.

For mipmap, no, I can't use the VDP2 RAM. I really want to use the CRAM, but you only have a maximum of 2048 colors, but if you use 16 colors per sprite, you still need to have these 16 colors in the same area. When you have 500 sprites, it's nearly impossible. Using 256 colors is possible of course, but then you double the VRAM counsumption.
Gouraud shading can be used with VDP2 Color bank as proved by the "Chrome" demo, but Sega writes in its documentation that they can't guarantee good results.
Per texture light is great, but then again you need to store many more sprites, which isn't easy.

For the PVS, I haven't seen much code online, but unless someone else here codes something first, I'll have to do it myself.


For the cd functions, the problem is that duplicating work isn't efficient, we all have a job, girlfriends, and all, so we can't spend as much time as we'd like on these projects.

For audio RAM, for PCM, I never saw an example, but maybe some homebrew emulator do it, I really don't know.

210

Project announcement / Re: Sonic Z-Treme

« on: February 25, 2018, 06:17:03 am »

For the SCU : like I mentionned before, SGL doesn't work with that. You just cannot use it for lights since it's done during the polygon processing and you can't intercept it unless you do some really complicated tricks, so forget it, it won't happen. Plus it wouldn't help with the framerate as the main framerate bottleneck is the VDP1 more than the CPUs. I might use the SCU for some more advanced physics down the line, but I'm not holding my breath.

For RAM, of course I know! Else how would I have been able to load my maps (13 000+ quads, 30 000+ vertices), fill the VDP1 RAM to the limit with my generated textures (500+ different sprites with 4 bpp CLUT)?
Plus you can't compare my engine with the Slavedriver engine : SGL takes MINIMUM 32 bytes per quad, EXCLUDING the vertices (12 bytes each). The Slavedriver engine takes 5 bytes per quad and 8 bytes per vertices (x, y, z and the vertex color data) plus some per-plane data.
You are comparing 2 very different things. SGL is super fast, but it's wasting lot of memory and I'm stuck with that.

For realtime lightning : each realtime lightning polygon requires 12 bytes of extra vector data. At some 13 000 quads per map, we are talking about 156 KB. Yes the Saturn has 2 MB of Work-RAM, but you need to store the code, the tables, the entities (Sonic, ennemies, etc.) and other stuff. My maps are totally filling the low-work RAM. I want to keep high-work RAM for the PVS and I need to find a way to store PCM in audio RAM (I'm not even sure if it's possible with the Sega audio driver as I never saw any examples).
Btw, I'm not using gouraud on everything : only on the LOD model to reduce both CPU and VDP1 usage. Since the LOD quads are large, it doesn't look fully smooth, but realtime lightning would look terrible because of that (like one large quad getting lit all at once). Palette swaps or per-texture lightning (like in Wipeout) might be a better choice for static light, but then the issue is VDP1 RAM. The depth gouraud is only taking 64 bytes, so it's really not much.

For the PVS or Portal, the problem is the implementation, it's not easy.

For the CD, obviously I know exactly what I'm loading as everything is tightly packed in memory, so I know I'm not loading more than 1,3 or 1,4 MB : I load the textures first to LWRAM and DMA them to the VDP1 RAM, then the actual map data that I all keep in the low-work RAM. The problem is that the current jo_fs_read_next_bytes function fetches 1 sector (2048 bytes) at a time, so it's not making good use of the SH1 512 KB buffer since it keeps stopping and transfering the data. It could fetch 10 sectors at a time without stopping. The async load function, as-is, can't be used for what I do, so I'll have to see what Johannes has in mind or continue writting my own CD function using SBL.

So my available memory is : VDP2 RAM, audio RAM and SH-1 RAM. The rest is fully used or will be soon.