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 ... 11 12 [13] 14 15 ... 23
181
Yeah, don't worry too much about optimization for now.

That being said, if you need a hand to write another collision detection function, don't hesitate to ask and I'll see what I can do.

182
I never played with the jo_vectorf, so I couldn't say.
AABB is one cheap way to do general tests, but you can easily do sphere vs sphere tests too.

So to test against rings, you could do something like : test against sphere, which gives you a pretty good idea. Then you test the distance to see if you are crossing the ring's plane  (2x dot products : before updating the player position and after, if signs are different, you crossed the plane). You would just need to calculate the normal vectors, but that's easy : just do a cross product and a distance division to find the normals, which you should do offline or as you load the map.
At the cost of max 2 dot products and sphere calculation, you would get a quite accurate collision detection.
Per quad is easy too, you just need a proper map subdivision (grid, quadtree, octree, kd tree or bsp tree).

183
I just took a short look at your code, and I need to ask : are you trying to build a space rocket?
Just kidding, but seriously you are overcomplicating this.

You can just use a bounding sphere around your objects or an AABB (like for the whole mesh so it's fast).
If you want a per quad collision detection, start with the AABB/sphere detection, then find a point on each quad (a vertices) and use the quad's normal to do an innerproduct (using your position minus the verticle position).
If the result is <= 0, you can check if you are crossing this quad (AABB again should be good enough, just find the minimum and maximum points) and check if you were crossing the quad's plane before updating your position.
It should take around 30 lines of code max and should be way faster than what you are doing.

184
SGL is using tables AFAIK for the square root functions , so the cost shouldn't be higher than doing a sin/cos.
Jo Engine also has some tricks to reduce cpu usage.
I don't have time this week to look at your code, but maybe you can try that.

185
Jo Engine Wish List / Re: 3D Textured Mesh Sample
« on: March 21, 2018, 03:30:10 pm »
It will do it all for you, as long as your model has material names that fit the TGA file's name. All textures should be 32 bits per pixel BUT should have no more than 16 colors (if not the program will compress the colors and you will loose details ).
I'm not supporting 32 bpp textures anymore as it just wastes VRAM.
It won't read the mtl file, so I will have to figure a way to support flat shaded quads, but I guess the easy way would be to use a 1x1 texture and I could just retrieve the color and put it on the quad.
We'll see.

186
Project announcement / Re: Sonic Z-Treme
« on: March 20, 2018, 06:09:50 pm »
I don't know about Robo Blast.
I will probably just allow free rotating camera with analog controls and keep the 90° rotation on digital control.

187
Project announcement / Re: Sonic Z-Treme
« on: March 20, 2018, 05:52:57 pm »
I will keep the X-Treme levels, so I'm not ditching the formula. But I will add more open levels, if I can make it work well with the current physics.

188
Project announcement / Re: Sonic Z-Treme
« on: March 20, 2018, 02:31:45 am »
While I'm not ditching the X-Treme formula, I'm moving toward Sonic Jam-type  (or Project Condor) levels, so I don't want to spend too much time on creating "blocky" levels.
I'm slowly resuming work on Sonic Z-Treme, so sadly I have no idea when it will be ready, but I want to show my next version at SAGE 2018, so hopefully I'll have something nice to show by then.

189
Project announcement / Re: Sonic Z-Treme
« on: March 20, 2018, 12:18:26 am »
You are right. But would anyone want to bother doing that?

190
Project announcement / Re: Sonic Z-Treme
« on: March 20, 2018, 12:08:09 am »
Unless you have the actual 3d format (that you can read on a pc) of the maps, no. I don't think anybody ever bothered to rip those as the game wasn't that good.

191
Did you try to reboot again instead?

192
Jo Engine Wish List / Re: 3D Textured Mesh Sample
« on: March 16, 2018, 01:04:06 am »
I'm (slowly) working on a tool to do just that.
I'm not fully done yet, so maybe in 2 or 3 weeks I could try to release it with a small demo.
It just converts the model and textures to either c file or a binary file and you will just need to use the demo functions with it to load the model.
Sadly, I couldn't think of a way to include animations (I'm not that great with 3D modeling software, so even there I'm bad at animating).

193
The order you call the rotations influence the output.
Just use the 3D model for now as it's easier for you.

You shouldn't use the Pseudo-Mode 7 for what you're doing. The Pseudo-Mode 7 is pretty much doing DMA to transfer a new image to the NBG1 to give the illusion of movement, while a RBG0 is a real 3D plane that can move in all directions.
It's much harder to use the RBG0, but it will be much faster and will be way more flexible.
For what you are doing, it's a no-brainer, you should use the RBG0.

194
I'm not 100% sure I understand your problem.
Try playing with another axis instead (x instead as an exemple), or do the rotation before the translation.
Play with a few settings, I'm sure you'll figure it out.

195
Try to burn disks at 2x.
It could also be related to the current functions : there are issues with the current Jo Engine CD functions according to my tests.
You can use the SBL GFS_Load functions (look at RockinB tutorial to see how it works : http://www.rockin-b.de/saturn/saturngametutorial/SaturnGameTutorial.htm ) for now as they are much faster, but it would require you to play with memory allocation (sending everything to Low-work RAM should be the easiest way).

Also, try to use Single plane only on your model.
Trust me, you don't want dual plane except for some rare instances (a quad that you need to be able to see from both sides).

From what I see, there should be no reasons that it can't work at 60 FPS, but like I said you must keep the amount of quads at a reasonable level (400 more or less) and at a rather low texture resolution (16x16 should be fine).

The Saturn is also quite good with untextured quads, so you can play with that too.

Pages: 1 ... 11 12 [13] 14 15 ... 23
SMF spam blocked by CleanTalk