Messages

316

Project announcement / Re: Sonic Z-Treme

« on: July 18, 2017, 10:59:43 pm »

Thanks for your comments!

For the LWRAM, it seems you are right according to Yabause! No wonder I always had to fight so hard to cram everything inside the Saturn. I thought files loaded from the disk (such as sounds and images) went straight to the LWRAM, as suggested in the Rockin'B guide.
I looked at the documentation for Jo Engine, and I can't find how to even use it or if there is currently a way (I guess there is, I just haven't found it).
How do I even allocate the LWRAM in Jo Engine?
Audio files would be a good start using it I guess (unless someone suggests otherwise).
Can I allocate more memory to the 3D Meshes, or does it have to go to the High-work RAM?
I'm trying to cram a level from Project AXSX shared by Andrew75, but right now I can't even put half of it as I run out of RAM quickly.
I might have to simplify the map, or find another way to allocate more memory to it.

Btw, Johannes, are you still planning to update the Jo Map Editor tool for the .OBJ conversion? (or release the source)
Right now it's pretty buggy, so I started to learn how to build my own, but I don't want to spend too much time on it as it might not even work with your new 3D implementation. Any words on that as well? Thanks!

317

About you / Re: Hi ! Im Andrew!

« on: July 08, 2017, 05:22:46 pm »

Nice to have you on bord! For the ram usage, it's what I did with Sonic Z-Treme : reuse assets. The mesh/block exists in the ram, all you actualy do is draw it on screen several times. It's really the only way you can put huge levels in these old consoles. The problem with Sonic X-Treme, from my understanding, is that since blocks are small instead of bigger meshes, you duplicate many vertices that the Saturn will need to transform, which takes lot of CPU usage. So you need to find the right spot between ram usage and cpu usage. I think, if I'm right, that the Sonic X-Treme method is too hard on the CPU.

318

Project announcement / Re: Sonic Z-Treme

« on: June 30, 2017, 12:47:16 am »

I know that you are working on a new implementation for 3D, but will the new version be compatible with the current 3d implementation? Like, attributes and all?

319

General Jo Engine Help / Re: Running Jo-Engine Applications on Actual Hardware

« on: June 29, 2017, 08:49:21 pm »

Same problem here. Pseudo Saturn is probably the easiest way to try homebrews, hopefully we will find a solution. Did anyone try to talk with the creators of Pseudo Saturn?

320

Project announcement / Sonic Z-Treme

« on: June 24, 2017, 03:31:19 am »

New update, running 60 FPS on real hardware without clipping glitches!
https://youtu.be/8kfkc7Xa8lk

I'm using SGL directly on this version (I know, I know!) for the VDP2 RBG0 3d plane (the ocean). I have a nice fading effect which worked on SSF, but not on real hardware sadly! (The effect is the same as the fighting SGL demo)

I'm also animating the level (running water) by swapping textures on polygons.

My physics are still bad, but you can see some basic slopes physics.
Overall, I will have to improve the physics, sounds and collision detection engine, but I'm satisfied with the graphical part so far.

One question : Will the next version of Jo Engine support .bin files for the 3d meshes, including loading/clearing?
At the moment, it's holding me back since I can't produce new maps because I can't load them from the disk (unless there is a way that I don't know about).
Thanks!

321

Project announcement / Sonic Z-Treme

« on: May 27, 2017, 12:25:16 am »

New version, running on stock Saturn!
I still have some rendering bugs and some slowdowns, but it's quite playable now and running really smoothly most of the time!


https://youtu.be/e4SUshGYl_I

322

Project announcement / Re: 3D Sonic demo

« on: May 06, 2017, 09:58:45 pm »

Another small update : Jade Gully from Sonic X-Treme in Jo Engine!

There are still many bugs, but I'm getting somewhere slowly but surely.

I managed to do something with my terrible collision detection function, but having more than a few levels will be hard.

Anyway, enjoy : https://youtu.be/mfv6X1YFbYQ

323

Jo Engine Wish List / Re: 3D mesh drawing and collision detection?

« on: April 29, 2017, 05:32:19 am »

No problem, I appreciate all you did so far! I managed to implement some collision detection, but it's not flexible enough. The invisible mesh would probably be the best compromise, but it will take more ram also. I also tried to "call" the polygons, but it didn't go too well, sadly.

324

Project announcement / Re: 3D Sonic demo

« on: April 29, 2017, 05:24:53 am »

Yes, I've also set it to 30 FPS already (value = 2), but it doesn't change anything on emulators, so I just unlocked it back to 60.. which, surprisingly, ran around that on the Saturn. I did a quick update again this week, with fisheye view, new camera and controls, improved model and some REALLY basic (and to be honest, terrible) vertical detection. I might just erase it all next week and try something else as it's really bad, I just did it after finishing work today and I'm surprised it even works. If I can't improve it, I'll just move back to 2.5D gameplay.

Here is the lasted video : https://youtu.be/z5agzrz6G5w

325

Jo Engine Wish List / 3D mesh drawing and collision detection?

« on: April 28, 2017, 07:11:23 pm »

Hi!

While working on a 3D collision detection function, I noticed that it didn't make sense (at least on the CPU) trying to read through all the polygons of a mesh in a loop, only to do 80% of the same work just seconds later to draw these polygons.  It seems like it's wasting ressources. My alternative right now is to hardcode very simple bounding boxes, but it's not as accurate and it creates problems when you consider matrix translations, where the box doesn't follow unless you also code it with a function (like a moving platform). Would it be possible to add a function that does both operations at the same time (while reading a polygon to send it to the vdp1, you also look for a collision with the coordinates you passed while calling the function)? Like, while you are looping through the polygons of a mesh to calculate the vertices and send them to the framebuffer, you also look for a collision with the current caracter's bounding box? Would it be helpful to reduce CPU use?
I hope I'm making sense!
Thanks again!

326

Project announcement / Re: 3D Sonic demo

« on: April 26, 2017, 11:00:58 pm »

Great, I can't wait! I've said it often, but you are doing a really good job, thanks again!

327

Project announcement / Re: 3D Sonic demo

« on: April 26, 2017, 06:51:08 pm »

Ok, so I have a very good news, one not so good.

I tried the game again on actual hardware with extra debugging settings. It's still clipping heavily, but maybe I would just need to increase the size of eveything, but I'm not 100% sure. I put the slZdsplevel/JO_3d_display_level to 3 and by pressing L+R + Start I made it so it switches between the 3 modes. When 2 polygons overlap, it seems like it almost always erase the one in the foreground. For this attempt I put everything in single_plane mode unlike last time, and it seems better now. It seems like it could be an issue with the Z-Sort. Do you guys think it could be related to the SORT_MIN/CEN/MAX polygonal attributes? Or maybe I should just invert all the normals on my models and put it in single plane mode? Could it be both? Or maybe just pushing back the actual camera would help? I don't see other reasons to explain why it's like that, but trying those different solutions would require more time than I currently have. I also tried increasing the view distance, but it didn't change anything.

For the good news : it runs at 60 FPS! I never expected it to run over 40 FPS, but I still left the framerate unlocked just to test.

Video here : https://youtu.be/s7mSQ_l8tM4

ISO attached bellow.

328

Project announcement / Re: 3D Sonic demo

« on: April 26, 2017, 02:57:22 am »

Yes, I have also read that part. The SGL manual is pretty useful. In fact I shrank my Sonic model to the minimum to also allow a good view while also preventing clipping. The Saturn is struggling really badly with huge polygons. It forces me to subdivise the whole map in several small polygons just to prevent the framerate from dropping. I have also added a projection window for far object clipping, which should help. I'll add several debug options for next time I burn a disk and try it on actual hardware. Do you know about a Jo Engine function to get the actual displayed framerate? Or should I just create one?

329

Project announcement / Re: 3D Sonic demo

« on: April 24, 2017, 03:13:07 pm »

Yes, it's all in dual plane. Should I just invert the normals and do it single plane?

330

Project announcement / Re: 3D Sonic demo

« on: April 23, 2017, 05:29:55 pm »

Ok, so I burned a disk and tried on my Saturn and... well, it's just broken on real hardware, but works fine in every emulator. I added a new "feature" to remove some geometry (just press L or R then start). The framerate is also very low, but I'm not that worried about it for now as I still have room for optimization and I'm only using one CPU. The main problem is the polygons keep disappearing. Any ideas on what the problem might be? Even by reducing the number of polygons, it doesn't work well at all. Do you guys think it's the VDP1 that can't keep up, or is it CPU related?

Video of the test on actual hardware : https://youtu.be/_pDlYx9yviU