Jo Engine Forum

Sega Saturn Development => Project announcement => Topic started by: XL2 on March 31, 2017, 01:58:46 am

Title: Sonic Z-Treme
Post by: XL2 on March 31, 2017, 01:58:46 am
Hi!

Here is my Sonic X-Treme remake project on Sega Saturn, running on real hardware :

v.0.071 : https://www.youtube.com/watch?v=Solq-N_jI28

Older version, ran at 60 fps on real hardware :
v.0.034 running on SSF : https://www.youtube.com/watch?v=d1qc8F7xflM&t=7s

Title: Re: 3D Sonic demo
Post by: mindslight on April 03, 2017, 01:45:22 pm
Wow it's very nice  :D
Title: Re: 3D Sonic demo
Post by: XL2 on April 07, 2017, 04:07:00 am
Merci encore pour ton moteur, c'est vraiment super! J'espère que tu vas poursuivre ton bon travail! Je n'en reviens tout simplement pas de tout ce que tu as réussi à accomplir jusqu'à présent!
--

New update here : https://www.youtube.com/watch?v=xF3kpwwG1vk&t=16s
I've modified the game a bit, and I think it looks much better now (the Sonic model is just missing eye textures and I still need to improve the way the arms move while running). I've added some new objects, but I still need to improve the vertical hit detection, add some ennemies and add a real foreground (no idea as for now, I'm still studying the engine). I hope to find a way to use a VDP2 plane to make it a 2.5D game, but I still have lot of work to get there, but little time sadly! 
Title: Re: 3D Sonic demo
Post by: mindslight on April 11, 2017, 04:38:28 pm
Merci à toi :)
Title: Re: 3D Sonic demo
Post by: Danny on April 13, 2017, 10:10:30 am
Your demo is very nice!
I specially like the way you used a 3d model instead of a sprite for the main character ;D.
Title: Re: 3D Sonic demo
Post by: XL2 on April 14, 2017, 04:09:09 am
Thanks both of you.

Here is a small update.

Now the game is all in 3D, but the physics, camera, collision detection and a few things took a huge hit. I haven't figured out if VDP2 plane is supported with Jo Engine. Johannes, can you help me on this one?
I'm still only using one CPU.

Enjoy :
https://www.youtube.com/watch?v=3GgKwrPbWAg 
Title: Re: 3D Sonic demo
Post by: mindslight on April 14, 2017, 02:12:01 pm
See at the bottom of main.c in the shooter demo.

You can run events on the slave CPU, but beware of thread safety
Title: Re: 3D Sonic demo
Post by: XL2 on April 14, 2017, 05:13:08 pm
Sorry, I meant using a VDP2 3D plane (as in several 3d games, like Panzer Dragoon, Virtua Fighter 2, etc.).
Right now, I'm using the VDP1 for the ground, but I would need to add so many polygons to prevent the weird bugs (such as Sonic's feet disappearing).
It would also allow me to have an infinite ground floor, which would make something a bit like Sonic Utopia possible to a certain degree.

As for the slave CPU, I don't want to count too much on it for now as I still have a lot to learn first.
Title: Re: 3D Sonic demo
Post by: Danny on April 15, 2017, 10:00:25 pm
Here is in attachment an old presentation from a Sega Workshop from 95 that should help understand how the CPUs and VPUs work together. If you want I could also take a look at your source code and give you a hand.
Title: Re: 3D Sonic demo
Post by: XL2 on April 16, 2017, 04:23:19 am
Wow, thanks a lot!
I will read that.
Thanks also for your offer for helping me with the code.
I will send it to you by PM (if I can), else I'll just edit and put it here.
Thanks again!

BTW, thanks also for the FPS control demo, I used that in order to get the camera working (with pad 2).
Title: Re: 3D Sonic demo
Post by: Danny on April 17, 2017, 10:16:55 am
I'm glad my code was helpful :)
I have downloaded your project and will take a look at it during the week to help you out.
I'm also working on a method for drawing the 3d environment for my first person shooter game, I have been researching about binary space partitioning, quadtrees, octrees and portals to see what will be most useful.
Once I have something nice to show I will share it because surely it will be reusable on almost everything that needs a 3d environment  :P
Title: Re: 3D Sonic demo
Post by: XL2 on April 21, 2017, 09:39:26 pm
After one month working on this project, here is a full 3D update. I imported the intro level from Mario 64. Still using only one CPU (the game slows down as you can see) and my collision detection is really really really basic (only X/Z, using hardcoded bounding boxes, still no Y collision detection at the moment).
I didn't succeed yet in implementing a polygon-based collision detection (I would just cover the level with invisible huge bounding boxes/planes and detect collision on them) and I'm not sure if there is a way right now without using SGL.

As you can see, I didn't texture map the level (except for the ground floor) and I didn't add extra geometry on the ground (which I should to prevent the texture warping). Once the collision detection works correctly I'll be able to move to objects/ennemies implementation. I'm also considering adding tails following Sonic. In both cases that means I need to learn some AI programming. For the levels, I think I might try to randomly general levels at one point, which might be better than trying to create several levels. But, that's still far off!

EDIT : I just did a small texture map test, but I'm using the level from the DS version, which has extra geometry.

Video here : https://youtu.be/RdzAl7iSfsI
Title: Re: 3D Sonic demo
Post by: XL2 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

Title: Re: 3D Sonic demo
Post by: mindslight on April 24, 2017, 08:46:05 am
This is due to the 3D implementation in the SGL. Did you use the DualPlane mode ?
Title: Re: 3D Sonic demo
Post by: XL2 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?
Title: Re: 3D Sonic demo
Post by: Danny on April 25, 2017, 10:28:18 am
It seems to me the problem is the polygon clipping when you get close because when you are far away everything seems to be shown fine  ???
You could try to use jo_3d_display_level() to adjust the near clipping but I'm not entirely sure if that will fix it, it might also be a problem somewhere else.
The jo_3d_display_level()  is an abstraction of the slZdspLevel, the parameters work like this:

jo_3d_display_level(level)

example values for level:
1: Display from 1/2
2: Display from 1/4
3: Display from 1/8
I have an image file as attachment that helps explain this.

Edit:
I did some tests with this and although this function is helpful the problem might not be related, because on your video some things that are close do not disappear while others do.
Title: Re: 3D Sonic demo
Post by: XL2 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?
Title: Re: 3D Sonic demo
Post by: XL2 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.
Title: Re: 3D Sonic demo
Post by: mindslight on April 26, 2017, 10:26:35 pm
My 3D implementation will be different from the SGL. Maybe the results will be better. I will release a beta in 2 weeks  :)
Title: Re: 3D Sonic demo
Post by: XL2 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!
Title: Re: 3D Sonic demo
Post by: Danny on April 29, 2017, 01:14:35 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?
Sorry friend, I have been busy at work and havent had much time to check up the forum, I'm not sure but I don't think there is a function for that, however you can set up the processing time of each frame on conf.h by changing JO_FRAMERATE to a slower framerate, this way the vdp1 has more time to draw stuff(I think). I know this does not help you much but I remembered it might be helpful although the conf.h file says "DONT TOUCH THIS FILE" xD.
As for measuring the cpu time you could use the clock tiks like i did in the dual cpu usage example  ???.
Title: Re: 3D Sonic demo
Post by: Danny on April 29, 2017, 01:22:39 am
My 3D implementation will be different from the SGL. Maybe the results will be better. I will release a beta in 2 weeks  :)
That is really good news, thank you very much Johannes!
I have been trying to implement a 3d space partitioning based on portals and maybe octrees (i'm still learning) and I'm using the PDATA and XPDATA SGL native structures for the polygons, will you still use them or make some new structures for this?
Title: Re: 3D Sonic demo
Post by: XL2 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
Title: Re: 3D Sonic demo
Post by: XL2 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 (https://youtu.be/mfv6X1YFbYQ)
Title: Re: 3D Sonic demo
Post by: mindslight on May 07, 2017, 09:30:40 am
Amazing  :D

In my side, the SGL replacement goes well. Maybe I will release a new version next week  :)
Title: Sonic Z-Treme
Post by: XL2 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
Title: Re: 3D Sonic demo
Post by: mindslight on May 27, 2017, 10:20:06 am
Wow  :D

I hope to finish the new 3D implementation next month. My job took me a lot of time and also my daughter  ;D
Title: Sonic Z-Treme
Post by: XL2 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!





Title: Re: Sonic Z-Treme
Post by: mindslight on June 29, 2017, 08:08:24 pm
Mesh loading is on the todolist.

It's hard to find enough time to work on Jo Engine, but the holiday is coming :D
Title: Re: Sonic Z-Treme
Post by: XL2 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?
Title: Re: Sonic Z-Treme
Post by: Andrew75 on July 08, 2017, 01:01:42 am
Heya ! Andrew75 here From Project AXSX. Anyhow, I was wondering if you had Skype. I think it would be easy to transfer Models and such threw there. I think before I send the model we need to get scales established. Scale is very important !

Maybe we can try to send a few cubes back and forth until we get the scale difference figured out between 3DS max which I use, and blender which you use. I'm sure you are familiar with the scale you need. but I hope to be brought up to speed so as any asset I send will be game ready as possible.
Title: Re: Sonic Z-Treme
Post by: corvusd on July 11, 2017, 09:54:15 pm
Edit - Like you can see here, the game progressed nicely, while there is still a lot to do, I now have a full 3D level with collision detection, physics, BSP, etc.
Demo attached (v.0.02)  (You will have to convert the MP3 files to WAV or change the cue sheet to make it work with MP3). There are some bugs in the demo that I'm aware of, such as the NBG2 background (hidden by the RBG0 plane) being "corrupted" and having poor contrast, the game only plays one sound at a time (I need to learn how to properly downgrade audio from 44100 HZ to 11025 mono) and there is a weird bug with the Sin/Cos functions (not sure if the problem is at my end) where the negative return bigger values when it's under 1 (even if I use floating points) which makes Sonic go faster in some directions than the others.

Newest version here, running on stock Saturn :

https://www.youtube.com/watch?v=WFaLo6XWmWo&t=1s (https://www.youtube.com/watch?v=WFaLo6XWmWo&t=1s)

Hi XL2, absolutely great job! :D

I see you've used the Color Calculation whit a Color Calculation Ratio = 31:1 on the NBG3 layer. A kind of fog over the image of the mountains. In the video of youtube in the real SS and in medanfen the effect is not seen. But in Yabause and SSF yes, show OK. Is it possible that you are missing something else in the VDP2 for this effect to look good in most real machine code?

The ground rotated work well, as you told me. It possible improve the final image, We find the way, but for now great work!

I also see that you do not use the LWRAM, is it because of some limitation? I ask out of curiosity :)

Finally I see that you have used the Mesh mode in the shadows and the explosions of enemies. It has been very well. Now it's easier to jump :)  Next step, find way use VDP1 Half transparent, if not penalize much.

By way of suggestion. At levels where you have to go very far and do not draw the stage, it could be a problem. You should design them knowing this limitation well. Or add a fog effect to increase the drawing distance a little more. An effect like in Sonic R maybe? I think what it does is to use the "trick" that the sprites in the background go to color bank of VDP2 and activate the MDB bit mode "1" so that it is the VDP2 that does the transparency.

Nothing more, I encourage and we keep in touch! :)

Regards!

David G. J.
Title: Re: Sonic Z-Treme
Post by: XL2 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!
Title: Re: Sonic Z-Treme
Post by: corvusd on August 14, 2017, 09:30:10 pm
Hello everyone!!

Sorry to take so long to respond. I am involved with various issues and work.

As I commented in several posts, I have pending various documentation that I have been developing for a series of entries in my personal blog.

The intention I have is to share and help grow the community of our great console. A small contribution and tribute to this great machine. Which he owed for a long time.

I share a spreadsheet where I am compiling technical data of a selection of games(200 aprox 20% total games)  that I think are outstanding of the system. That can help us to better understand how effects were made or how they used the machine better. Currently this half-translated into English, since my native language is Spanish.

UPDATE table and data at 02-12-2017, view beetter whit 75% zoom level in google docs viewer:
https://docs.google.com/spreadsheets/d/1tcTUC9oZ70ZGzVV58ca20bfwn0YEWzyJbxAMVFrAVwE/edit?usp=sharing (https://docs.google.com/spreadsheets/d/1tcTUC9oZ70ZGzVV58ca20bfwn0YEWzyJbxAMVFrAVwE/edit?usp=sharing)

With respect to the use of memory, it has been one of the last aspects that I am compiling. They are in column AA. I have tried to break them down by the different memory wells. The data is approximate, since even the Yabause does not quantify in total values ​​the use of memory.

I started by analysing the use of transparency of VDP1, VDP2 and VDP1 + VDP2. Afterwards, with depth of color in textures and total, use of gouraud and lighting, use of layers of VDP2 and color calculation ... to gradually embrace many aspects.

It would help a lot, that Yabause not count the number of elements in the VDP1, to see how many polygons are on the scene. Or the amount of elements that are using Gouraud, or half-transparent, filter them somehow. Since the debugger lists them all and their properties. Or ideally show the % use of the processors, this last more complicated.

I will update and translate the sheet as I can. If someone wants to contribute in the edition only that asks me, the more we are better.

Regards! :)
Title: Re: Sonic Z-Treme
Post by: mindslight on August 15, 2017, 07:11:35 pm
Your help is welcome :)

There is still time to revive the Sega Saturn.

I am pleased that they have more and more people who are interested in our work.
Title: Re: Sonic Z-Treme
Post by: corvusd on August 27, 2017, 08:16:32 pm
Hello Johannes,

Sorry to answer you so late Thanks for your words.

I hope we succeed. This community and the machine deserve it.

I have been updating data from the table. There are still many things in Spanish. I hope to be able to translate and complete the analysis of the games.

If you like, I open thread in the forum share code share. It is not the same, but I think it will be more at hand, to be able to consult games that do specific things and how. That is the end of the spreadsheet.

Regards,
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on September 04, 2017, 04:08:22 am
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!

Someone that  would know probably is Jolly roger, il pm him and ask if he knows
Title: Re: Sonic Z-Treme
Post by: XL2 on September 04, 2017, 05:32:02 am
No need, it's all working already.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on September 04, 2017, 06:34:53 am
Oh okay 8)
Title: Re: Sonic Z-Treme
Post by: XL2 on September 14, 2017, 05:07:57 pm
Small update, now using a map from Project AXSX (thanks to Andrew75) :
https://youtu.be/UDzUXsTSKk4
Title: Re: Sonic Z-Treme
Post by: mindslight on September 14, 2017, 05:18:49 pm
Good job ! ;D

Project AXSX is a very nice project too :)
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on September 15, 2017, 02:45:05 am
Amazing!  ;D cant wait to try it!
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on September 15, 2017, 07:10:40 am
Hey man was just wanting to say keep up the great work with Z-treme as its a dream come true for a die hard Saturn fan. Just as a heads up just got 80 new cd=r so if you need anything tested on real hardware im  up 8)
Title: Re: Sonic Z-Treme
Post by: mindslight on September 15, 2017, 09:11:38 am
Hey man was just wanting to say keep up the great work with Z-treme as its a dream come true for a die hard Saturn fan. Just as a heads up just got 80 new cd=r so if you need anything tested on real hardware im  up 8)

I also have some old 650 MB CDs :)

Once in two the engraving fails, because they are over 15 years old :D
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on September 15, 2017, 07:33:02 pm
Yeah! cant wait to download it and try it out! ;D
Title: Re: Sonic Z-Treme
Post by: XL2 on September 16, 2017, 01:05:58 am
 Right now it runs between 30 and 60 fps on real hardware, so it's not really playable, so I will have to optimize everything first.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on September 20, 2017, 03:11:19 am
I am curious on something, why would there be a big hardware performance difference between the Saturn and a emulator? As someone who programmed for the Saturn i know the emulator has some minor difference when making something with screen tearing ect but why for fps? Also its okay if does not run at 60, few games at the time did and a stable 30 is just as good ;D Keep up the good work!
Title: Re: Sonic Z-Treme
Post by: XL2 on September 20, 2017, 03:20:54 am
The problem is that when the CPU can't keep up, it drops one frame, so your game logic goes down to 30 fps. So it's going from 60 to 30 to 60, making the game hard to play. I have a few ideas for preprocessing the visibility. My hard limit seems to be around 1100 vertices on screen, the game now goes from 700 to up to 1600 sometimes, so it's uneven. Of course, there are 2 cpus, but sending the draw command to the slave doesn't help that much (SGL slPutpolygonS). I could probably brute force my way to 60 fps by alternating the matrix transformation between slave and main CPU, but I want to optimize everything and keep some room for extra effects. The main problem for high vertices count is the way that by subdividing a map for culling you duplicate many vertices, putting a strain on the CPU.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on September 20, 2017, 06:37:31 pm
Thanks for responding :) that makes alot of sense, i also did not realize how much of a difference those 30 frames meant to this game. I was just thinking about how Sonic Adventure, Shenmue, Nights, Panzer Dragoon Series and other games at the time ran at solid 30 and where still fun. Was suggesting that so you wouldn't have to work as hard 8)
Title: Re: Sonic Z-Treme
Post by: XL2 on September 20, 2017, 06:52:58 pm
Well, I could just put it at 30 fps and it would run fine, but my whole game logic is at 60 fps, so it's some work too since at 30 fps it's like a slow motion game. So I prefer to spend time optimizing the game first, and if that's not enough I will downgrade to 30 fps and just add more effects
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 01, 2017, 06:03:34 pm
Just noticed something in your new builds of jade gully zone. The floor texture looks like transparent water! Was wondering how you achieved this effect as it look really good! 8)
Title: Re: Sonic Z-Treme
Post by: XL2 on October 01, 2017, 06:12:11 pm
I tried to make it look like it's a reflection more than transparency, but it is indeed transparent with the background flipped. The VDP2 has no problems at all with transparency, only the VDP1 does. I want to try some sort of VDP1 transparency by using the VDP2 (like make objects fade in/out instead of poping in/out), but I have many things to do first. It seems to work only with paletted sprites, so I need to test that as well.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 03, 2017, 02:47:01 am
It will be very interesting to see how the effect translates over to original hardware and if "Lines" somewhat blur it up. Im sure that is mostly down to what video output you use though, aslo heard you got Crystal frost working! any chance you could lend a screen shot  ;D
Title: Re: Sonic Z-Treme
Post by: XL2 on October 03, 2017, 03:10:25 am
I will show it soon enough.
I'm trying now to optimize everything to try to make it work at 60 fps, but it's not easy!
And at 30 fps it feels so floaty and I would need to change my game engine logic, so both ways are lot of work.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 03, 2017, 04:02:43 am
I will show it soon enough.
I'm trying now to optimize everything to try to make it work at 60 fps, but it's not easy!
And at 30 fps it feels so floaty and I would need to change my game engine logic, so both ways are lot of work.

Haha no need to rush, it will be done when it is done ;) Sorry if i sounded demanding, did not mean to be
Title: Re: Sonic Z-Treme
Post by: XL2 on October 03, 2017, 04:11:35 am
No problem, I'm just in a rush to get a build for Retro Barcelona and I'm trying to throw all the optimizations I can think of to make it work as it's in 3 days only...
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 03, 2017, 04:44:56 am
No problem, I'm just in a rush to get a build for Retro Barcelona and I'm trying to throw all the optimizations I can think of to make it work as it's in 3 days only...
Well if you need me to do any testing or testing on a real console im available, youl win easily  ;D (PS what is Retro Barcelona? 8))
Title: Re: Sonic Z-Treme
Post by: mindslight on October 03, 2017, 10:38:09 am
(PS what is Retro Barcelona? 8))

It's an event in Spain inside the Barcelona Game World (http://www.barcelonagamesworld.com/ (http://www.barcelonagamesworld.com/)), one of the biggest video game event in Europe.

Website: http://www.retrobarcelona.org/

And the topic on the forum: http://forum.jo-engine.org/index.php?topic=825.0
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 04, 2017, 04:32:50 am
Very cool! so is there a competition held there or a showcase for projects? if so XL2 will win for sure!
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 06, 2017, 07:02:17 am
https://www.youtube.com/channel/UC-U3sMVXNwNkk8Zgs4JPmng
Jade Gully &Crystal frost
Title: Re: Sonic Z-Treme
Post by: XL2 on October 06, 2017, 06:28:54 pm
I posted a demo here, it was rushed and not properly tested in order to make it for Barcelona Retro (I only had a 3 days heads-up). I also changed the controls a bit in version 0.034, hopefully it makes diagonal movement more reliable (preserves momentum now). I also made the acceleration a bit faster to compensate the longer turn time. Hopefully this version should run well 95% of the time, with some slowdowns and some collision bugs in some areas (again, 3 days only!)
Title: Re: Sonic Z-Treme
Post by: mindslight on October 06, 2017, 07:01:56 pm
I sent the new update to my friend Alfonso at retrobarcelona  show
Title: Re: Sonic Z-Treme
Post by: null1024 on October 07, 2017, 02:33:16 am
Seems to work fine in SSF. Couldn't boot it on my Saturn with Pseudo Saturn Kai (and latest Jo-Engine supports it if you add JO_PSEUDO_SATURN_KAI_SUPPORT to the makefile), so I'd have to do the swap trick later to try it out.
Title: Re: Sonic Z-Treme
Post by: XL2 on October 07, 2017, 02:40:57 am
Yeah, I didn't have time to update sadly. I will do it later this weekend.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 07, 2017, 08:07:13 am
Did not realize you had to add that bit of code 8)
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 08, 2017, 07:20:48 am
If XL2 is interested in seeing the feedback from the spam of topics i made in various Sega forums here is a quick list of some of the ones i did (if you want to see feedback)

obviously did XL2's posts in Assembler, Sonic Retro & Sega Xtreme

Official Sega forums
http://forums.sega.com/showthread.php?1073177-New-Sega-Saturn-Homebrew-Sonic-Z-Treme

Dreamcast-Talk
https://www.dreamcast-talk.com/forum/viewtopic.php?f=18&t=10609

Andrew75's forums
http://www.sonicxtreme.com/forums//viewtopic.php?id=1119

Segabits
http://www.segabits.com/forums/index.php?topic=4299

I think those are all the ones i have done for now, Did not have time to write anything fancy but i thought the project needed some"marketing"
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 08, 2017, 08:03:47 am
Also this might be too much to ask but maybe for a next test level we could try this one?
https://www.youtube.com/watch?v=6IOd0mQ-uXE
Im not sure what you have planned next (Im sure its mostly optimizing the code ect) or what levels Andrew has giving you (He might not even have this one) but its always one iv wanted to try it 8)
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 09, 2017, 12:17:18 am
Only been a few days and the ztreme video has hit over 1000 views and the older one i did has hit 5000 almost!
Title: Re: Sonic Z-Treme
Post by: XL2 on October 09, 2017, 01:07:52 am
He doesn't have this level sadly. I also wanted it.  I guess I will have to recreate it
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 09, 2017, 07:04:40 am
Thats too bad, well what ever is easy for you im down! (Maybe Red sands next? that be a good one to show groud Shading if you aiming for that still with the fire on the torches ect)
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 09, 2017, 11:13:48 pm
Someone talked about Z-Treme!
Have no clue what he said but thought i mention it

http://www.youtube.com/watch?v=K6lzK8GW9vA&t=440s
Title: Re: Sonic Z-Treme
Post by: Cerv3ro on October 11, 2017, 12:30:26 am
Many thanks to XL2 for this awesome proyect, you are the man! , i hope you grow up as programmer while you do this. And also many many thanks to mindslight por creating this unique and incredible tools and engine. The Saturn scene never has been so alive.
Thanks also to the rest of people working in the shadows triying to the best.
Title: Re: Sonic Z-Treme
Post by: neoraph on October 11, 2017, 03:26:29 am
Hi,
I also opened a topic in sega-mag, a french web site for sega fan (I am part of the team and I work as a web developper here) about the jo-engine, and also talk about Sonic-Ztreme :
http://www.sega-mag.com/forum/sujet-Jo+Engine+++SDK+pour+developper+sur+Saturn-1972-3-1.htm
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 11, 2017, 05:17:28 am
Very nice :D you should make an update showing off Xl2's & my new videos with the latest builds. ;D Sadly seems that some people where bashing it for no reason other than "its Sonic". Never understood that type of criticism. Just because im not a Mario fan does not mean i have to scoff at projects because tt has Mario in it :/
Title: Re: Sonic Z-Treme
Post by: XL2 on October 11, 2017, 06:09:02 am
I think many people fail to realize that assets don't create themselves. Coding is complicated enough, spending more time on 3d models, textures, sound, etc would make the project impossible to complete. At first I didn't want to make a Sonic game, I thought I would do a beat them up (which is why Sonic had a fighting stance in my earlier demos), but I just ended doing this game once I started adding elements in it.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 11, 2017, 07:00:09 am
As someone who has created 3d models i know who hard it is making detailed textures from scratch. I mostly used pre made textures and when i made xtreme models i simply copied assets over to make life easier.
Title: Re: Sonic Z-Treme
Post by: mindslight on October 11, 2017, 12:42:14 pm
The same thing happened to me, but in a different way :P
When I started to develop the Jo Engine, I used a lot of SGL functions and many people says that it's not an homebrew, just an SGL wrapper.
I don't agree with that, because if you used the SGL, you are in the same conditions as the developers in 1995.

Do you think the developers had time to rewrite everything ?
Of course not. It is already hard enough to develop a game.
In computer science, this has a name: Reinventing the wheel. ::)

Furthermore, my primary goal is not to replace the SGL, but help people to create games on the Sega Saturn.
Otherwise, what is the purpose of replacing SGL ?

On the other hand, if you are interested in programming closer to the machine, there is an excellent library : libyaul

Today, I have enough backwards to replace the SGL not because it's not homebrew, but because I want a lightweight engine with only useful features.

That's the reason why I made an option on the Makefile (JO_COMPILE_USING_SGL) to let developers choose whether or not to use SGL features  ;)

Title: Re: Sonic Z-Treme
Post by: Cerv3ro on October 16, 2017, 01:38:43 am
Hey XL2, i´ve probed the 0.035 v in my Saturn and let me tell you...this is something f... awesome. Really a great work you are doing with this engine.
I want to let you here my impressions:

The demo has no music and sometimes the sounds effects are missing, for example when you collect a ring or hit an enemy.

When jump, the sound doubles. I have tried to turn on the 60 Hz mod in my Model 1 Pal Saturn and this effect is corrected but some grafic bugs appears and some issues with the frames that goes down.

IMO, the colours are very intense and bright, maybe with less pure colours the game looks better, is only an idea.

Also i´ve noticed that you can swith between 2 different cameras and hud. Interesting.

In the first level the water don´t hurts you but it does on the second one.

i´m looking forward to your progress.
Title: Re: Sonic Z-Treme
Post by: XL2 on October 16, 2017, 03:52:36 am
Thanks !
For the music, it's included, make sure you use the cue sheet and your img burner supports it, else convert to .wav.
The sound issue is known, I'm having issues with Jo engine sound play back which causes issues and crashes when I use the function to use whatever channel is available, so only 1 sound is being played, max 2 in some cases.

I never used a PAL Saturn, so I don't know, but the framerate on NTSC Saturn should be at 60 fps around 95%. I didn't have time to improve my engine in time for Retro Barcelona, so I couldn't do better. I am working on fixing this.

For the camera and HUD, those are debug functions "hidden" when you press L+R and other buttons. They lead to some issues, so avoid them.

For the water, it's not a bug : the second level's water is supposed to be freezing cold, so it hurts Sonic.

For the colors, I'm using the original assets from Sonic X-Treme, so I can't do much. Try playing with your TV's settings until you get a good image.

What graphical bugs did you get? I think the clouds could lead to issues, but I haven't tested enough to know.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 16, 2017, 06:24:52 am
ver .35 on my Saturn works perfectly with music and all (haven't had the time to record gameplay of it yet) and playing it on my Saturn the colors are fine. Like XL2 said you need to select the .cue when burning it (i use imgburn) otherwise it wont right the music files on the cd. You can also change the music files to whatever you want too. I have to say it again XL2 did an amazing job :)
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 17, 2017, 02:21:16 am
Hey XL2 Just to clarify, the water effect in the new .35 build actually uses transparency right? Due to how much you have to correct me in the comments section of the videos i want to make sure i get all the facts right. Thanks
Title: Re: Sonic Z-Treme
Post by: XL2 on October 17, 2017, 02:27:15 am
It's VDP2 transparency, which is easily supported by the Saturn. The problem is with vdp1 (polygons).
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 17, 2017, 02:48:37 am
Okay thanks, tomorrow afternoon im going to try and make a video on .35 and will send a private link to you so you can look at it and make sure its up to your standards. Really sorry again for all the errors i made :-\
Title: Re: Sonic Z-Treme
Post by: XL2 on October 17, 2017, 03:04:47 am
As long as you don't say you did this game, there shouldn't be any issues ;)
For me v.0.035 is buggy and I'm having loading issues.
Can you confirm that crystal frost loads fine and you're not having glitches?
If so just post it public right away.
I'm changing my loading mecanism for faster loading (pre-swap endianness and not using buffers) and will integrate paletted sprites for extra VDP2 effects on polygons (such as transparency)
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 17, 2017, 03:10:41 am
Yeah no clue what i was thinking with that "us" (think i was really tired that day)
Crystal frost work fine for me as the screen tearing was fixed for it in that release. Il also do a side by side comparison for the loading times
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 17, 2017, 03:45:39 am
Also one more question XL2, there is a new Saturn site going up right now that rebuilds the Netlink Zone and also will have sort of a homepage for Saturn users. It will have a "News" section on the going ons in the Saturn scene. Like the new unreleased game that was recently dumped or new stuff in the homebrew scene. And me and the runner of the site where wondering if i could take some screenshots of the current builds and send them his way so update the page. The site is only really usefull when viewd on the Saturn so it be cool to take some screenshots into good old jpg 128 (like this https://web.archive.org/web/19970215191106/http://www.gamefan.com:80/download/saturn/sonic_x-treme/index.html) You can view part of the site here if your wondering
http://saturn.dreampipe.net/
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 25, 2017, 07:43:35 pm
Did another topic in the Radio Sega Fourms, any other places/ fourms you think people would enjoy it?

https://www.radiosega.net/forum/showthread.php?4188-New-Sega-Saturn-Homebrew-Sonic-Z-Treme&p=62028
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on October 25, 2017, 08:15:08 pm
Did another one in the sonic Stadium

https://board.sonicstadium.org/topic/22977-fangame-new-sega-saturn-homebrew-sonic-z-treme/
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on November 01, 2017, 10:03:39 pm
Because some asked for it here is ver 0.35 with my custom tracks i made ::)
http://www.mediafire.com/file/vbmlybhsq58sgep/SONIC+Z_TREME+0.034+%28Custom+Music%29.zip
Title: Re: Sonic Z-Treme
Post by: XL2 on November 01, 2017, 10:05:53 pm
0.35 is super glitchy, so I removed it. I'm working on a new 3d implementation (again!) for more speed. It might take a few more weeks.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on November 03, 2017, 03:27:39 am
Gota go fst :o On a side note you want me to remove my custom version?
Title: Re: Sonic Z-Treme
Post by: XL2 on November 03, 2017, 03:43:49 am
0.034 was more stable, so I would suggest using that instead until I release 0.036 or 0.04 (If I nail the 3d implementation )
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on November 03, 2017, 06:16:26 am
Will change it when i have time, hope all goes well for the project in the next few weeks 8)
Edit: Done, and on another side note ver 0.32 video has hit 6 thousand views! and the old ver .2 video i made has almost hit 7000. Its great that more people are finding out about your project XL2
Title: Re: Sonic Z-Treme
Post by: LekBr20101 on November 07, 2017, 01:19:37 am
Hi!

Here is a short demo of a 3D Sonic game made with Jo Engine. Based on the Sonic demo, I made the 3D model and then animated it (hardcoded). It's still very buggy and as I had no previous coding skills and never made a game before, I don't expect to turn this into a full game. The demo is running on SSF, it does also run on Yabause.

v.0.034 running on SSF : https://www.youtube.com/watch?v=d1qc8F7xflM&t=7s


Edit : v.0.035 below. Added the RBG0 ocean and clouds in Jade Gully. The clouds are rather large, they might impact performance on real hardware, but I didn't try it so I don't know. I also tried to improve the loading time, but I didn't test it. Jade Gully should load about twice as fast now, while Crystal Frost should load in around 35 seconds (I will try to improve that as well). Again, I didn't test on real hardware, so it might not work at all, try at your own risk!

Edit 2 : Removed 0.035 as it contains a couple of glitches.

Playing I noticed some problems: 1-it gains speed very quickly, but loses it very slowly.
2-You could remove the double leap and add a single, but slow leap.
3-In the first phase could have the addition of more parts, a 3 or 4 would be welcomed.

If you want, I'm going to try to make some conceptual arts to try to help you.
Title: Re: Sonic Z-Treme
Post by: LekBr20101 on November 07, 2017, 01:21:30 am
I'll see if I can find the order of the songs and the phases on the Internet, and of course, their themes respectively.

How are you doing the modeling of the characters?
Title: Re: Sonic Z-Treme
Post by: XL2 on November 07, 2017, 08:54:29 pm
I don't know what you mean about the speed. If you mean the momentum, it's normal, there is friction but the engine keeps your speed.
The single slow jump could be terrible and make the game feel like you are under water.
So I won't do it.
For your point 3, the game is not finished, but adding levels isn't a priority since I'm busy working on my engine.
Title: Re: Sonic Z-Treme
Post by: LekBr20101 on November 07, 2017, 11:08:38 pm
I don't know what you mean about the speed. If you mean the momentum, it's normal, there is friction but the engine keeps your speed.
The single slow jump could be terrible and make the game feel like you are under water.
So I won't do it.
For your point 3, the game is not finished, but adding levels isn't a priority since I'm busy working on my engine.


I understand, about speed is much more about the high speed gain itself, for example, in the Sonic of Genesis, using the trees behind in Green Hill as base, starting from the first if it reaches the maximum speed in the seventh, however in the project the gain is very high. Thinking about it might be the scenarios that are very small, it would be possible to put some areas for testing in the future.

On the leap I do not know, using Sonic 2D as an example, Sonic's jump is about 3 Sonics above him, I'm thinking on the side of breaking the game itself, jumping from one side to the other of the map and finishing the phase in 20 seconds seems a bit sad.

On performance the game has its downfalls, but it seems that in the next update you will lock the frame rate at 30fps, maybe even improve the rendering of the game.

Returning to talk about the jump, Sonic X-Treme was going to have phases differentiated for each character, but I do not know, maybe it's better to create a single phase with different paths for each character, maybe save time.
Title: Re: Sonic Z-Treme
Post by: LekBr20101 on November 07, 2017, 11:10:35 pm

I do not know exactly how to move 2D to 3D, maybe it's better to wait for the engine to get ready.
Title: Re: Sonic Z-Treme
Post by: XL2 on November 07, 2017, 11:19:29 pm
For the acceleration, I played with different settings and found it better to have a bit faster acceleration, which makes turning in 3d easier.
For the jump, I'm using the same value as classic games. The only difference is that the camera tilts as you jump.
For the slowdowns, I mentionned it before, I'm fully rewriting my 3d implementation for stable 60 fps.
I did the demo for Retro Barcelona in 3 days, the engine wasn't fully ready.
For other caracters, I'm not considering it atm.

For you waiting for the engine to be ready, I don't think I understand what you mean.

If you mean Sonic Z-Treme engine, I won't be making it public. But I might update the fps demo.

If you meant Jo engine, Johannes is working on a new implementation, but you can fully use SGL at the moment.
Title: Re: Sonic Z-Treme
Post by: LekBr20101 on November 08, 2017, 12:08:44 am
For the acceleration, I played with different settings and found it better to have a bit faster acceleration, which makes turning in 3d easier.
For the jump, I'm using the same value as classic games. The only difference is that the camera tilts as you jump.
For the slowdowns, I mentionned it before, I'm fully rewriting my 3d implementation for stable 60 fps.
I did the demo for Retro Barcelona in 3 days, the engine wasn't fully ready.
For other caracters, I'm not considering it atm.

For you waiting for the engine to be ready, I don't think I understand what you mean.

If you mean Sonic Z-Treme engine, I won't be making it public. But I might update the fps demo.

If you meant Jo engine, Johannes is working on a new implementation, but you can fully use SGL at the moment.

About modeling I would like to help you in something, however I am the ultimate noob form in programming, maybe in modeling or stuff like I can do something.

Yes, I understand, unfortunately I couldn't go to Barcelona, it would be annoying to cross an ocean to access a DEMO, however I can wait for the next video on the canal.

In fact, I saw that you used the stage created by a fan as the first stage, or did you create this internship a couple of years ago?
Title: Re: Sonic Z-Treme
Post by: XL2 on November 08, 2017, 12:12:05 am
Sorry, but I'm not looking for help at the moment and don't want to use other people's models.
The stage is from Project AXSX, that Andrew75 recreated after Sonic X-Treme's maps.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on November 08, 2017, 10:05:18 pm
Hey Xl2 just a quick question, so are you just rebuilding the Engine from the ground up with a retooled gameplay style or just modifying/ cleaning up the original code? If you want to keep it a secret until you show it off that's okay was just a little confused
Title: Re: Sonic Z-Treme
Post by: XL2 on November 08, 2017, 11:31:54 pm
I'm rebuilding the 3d implementation and reworking on the collision detection code.
It might take a while.

I'm using Saturn Quake levels to stress test the engine, but since I haven't updated the FPS demo, it gives some weird results like this (I should add a shotgun and turn Sonic into Shadow and just call it Shadow Z-Treme, I'm sure that would be a wonderful idea!) : 
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on November 09, 2017, 01:50:33 am
Looking good, the cross over we all wanted 8) Did not know the quake Saturn maps where available in .3ds or .obj format
Title: Re: Sonic Z-Treme
Post by: XL2 on November 09, 2017, 01:52:05 am
I converted them to .obj and then to .ztm.
Title: Re: Sonic Z-Treme
Post by: mindslight on November 09, 2017, 06:34:05 pm
Sonic on Quake level  ;D OMG  :D
Title: Re: Sonic Z-Treme
Post by: LekBr20101 on November 09, 2017, 11:59:10 pm
Sonic on Quake level  ;D OMG  :D

Quanic
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on November 11, 2017, 03:28:33 am
Hey Mindsight does Jo Engine support the 3d controller now? would be interesting to see Z-Treme use it
Title: Re: Sonic Z-Treme
Post by: XL2 on November 11, 2017, 04:36:25 am
It doesn't support yet, but you can use the SGL/SBL functions directly.
Title: Re: Sonic Z-Treme
Post by: LekBr20101 on November 11, 2017, 11:24:30 pm
ohh GOD!!!

https://www.youtube.com/watch?v=_Vjg3OVC5CY

Sounds perfect
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on November 14, 2017, 08:43:15 am
Hey XL2, did anyone ever contact you back about the Sonic & Sega Fan Jam?  was just wondering as its going to start soon (think the 18th)
Title: Re: Sonic Z-Treme
Post by: LekBr20101 on December 01, 2017, 04:44:59 am
Hey XL2, I'm reading your interview on a site called SEGA nerds, I'm finding it very interesting, your interviewer is a Brazilian who is, as well as me, rooting for your project!
Title: Re: Sonic Z-Treme
Post by: NeoSnk on December 01, 2017, 04:55:32 am
Hahaha I did the interview! And of course Im rooting for this project! This is amazing ;)

http://www.seganerds.com/2017/11/30/the-sega-saturn-is-finally-getting-a-3d-sonic-game/
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on December 02, 2017, 02:50:18 am
Great job XL2 on the interview! Glad to see your project getting more attention, you deserve it! 8) Also cool to see another fellow Canadian who actually has a Saturn  ;)
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on December 09, 2017, 01:36:37 am
Hey XL2 how's development going!
Title: Re: Sonic Z-Treme
Post by: XL2 on December 11, 2017, 01:03:32 am
Slowly, I'm almost rewriting everything.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on December 11, 2017, 01:30:08 am
Slow and steady wins the race, cant wait to see what the new versions look like
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on January 20, 2018, 07:21:30 pm
Hey XL2, how's the development going?

Also one quick question, iv been getting lots of questions recently on what role vdp2 has on the game, seems weird to me that lots are suddenly asking but could you give me an answer that i could tell them?

Have a great day! ;D
Title: Re: Sonic Z-Treme
Post by: XL2 on January 24, 2018, 07:34:38 am
Right now I put Sonic Z-Treme on hold to focus on occlusion culling using the FPS demo for testing.
I got the auto-LOD model generation working (but I haven't implemented texture generation yet) which should help with better draw distance.
I also got the 4 bits per pixel textures working, saving me some VRAM that I'll use for LOD textures.
I added analog control (not even properly documented in the official documentation) in the FPS demo.
I implemented a KD tree... then tried a BSP tree... now I'm going for an octree...but feel like going back to a BSP tree...
I also wasted a couple of weeks trying to implement a mesh buffer to save RAM and reduce vertices transformation, but the memory access made it slower so I flushed it.
I still need to find a way to generate PVS and cram it in the little bit of RAM left... or go for the BSP tree and use a low-res depth buffer (should be slower, meaning 60 FPS would be impossible).

I'm working on a new collision detection code and PVS, and I need to find a way to use the audio RAM to free some work RAM.
Quake maps are loading, maybe I'll be able to show the new FPS demo within 2 months, but I'm confident that I'll hit 30 fps with gouraud shading.

Long story short, occlusion culling is really hard and there is no perfect solution.

As for the VDP2, it's used for the text (NBG0), the "ocean" (RBG0) and the background mountain (NBG2). I added extra clouds with NBG3, but removed them as I was running out of high work RAM.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on January 26, 2018, 08:49:33 am
Sounds like a good plan! Cant wait for one day to see the fruits of you labor

Have a great week
Title: Re: Sonic Z-Treme
Post by: XL2 on February 04, 2018, 05:26:26 pm
Here is a small video (I didn't make it public since many things are removed) just to show what it looks like in terms of performance using LOD models (auto-generated with my map converter).
The effect will be similar to what's in Tomb Raider.

I DIDN'T CODE YET THE MATCHING TEXTURES! Which is why it looks horrible and textures don't fit, but I will code it within a few weeks.
The idea is that if a 4x4 quads wall becomes 1, I will need to generate a texture mixing data from other sprites.
So, 4 times 4 16x16 textures might become a single 32x32 texture, or even a 16x16 texture (I will have to play with different settings)
I removed the collision as I'm working on a per-quad collision and it's not complete.
I also switched to 16 colors sprites, but except for the Quake E1L1 map, all the textures were auto-downgraded with my map converter, which is why they don't look all that great.
Still no PVS/portal, but I might not even need it for Sonic Z-Treme to increase the draw distance thanks to the LOD (we'll see).
I also added analog control in the FPS demo.

https://www.youtube.com/watch?v=crZ7jbSA1SQ&list=UU-U3sMVXNwNkk8Zgs4JPmng&index=1
Title: Re: Sonic Z-Treme
Post by: corvusd on February 04, 2018, 08:24:13 pm
Your progress is really great! AWESOME !!

And also it's a coincidence with me! These days in my research I have added two columns to table data. Now I will update them.

1) If a game has "Tessellation" (you call it LOD) as you say Tomb Raider has it. But there are some more games. The complication is that the game has to have wireframe mode to discover it. Or that the wireframe is implemented in Yabause or other emus to see how many more games are used, surely many! Since it is a trick to gain drawing distance and perfect speed!

* The LOD is the reduction or increase of geometry in an object. Like the FIFA players or the Daytona cars. When it is in the "terrain" or "stage" in the engines they are called Tessellation.

2) I have also added a column of "Table fog" since it was an effect that in PSX also looked a lot. But also in SS!!

I was able to confirm that both effects were fully integrated into the PSX SDK. They are three functions. The "Table fog" is called "Depth Cueing" and the "Tesselation" includes two functions: 1) "Polygon Division" and 2) "Mip-map Function Library". All of them using the GTE.

On the other hand I have searched and not found in the SS SDK any function to do these things. In these cases, programmers create their own code to have these effects in their games or ports. But it is very possible, that each one did it in a different way... and none in the most optimal way. Here perhaps, SEGA failed to detect these needs and integrate them into the SDK.

I think that in this rebirth that you are building, functions like these would be very useful and necessary. I have many concrete ideas for these functions (to optimize the use of memory, VDPs and processes) and proposals in development. But specifically in these cases using the SCU-DSP, would be ideal.

EDIT: I seeing your debugging text I have remembered the polygon limit values (theoretical) in the SS SGL and in the PSX SDK.
SGl talks about:
MAX_POLYGON (number of polygons that can be used): 1800
MAX_VERTICES (number of vertices that can be used): 2500

And in the PSX SDK, in the "Performance Analyzer" manuals you can see analyzes of the game "Motortoon Grand Prix 2": 1200/1040 polygons

It is curious to see how both machines are in very similar numbers.

Greetings and thanks!!!
Title: Re: Sonic Z-Treme
Post by: XL2 on February 05, 2018, 02:25:45 am
Thanks!
Just a quick answer :
1) I'm actualy storing the whole lower detail model in memory. But instead of doing it manualy in Blender, it's all automated. So I guess LOD is appropriate, lol. Mipmapping is also a form of LOD, so I do both techniques. Anyway, I will improve memory counsumption by sharing the vertices between the HQ and LQ models. You can find what games use this technique using the vdp1 debugger and looking at the sprites. Far away models will usualy merge 2 textures or more together. Few games that I know are using it : Sonic Jam, Tomb Raider, Quake, Wipeout 2097 and Duke Nukem.
As for the SS SDKs, none of them do it for a good reason : since you need to create a new sprite everytime, it would be a nightmare to manage, without mentionning all the DMA involved. On PS1, since they use texture coordinates, it's super easy. That being said, you could subdivide a quad on Saturn (like 64x64) to 4 times 32x32 without generating a new texture by playing with the memory adresses, width and height.
I don't plan to add that feature as it would be quite complicated to manage, but it could lead to better results with close quads, preventing warping and all.

2) for the fog effect, it's supported by SS hardware thanks to the vdp2 transparency.  That's a feature I want to implement. One way I plan to do is to use color bank for far away objects, and normal vdp1 lut for close objects and put vdp2 transparency on CRAM sprites. I'm just not sure if there is a way to use automatic color calc ratio or if I need to calculate it myself. Worst case scenario if all fails is normal depth gouraud, but it doesn't play nice with some colors (white, blue, yellow, etc.).

Edit : About the limits, it's only the default SGL buffer memory allocation, you can increase it. But with a portal system or pvs the default values should be fine.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on February 05, 2018, 04:43:03 am
Loving that Gouraud shading!
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on February 07, 2018, 05:10:14 pm
Hey XL2 you should show build 34 or 33 to SAGE this year! ;)
http://forums.sonicretro.org/index.php?showtopic=37809&st=0&gopid=921577&#entry921577
Title: Re: Sonic Z-Treme
Post by: XL2 on February 07, 2018, 06:45:27 pm
I still have 6 months, so I will have a new version ready by then, I think I can push the draw distance much further, so no rush for now.
Title: Re: Sonic Z-Treme
Post by: corvusd on February 08, 2018, 09:01:56 pm
Hi XL2 !!!

I discover new game that use "tessellation" or LOD like you say in Scenary generation. Is Courier Crisis. This game has wireframe cheat to activate. This game in SS version have more draw distance and FPS that the PSX version !!! Use "Color Calc. Mode: Gouraud Shading + Half-luminance" to far "quads/distorted sprite" and also change for 3D objets and something quads to flat polygon whit base color also. Is a good example to add trick to engine.

The key I think, and the complicate is a good clipping algorithm. Is it possible to write to a simple algorithm for the engine to know when to cover the object / s behind and are to more distance to not draw them??

Greetings!!
Title: Re: Sonic Z-Treme
Post by: XL2 on February 09, 2018, 01:37:55 am
For using untextured quads for far away objects, I won't need it to improve the framerate as I think I'm on the right track with the current technique (the per-quad collision might cause some issues thought if it's not fully optimized for early rejection).

For the clipping, my plan is still the per-octree node pvs, the main issue will be the compression used to store the data, but I'm not there yet as the new collision technique might take a while to get it right.
Title: Re: Sonic Z-Treme
Post by: XL2 on February 09, 2018, 07:11:48 pm
Still lot of work to be done on the per-quad collision, the view frustum culling and the LOD (or tessalation) texture generation, but here is, just to show my newer version of the engine, an old "map" revisited with the map converter (I didn't try to fix the geometry for the Saturn other than turning triangles to quads and subdividing everything once).

The intro level isn't the biggest level, but it shows that Mario 64 could have worked on the Saturn (with perhaps some compromises of course).

Video here : https://youtu.be/ScGVHMFB58M
Title: Re: Sonic Z-Treme
Post by: mindslight on February 10, 2018, 09:19:57 am
Very impressive  :)
Title: Re: Sonic Z-Treme
Post by: corvusd on February 10, 2018, 08:13:26 pm
For using untextured quads for far away objects, I won't need it to improve the framerate as I think I'm on the right track with the current technique (the per-quad collision might cause some issues thought if it's not fully optimized for early rejection).

For the clipping, my plan is still the per-octree node pvs, the main issue will be the compression used to store the data, but I'm not there yet as the new collision technique might take a while to get it right.

Sorry for not answer sooner... Absolutely you are in the right path. Your actual work and improvement in the engine talk about the quality work it for you.

My only intention is try to add something possible ideas to get new paths to improve the use of the machine.

In other hand your goals are impressive: Clipping with per-octree node pvs, the compression for store the data(in SDK SS can see the RLE compression are been implemented) and finally a new collision technique. All goal are important and impressive to build a strong engine for a "SS Sonic 3D" game ;)

Still lot of work to be done on the per-quad collision, the view frustum culling and the LOD (or tessalation) texture generation, but here is, just to show my newer version of the engine, an old "map" revisited with the map converter (I didn't try to fix the geometry for the Saturn other than turning triangles to quads and subdividing everything once).

The intro level isn't the biggest level, but it shows that Mario 64 could have worked on the Saturn (with perhaps some compromises of course).

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

Is a outstanding work! Really! You are use the two SH2?? Because is possible will go more far... and If you could use de DSP of SCU it be a crazy improvement! :D

In the video is possible see a peak of near 1000 quads in screen at 30FPS!!! is a madness!! XD Is possiible that you cap the limit FPS to 30, is possible that you rendering at more FPS, near 60FPS??

Thanks and encourage!!!! GO GO GO!
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on February 11, 2018, 02:28:53 am
Face it Pretendo, you are not worthy
Title: Re: Sonic Z-Treme
Post by: XL2 on February 11, 2018, 03:12:00 am
For using untextured quads for far away objects, I won't need it to improve the framerate as I think I'm on the right track with the current technique (the per-quad collision might cause some issues thought if it's not fully optimized for early rejection).

For the clipping, my plan is still the per-octree node pvs, the main issue will be the compression used to store the data, but I'm not there yet as the new collision technique might take a while to get it right.

Sorry for not answer sooner... Absolutely you are in the right path. Your actual work and improvement in the engine talk about the quality work it for you.

My only intention is try to add something possible ideas to get new paths to improve the use of the machine.

In other hand your goals are impressive: Clipping with per-octree node pvs, the compression for store the data(in SDK SS can see the RLE compression are been implemented) and finally a new collision technique. All goal are important and impressive to build a strong engine for a "SS Sonic 3D" game ;)

Still lot of work to be done on the per-quad collision, the view frustum culling and the LOD (or tessalation) texture generation, but here is, just to show my newer version of the engine, an old "map" revisited with the map converter (I didn't try to fix the geometry for the Saturn other than turning triangles to quads and subdividing everything once).

The intro level isn't the biggest level, but it shows that Mario 64 could have worked on the Saturn (with perhaps some compromises of course).

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

Is a outstanding work! Really! You are use the two SH2?? Because is possible will go more far... and If you could use de DSP of SCU it be a crazy improvement! :D

In the video is possible see a peak of near 1000 quads in screen at 30FPS!!! is a madness!! XD Is possiible that you cap the limit FPS to 30, is possible that you rendering at more FPS, near 60FPS??

Thanks and encourage!!!! GO GO GO!

For RLE, you mean using SBL?
I thought of something else, but everything is on the table.
It might take a few months before I truly focus on pvs.

I am using both SH2, but not the SCU DSP. The problem with the SCU DSP is that it needs to be coded in assembly (I haven't learnt it yet) and there is some overhead since you need to DMA transfer data, start the DSP program, wait for it to complete the processing, stop the program and then fetch the data. Unless you are dealing with complex maths in parallel, it's not really worth it. Most people used it for lightning calculations, but SGL for some reasons didn't use it.
It also has really limited RAM and can't do divisions, so you can't do that much with it.

For 60 fps, it would work with around 450 quads on screen, no gouraud shading, low res textures and/or no overdraw, so it's not really a solution for now with complex levels.
But it works nice with Sonic X-Treme levels.
Title: Re: Sonic Z-Treme
Post by: corvusd on February 11, 2018, 01:06:04 pm
For RLE, you mean using SBL?
I thought of something else, but everything is on the table.
It might take a few months before I truly focus on pvs.

I am using both SH2, but not the SCU DSP. The problem with the SCU DSP is that it needs to be coded in assembly (I haven't learnt it yet) and there is some overhead since you need to DMA transfer data, start the DSP program, wait for it to complete the processing, stop the program and then fetch the data. Unless you are dealing with complex maths in parallel, it's not really worth it. Most people used it for lightning calculations, but SGL for some reasons didn't use it.
It also has really limited RAM and can't do divisions, so you can't do that much with it.

For 60 fps, it would work with around 450 quads on screen, no gouraud shading, low res textures and/or no overdraw, so it's not really a solution for now with complex levels.
But it works nice with Sonic X-Treme levels.

Yes, I remember some library for that. Is a CMP LIB. In the "ST-135-R4-092295 Program Library User's Guide 3" is explain.

Are great if you are using right now the two SH2. SCU DSP is truly powerful but is high complex to use it, I know... but the memory I don't think is the problem here. First the ASM language. Second design that task make and design the process thread carefully. It is possible to tessellation(LOD) use the SH2, and for lightning or transformation use SCU to speed up. Is only intuition for my part, I not a programmer...

SGL is created mainly for AM2 team... I think in its games, the use of lighting is very limited... and not need it more speed in this area. This reason it possible to not use SCU DSP at all.

Other case is Sonic Team, whit Burning Rangers... Is are a truly lighting system... but not use SCU... is rare.

The 500 quad at 60FPS is real numbers... because in the games whit this FPS the numbers and shading used are it you said Two examples: VF2, Mass Destruction... etc...

Thanks for the feedback!! :)
Title: Re: Sonic Z-Treme
Post by: Cerv3ro on February 12, 2018, 01:29:47 am
Your progress is really great! AWESOME !!

And also it's a coincidence with me! These days in my research I have added two columns to table data. Now I will update them.

1) If a game has "Tessellation" (you call it LOD) as you say Tomb Raider has it. But there are some more games. The complication is that the game has to have wireframe mode to discover it. Or that the wireframe is implemented in Yabause or other emus to see how many more games are used, surely many! Since it is a trick to gain drawing distance and perfect speed!

* The LOD is the reduction or increase of geometry in an object. Like the FIFA players or the Daytona cars. When it is in the "terrain" or "stage" in the engines they are called Tessellation.

2) I have also added a column of "Table fog" since it was an effect that in PSX also looked a lot. But also in SS!!

I was able to confirm that both effects were fully integrated into the PSX SDK. They are three functions. The "Table fog" is called "Depth Cueing" and the "Tesselation" includes two functions: 1) "Polygon Division" and 2) "Mip-map Function Library". All of them using the GTE.

On the other hand I have searched and not found in the SS SDK any function to do these things. In these cases, programmers create their own code to have these effects in their games or ports. But it is very possible, that each one did it in a different way... and none in the most optimal way. Here perhaps, SEGA failed to detect these needs and integrate them into the SDK.

I think that in this rebirth that you are building, functions like these would be very useful and necessary. I have many concrete ideas for these functions (to optimize the use of memory, VDPs and processes) and proposals in development. But specifically in these cases using the SCU-DSP, would be ideal.

EDIT: I seeing your debugging text I have remembered the polygon limit values (theoretical) in the SS SGL and in the PSX SDK.
SGl talks about:
MAX_POLYGON (number of polygons that can be used): 1800
MAX_VERTICES (number of vertices that can be used): 2500

And in the PSX SDK, in the "Performance Analyzer" manuals you can see analyzes of the game "Motortoon Grand Prix 2": 1200/1040 polygons

It is curious to see how both machines are in very similar numbers.

Greetings and thanks!!!

Hei guys, when you talk about "Tessellation" or "LOD" you mean something like this? (Go to minute 05:00).
https://www.youtube.com/watch?v=ME7Dkpgd_-k&t=175s (https://www.youtube.com/watch?v=ME7Dkpgd_-k&t=175s)

Different levels of detail acording the distance?.

Very impresive work XL2, thank you very much for doing this.
Title: Re: Sonic Z-Treme
Post by: XL2 on February 12, 2018, 01:40:28 am
Yes, but for the actual level instead of the entities.

You can check Wipeout which does it too :
https://www.youtube.com/watch?v=x8yLq45tDGc
If you look at the sides, 1 quad turns to 16 (and vise-versa).
It's about the same ratio as I'm doing, but my quads are much larger, so I might have to push the effect a bit to avoid warping on real hardware.
Tomb Raider also does it (starts around the 1 min mark) :
https://www.youtube.com/watch?v=FM3cQt-3kGM

Title: Re: Sonic Z-Treme
Post by: XL2 on February 12, 2018, 03:47:51 am
Good news! I only put around 1 hour since the last video, but seems like I got the collision almost right on my first try. I still have to make some adjustments, but a level like a Quake map is fully working now (except for doors).

I still have to write the texture generation to match the merged quads and use another frustum culling technique (I have an octree, but it's not used other than collision since it can't work well with the SGL frustum culling functions).

Here is a Quake map in my engine, with fully working collision : https://youtu.be/uBa6NNM4ZU0

Still no portal or pvs or depth buffer, so it wouldn't work nice on real hardware unless I drop the texture quality (it's 64x64 right now, but with the overdraw it will be slow).
Title: Re: Sonic Z-Treme
Post by: corvusd on February 12, 2018, 09:17:59 pm
Your progress is really great! AWESOME !!

And also it's a coincidence with me! These days in my research I have added two columns to table data. Now I will update them.

1) If a game has "Tessellation" (you call it LOD) as you say Tomb Raider has it. But there are some more games. The complication is that the game has to have wireframe mode to discover it. Or that the wireframe is implemented in Yabause or other emus to see how many more games are used, surely many! Since it is a trick to gain drawing distance and perfect speed!

* The LOD is the reduction or increase of geometry in an object. Like the FIFA players or the Daytona cars. When it is in the "terrain" or "stage" in the engines they are called Tessellation.

2) I have also added a column of "Table fog" since it was an effect that in PSX also looked a lot. But also in SS!!

I was able to confirm that both effects were fully integrated into the PSX SDK. They are three functions. The "Table fog" is called "Depth Cueing" and the "Tesselation" includes two functions: 1) "Polygon Division" and 2) "Mip-map Function Library". All of them using the GTE.

On the other hand I have searched and not found in the SS SDK any function to do these things. In these cases, programmers create their own code to have these effects in their games or ports. But it is very possible, that each one did it in a different way... and none in the most optimal way. Here perhaps, SEGA failed to detect these needs and integrate them into the SDK.

I think that in this rebirth that you are building, functions like these would be very useful and necessary. I have many concrete ideas for these functions (to optimize the use of memory, VDPs and processes) and proposals in development. But specifically in these cases using the SCU-DSP, would be ideal.

EDIT: I seeing your debugging text I have remembered the polygon limit values (theoretical) in the SS SGL and in the PSX SDK.
SGl talks about:
MAX_POLYGON (number of polygons that can be used): 1800
MAX_VERTICES (number of vertices that can be used): 2500

And in the PSX SDK, in the "Performance Analyzer" manuals you can see analyzes of the game "Motortoon Grand Prix 2": 1200/1040 polygons

It is curious to see how both machines are in very similar numbers.

Greetings and thanks!!!

Hei guys, when you talk about "Tessellation" or "LOD" you mean something like this? (Go to minute 05:00).
https://www.youtube.com/watch?v=ME7Dkpgd_-k&t=175s (https://www.youtube.com/watch?v=ME7Dkpgd_-k&t=175s)

Different levels of detail according the distance?.

Very impresive work XL2, thank you very much for doing this.

Very similar techniques. Two link to wikipedia:
https://en.wikipedia.org/wiki/Level_of_detail
https://en.wikipedia.org/wiki/Tessellation_(computer_graphics)

In the case in this generation of 3D. The improvement of XL2 in your engine is more similar to modern Tessellation. Is a LOD automatic or calculate in real time in function of the variables. To put in screen the optimal number of data geometry.

LOD is a manual technique or static. I mean, you create the levels o detail model for a one specify model. This is used a lot in a lot of game in all catalog in SS. For example FIFA games or similar games. Is easy see the steps in the models. Or in Daytona USA in a cars.

Normally the tessellation is use in the scenario. I one part o in all. In the case of Wipeout or Nascar 98 for the road. In other case like Tomb raider or Courier Crisis for all scenario.

In this age. A lot of games use it. More in PSX for easy to implement. For me one the most aggressive Tesselation + LOD in PSX games us very last games: Terracon (2000)

Good news! I only put around 1 hour since the last video, but seems like I got the collision almost right on my first try. I still have to make some adjustments, but a level like a Quake map is fully working now (except for doors).

I still have to write the texture generation to match the merged quads and use another frustum culling technique (I have an octree, but it's not used other than collision since it can't work well with the SGL frustum culling functions).

Here is a Quake map in my engine, with fully working collision : https://youtu.be/uBa6NNM4ZU0

Still no portal or pvs or depth buffer, so it wouldn't work nice on real hardware unless I drop the texture quality (it's 64x64 right now, but with the overdraw it will be slow).

Again my congratulations!! 1200 quads in screen!! Wohooo!!! :D

I can wait to put in my SS and in yabause to see your work near! ;)

In other hand. I continue my research. I can confirm, that in last SGL (3.0), SEGA implemented the Depth Cueing like PSX SDK. For the side of the use of SCU in SS SDK. Is strange. I can see a lot of function in SBL y SGL to use DMA, access to RAM storages and all stuff tu use it. But not are a code specify implemented in C to call a ASM code or similar. Only in SBL I can find some come to transform or matrix in a folder name MATHS. Is rare, because the very first game of AM2 use it SCU: VF1 and Remix

Finally! I can read in youtube a user said it, about port Quake 2 to SS in your engine. I can help you whit the graphics part. If some day this project start. ;) One of my dreams is make a very good port of Doom. Best that PSX, I believe it possible. And because no! a Quake 2. But Sonic Z-treme is good start to put to limit a our lovely machine!! I want see more transparencies in SS, like PSX... real lens flares for example. I try to design some trick or way to do it!!

Stay in touch! See ya!! :)
Title: Re: Sonic Z-Treme
Post by: XL2 on February 12, 2018, 11:13:40 pm
For the depth cueing, it's what I'm using for the gouraud shading.
For the LOD/tessalation, the thing is that all the work is done offline, so there are really 2 full maps in memory, I display one or the other depending on the distance from camera for each node. It could be done manually for better results, but I don't have time for that so it's all automated during conversion.
Nothing is built in realtime.
While it would be possible to subdivide a quad in realtime, the other way around can't be done since we are dealing with distorted sprites only.
I could choose to just use the low quality model if I wanted, but the results would be bad.
About the 1200 quads on screen, SGL transforms the vertices, then does backface culling, so only half those quads reach the VDP1. Using a BSP tree could reject them earlier, but walking the tree would be slower than what could be gained (and it uses more memory).

The SCU DSP is in assembly only, and SGL doesn't have functions using it, while the SBL functions are useless : they transform vertices from a different matrix format and it is not compatible with the SGL quad processing (buffers and all).
The DSP RAM is also too limited, so I can't really use it for a depth buffer or something like that, while SGL already has a strong lightning support built in, so I wouldn't gain anything from replacing it.
It's hard to find a good use for it in these circonstances.

For Quake 2, I could just show 1 or 2 maps in my engine, but I wouldn't want to port the whole game since there are much better ways to play it already.
Title: Re: Sonic Z-Treme
Post by: corvusd on February 13, 2018, 07:25:24 pm
For the depth cueing, it's what I'm using for the gouraud shading.
For the LOD/tessalation, the thing is that all the work is done offline, so there are really 2 full maps in memory, I display one or the other depending on the distance from camera for each node. It could be done manually for better results, but I don't have time for that so it's all automated during conversion.
Nothing is built in realtime.
While it would be possible to subdivide a quad in realtime, the other way around can't be done since we are dealing with distorted sprites only.
I could choose to just use the low quality model if I wanted, but the results would be bad.
About the 1200 quads on screen, SGL transforms the vertices, then does backface culling, so only half those quads reach the VDP1. Using a BSP tree could reject them earlier, but walking the tree would be slower than what could be gained (and it uses more memory).

The SCU DSP is in assembly only, and SGL doesn't have functions using it, while the SBL functions are useless : they transform vertices from a different matrix format and it is not compatible with the SGL quad processing (buffers and all).
The DSP RAM is also too limited, so I can't really use it for a depth buffer or something like that, while SGL already has a strong lightning support built in, so I wouldn't gain anything from replacing it.
It's hard to find a good use for it in these circonstances.

For Quake 2, I could just show 1 or 2 maps in my engine, but I wouldn't want to port the whole game since there are much better ways to play it already.


OK! Now I understand you. Yeah, you are implemented LOD for the scenery. But is a absolutely great achievement. And is a good opportunity to design great levels to fit in memory. :)

This sentence I don't understand: "I could choose to just use the low quality model if I wanted, but the results would be bad."

I think that, in Tomb Raider and Wipeout 2097 is realtime. Because both games full the memory and both are been port to PSX whit the same memory. The Wipeout 2097 is a port from PSX, that have this feature implemented in SDK.

Whit the data recompiled in Yabause. 1200 quads in screen not is are impossible situation. Sonic R(2x SH2 + SCU use) or Burning Rangers(2xSH2 no SCU use) have more than this quantity and run whiteout problem at 30FPS. 4x4 Hardcore(1500) or Tomb Raider(1300) whit slowdown to 15FPS o less in the 4x4 case. Yabause only list the elements in the screen, not the calculated or back face clipped... Maybe more really.

Is true the SBL an SGL, are a two different approach to build a "engine" or conjunction of library to arm a SDK. In some form the structure of libraries SBL is similar to PSX SDK. But SGL is more similar to PSX SDK in the name of the specify 3D functions and variables in it. I think in last version SEGA tried to fusion both... but not is perfect SDK to exploit to maximum SS.

This days I think about the fantasy, of the in time, fusion of the Tantalus/Perfect engine(Yes I think in some aspect are good features) + Argonaut Engine + Sonic Team Engine + Sonic R Engine + Slave(Lobotomy) Engine + Game Arts FMV codec... for put some of the best devs engines of the time. If SEGA would have invested in all this GREAT code, the SDK enriched greatly.

Anyway. Your work, the Johannes work and the other awesome people of the SS community homebrew, this days make true my dreams. Thank you!

GO GO GO! Greetings! :)
Title: Re: Sonic Z-Treme
Post by: XL2 on February 13, 2018, 07:47:44 pm
About the low quality model, I just meant that by changing one line of code I could choose to display the low quality or high quality model.
About 1200 quads on screen, it's totally possible even at 30 fps. But for a FPS, that means many many pixels that keep getting rewritten over since the walls - if you don't have proper occlusion culling - can take the whole screen.
About Burning Rangers, there is a SCU DSP program in memory, so are you sure it's not used?
I don't know if Wipeout and Tomb Raider do the quad subdivision in realtime, but one way to see is to check the texture memory address : if 1 quad turns to 4, look at the top left quad. If the address is the same as the lone quad texture address, with different width/height, then you know it's probably done in realtime.
But they could also store it in memory since the low quality map should take maybe as little as 1/4 the size of the high quality map.
About SBL and SGL, both are really interconnected. For graphics, it's SGL, for almost everything else it's SBL or SBL wrappers.
Title: Re: Sonic Z-Treme
Post by: corvusd on February 13, 2018, 08:49:50 pm
About the low quality model, I just meant that by changing one line of code I could choose to display the low quality or high quality model.
About 1200 quads on screen, it's totally possible even at 30 fps. But for a FPS, that means many many pixels that keep getting rewritten over since the walls - if you don't have proper occlusion culling - can take the whole screen.
About Burning Rangers, there is a SCU DSP program in memory, so are you sure it's not used?
I don't know if Wipeout and Tomb Raider do the quad subdivision in realtime, but one way to see is to check the texture memory address : if 1 quad turns to 4, look at the top left quad. If the address is the same as the lone quad texture address, with different width/height, then you know it's probably done in realtime.
But they could also store it in memory since the low quality map should take maybe as little as 1/4 the size of the high quality map.
About SBL and SGL, both are really interconnected. For graphics, it's SGL, for almost everything else it's SBL or SBL wrappers.

Perfect thanks, now I understand.

It is true, in a FPS the probability of covering other objects and many of them is greater ... I think now about how the Slave engine does it. It's really complex, using Clipping user and system every "X" elements ... it's almost the only game I've seen that does that. Even with the sky drawn he does it in case of the Quake.

It is true that there is a program. But SSF does not detect the use of the SCU ... and seeing the registers ON, they are only 3% ... I really have doubts in this case.

I will investigate more deeply Wipeout, Tomb Raider, Nascar 98 and Courier Crisis, which are the games that until now I am sure do this.

With respect to SBL and SGL ... I understand, but they seem very separate "projects" ... And the logic should be that these should be closer still ... I do not know.

Thanks again for the quick replies!
Title: Re: Sonic Z-Treme
Post by: Joeveno on February 15, 2018, 10:24:18 pm
Hello! I'm a huge fan of this project! It's bringing the Blue Hedgehog fully fleshed out to the Saturn! congratulations!
I was just wondering something, it is possible to convert some of the Sonic Robo Blast 2 maps to Z-Treme? or it would be too heavy for the Saturn? and about the loops, they're gonna be in the game?
Would be nice to see those maps in this amazing project! cheers!
Title: Re: Sonic Z-Treme
Post by: XL2 on February 15, 2018, 10:48:57 pm
Thanks!
For porting the maps, it could be done using something like Noesis, but lot of work would need to be put to make them suitable for the Saturn.
The Doom engine has large open space, which isn't too great on the Saturn.
That being said,  I don't intend to do it.
For the loop, it will come back at a later time, once I fully settle on the collision functions, as I'm still experimenting.
Title: Re: Sonic Z-Treme
Post by: XL2 on February 16, 2018, 10:44:56 pm
It's not perfect, but still not terrible either :
https://youtu.be/lLiq5V_nlsg

 
I might just push the LOD draw distance to hide it better or play more with the mipmapping or even hide it with gouraud shading, but it now generates textures to fit the merged quads.
One huge issue is that the quads can have different width/height, so the generated textures doesn't fit perfectly.
It's even more obvious on Quake maps, but anyway I think it can be improved.
Title: Re: Sonic Z-Treme
Post by: corvusd on February 17, 2018, 12:58:11 am
It's not perfect, but still not terrible either :
https://youtu.be/lLiq5V_nlsg
 
I might just push the LOD draw distance to hide it better or play more with the mipmapping or even hide it with gouraud shading, but it now generates textures to fit the merged quads.
One huge issue is that the quads can have different width/height, so the generated textures doesn't fit perfectly.
It's even more obvious on Quake maps, but anyway I think it can be improved.

Another awesome step! Are mip mapped manually the textures?? How many levels? Max/min resolution?

The fit problem is normal, in auto convert geometry. Whit a manually clean and adjust this problem fix it almost all cases.

A very little doubt? Is possible adjust to the max peak(1000/1200) of the showed quad geometry, to show the max or near to the max, for all most time to increase farclip??

And last. It possible adjust the levels of shades to farclip. To have more equal color fade to far. To soft the poping??

Amazing work!!

The Doom engine has large open space, which isn't too great on the Saturn.

I understand well the sentence? The open space in Doom not capable for SS?? I mean, Exhumed or Duke3D had have open space and SS had been capable to move whiteout problem. ;) I hope in the future, We give a definitive port of Doom to SS. :)
Title: Re: Sonic Z-Treme
Post by: XL2 on February 17, 2018, 03:29:29 am
Everything is automated, which is why the textures don't look all that great, but my pushing them further I might be able to hide it. About the open space, my engine doesn't support proper occlusion culling (pvs or portals), so I need to limit the draw distance.
Title: Re: Sonic Z-Treme
Post by: corvusd on February 17, 2018, 07:18:20 pm
Everything is automated, which is why the textures don't look all that great, but my pushing them further I might be able to hide it. About the open space, my engine doesn't support proper occlusion culling (pvs or portals), so I need to limit the draw distance.
When you said  "Everything is automated"... is in realtime or automated in a script when you create the scenary??
I answer myself: Script map tool make it the automated features. XD

Anyway. A great job again.

I've been reviewing forum threads. And I've seen that you were investigating the clipping user of slave engine. Finally you concluded that it helped to improve the bottleneck of the VDP1 itself. But not the DSP calculation of the SH2 or SCU.

Combine both techniques to optimize both side of the VDP1 blitter and side of the 3D transformations for loading the processors (SH2 or SCU). It would be the ideal scenario to take advantage of the SS, right?

Maybe you're doing it already.

Finally, I think I understand you right now perfectly regarding the issue of open areas. With a pvs or portals algorithm. You can discriminate rooms by size or distance and so you can stop processing or drawing before said geometries. Or even apply a more aggressive LOD more selectively, no?

On the other hand. I have been looking at the use of SCU in Burning Rangers and other games. I said that I used 3% of registers and I was wrong. Out of a maximum of 23 registers, use 3. Which are actually 13% and 70% code. Against Sonic R 53% registers and 80% code. Or cases such as Wipeout 1 (Registries 60% Code 33%) or Assault Rigs (39% Registries 60% Code) where they also use the DMA. Something must be doing this code in BR. Is it possible to help decompress the Audio ADX??

Which brings me to another question. What I see also you have been researching in the forums. Using PCM for sound takes up a lot of memory. SDK SS there are libraries to compress/decompress ADPCM, which in essence is very similar to ADX. You will save a lot of space and decompress whit the M68000 sound proccesor.

Which leads me to another question that surrounds me these days and I do not understand. The SS sound chip is a beast. That has programmable DSP. It is possible to do things with him. Because I have not seen any game with reverb. Something that is seen in many PSX games. And it is supposed SS could do. I know that for this I had to buy another sound development SDK. And that's the reason for not seeing more things like that in games.

It is also a question to Johannes. Is it possible to implement this effect in the Jo-Engine library? Reverb and / or echo effect for sound or sound channels.

Greetings! :)
Title: Re: Sonic Z-Treme
Post by: mindslight on February 18, 2018, 09:28:36 am
It's possible, but first I need to fix Linux compilation with custom GCC and continue the 3D implementation  :)
Title: Re: Sonic Z-Treme
Post by: corvusd on February 18, 2018, 12:35:39 pm
It's possible, but first I need to fix Linux compilation with custom GCC and continue the 3D implementation  :)
Only with read this: "fix Linux compilation with custom GCC" you are GOD!

And is normal. 3D implementation is priority feature.

But read that is possible, for me is dream! Reverb in SS! :)
Title: Re: Sonic Z-Treme
Post by: XL2 on February 22, 2018, 03:27:16 am
I tested the demo on real hardware : 20 to 60 fps, which is great considering it's not optimized.
Here is a video with 2 more Quake maps :
https://youtu.be/2B48PMqd1zg
Title: Re: Sonic Z-Treme
Post by: corvusd on February 24, 2018, 05:37:03 pm
I tested the demo on real hardware : 20 to 60 fps, which is great considering it's not optimized.
Here is a video with 2 more Quake maps :
https://youtu.be/2B48PMqd1zg

Guau!!! Really nice the new texture LOD in this version and a REAL Hardware!! :D

You think that whit real-time source colour lighting, like Exhumed/DN3D/Quake from Slave engine. Your engine could stay 30FPS for second??

Greetings! :)
Title: Re: Sonic Z-Treme
Post by: XL2 on February 24, 2018, 05:44:11 pm
Probably not, but right now it wouldn't work well for sure, both on the CPU and the VDP1.

Anyway RAM is so tight that it wouldn't fit since I would need to keep space for the light vectors, so I will stick with static lights.
I don't plan to add dynamic lights.

On real hardware, the framerate goes between 20 and 30 FPS (or 60 fps sometimes if left uncapped). The video seen here is on emulator, which stays at 30 fps (or 60 if I leave the framerate uncapped).
There is lot of overdraw (sprites written over other sprites), if I find a solution for that the framerate should be much better.

The CD loading functions are really terribly slow (2 minutes to load a 1,3 MB map!!!) and prone to failure, so I'm not showing real hardware footage until I can bring that loading time down to something better (15 seconds or so).
Title: Re: Sonic Z-Treme
Post by: corvusd on February 24, 2018, 10:33:26 pm
Probably not, but right now it wouldn't work well for sure, both on the CPU and the VDP1.

Anyway RAM is so tight that it wouldn't fit since I would need to keep space for the light vectors, so I will stick with static lights.
I don't plan to add dynamic lights.

On real hardware, the framerate goes between 20 and 30 FPS (or 60 fps sometimes if left uncapped). The video seen here is on emulator, which stays at 30 fps (or 60 if I leave the framerate uncapped).
There is lot of overdraw (sprites written over other sprites), if I find a solution for that the framerate should be much better.

The CD loading functions are really terribly slow (2 minutes to load a 1,3 MB map!!!) and prone to failure, so I'm not showing real hardware footage until I can bring that loading time down to something better (15 seconds or so).

Okey. Is possible that you need use something whit SCU to calculate lights maybe, to push up the FPS whit this feature on.

SS have 2MB of RAM and 1MB of VRAM(VDP1+VDP2) to maps like Quake that have a size of 1MB aprox whit color vertex data inside. And now you are use Gouraud in all sprites in screen for Depth Cueing. I mean, right now the vertex are a color data for this effect.

For overdraw. The only way is a good culling function like you said. Whit the portal o PVS like you want, and whit the actual LOD + mip mapping. Are the right way. I think. All this whit a simple and fast code. Ideally, in very complex part whit a ASM to win speed in more complex areas.

Load data from CD at this speed is very rare... SS can read at 2x 360kb/s and have cache system and SH-1 to help it... is rare. Ideally 1.300Kb could be read in 3,5 o 4 sg. Right now 120sg is to long time... But, you load the map and all the rest data: sound, engine code... etc... I possible you load more things. I don’t know what happens...
Title: Re: Sonic Z-Treme
Post by: XL2 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.
Title: Re: Sonic Z-Treme
Post by: corvusd on February 25, 2018, 09:07:08 pm
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.

Okey. I know that win a lot of possible in the pre-process side(Transform matrix, lighting, physic. IA…) not help to side more to VDP1?? But the real bottleneck not are totally documented. But are games whit less of 400 quads very low FPS and games whit a lot of quads more than 1200 whit a 30FPS o more. And whit a lot of VDP1 effects… I had the sensation of the knowledge of the real limit of VDP1 is unknown. But this, I choose how possible solution use SCU o more ASM code for complex functions in pre-process side to win a lot of time process cue to VDP1. But I don't want press you. I know that your skills and resources are limit. And your results are BIG. Thank you.

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.

32 bytes SGL vs 8 bytes “Slave” for quad is a lot of difference… Is for have more possible spec ready to use?
But for lighting the requirement data is the vertex data. And the difference here is less 12 bytes SGL VS 8 bytes “slave” I can't know why...
Anyway the current use of texture data en “SlaveEngine” is 15bit RGB in Exhumed and DN3D. For Quake 4bpp color LUT like your engine, whit a similar load of data, except the LOD data. I know that are use more RAM in both sides. One for SGL data mesh and vertex. And VRAM for LOT and Mip mapping. Is possible for Mip mapping locate the data in VDP2 VRAM? I mean use color bank for these textures. I saw how use Gouraud or Half-transparent in color bank elements: Polygon, line, sprites… not Sprite distorted… but maybe possible. If not, well. For Depth Cueing or lighting you can use “per texture texture lighting”

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.
“Realtime lightning polygon requires 12 bytes of extra vector data” plus the 32 bytes and 8 bytes that refer before of SGL? 52 bytes total for distorted sprite?

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

I am conscious about that. How can help you whit this? Try to find some code example? Or are you have? Testing??

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.

Many areas until to implement well to have better tools to dev new games. Any effort is welcome. In this direction, your both efforts to implement a better function to win speed in data load from CD is a good new for the community.

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

Well. Only can give you is the possibility or use color bank for LOD textures. Whit the “possible” problem that gouraud not work or work whit issues. For the audio RAM, I try to find some code example. Ideally fx sounds coded in ADPCM in low sample quality and mono. In order to get the most FX sounds, mainly, and maybe some song or music. In documentation in this way only use 4% of the sound CPU I remember to decode this quality of ADPCM. The other option is combine low PCM fx sounds whit ADPCM tunes in low medium/stereo quality. I understand that you can decompress audio whit the M68000 is need place the data in your own RAM. If not is very slow, load from system RAM to process the sound data.
Title: Re: Sonic Z-Treme
Post by: XL2 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.


Title: Re: Sonic Z-Treme
Post by: corvusd on February 26, 2018, 08:27:58 pm
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.

Yes, but for me not is good documented limit. Or bottleneck. For example: How many elements or layers or area limits to use VDP1 CC Half-transparent.... Or VDP1 CC Shadow. Or many cycles use Gouraud + Flat Polygon. Or Flat Poligon + H-T + Gouraud... How many cycles use Forced Triangles share a one vertex common. For me so many dudes. Or many cycles read the VDP1 Buffer o VDP2 Buffer for the CPU to Render-to-texture effects... So many questions, to know the real limits of the system.

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.

Ok, gotcha is a base Design of the SGL. Not in mind put the limit the hardware to lighting system, like Slave engine.

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.

I read the issues in the release notes of SGL/SBL SDK. But I understand that fix in last release for the Gouraud real time.

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

Yes, my mistake. Sorry.

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.

Is a good news know that Gouraud is possible use colour bank, no limit here. I understand the real problem is design a sprites colour palette whit precision to have similar colour between texture CLUT and Colour bank. And use 16 colour is enough for very low and far mip map, whit various palletes of 16 colour I mean. An you save it a lot of memory and use CVRAM.

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.
I will try find something in C, that is the same language and how example or beginning is something.

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.
I take your word... I have a child XD But this is a funny and epic "mission"! :)

For audio RAM, for PCM, I never saw an example, but maybe some homebrew emulator do it, I really don't know.
I will try to find something here also.

Thank again and greetings!
Title: Re: Sonic Z-Treme
Post by: XL2 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.

Title: Re: Sonic Z-Treme
Post by: corvusd on March 03, 2018, 10:47:25 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.

Ou yeah!! :)

This function maybe use it whit a example to implement some improvements in the side of jo-engine function. Is really good news!

:D
Title: Re: Sonic Z-Treme
Post by: XL2 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 (https://youtu.be/VsHibSGWKuw)
Title: Re: Sonic Z-Treme
Post by: Joeveno on March 07, 2018, 01:56:24 am
Hello! it's me again!
Is there gonna be any kind of Homing Attack in the Z-Treme project? what about camera centralization?
What about using the Robo Blast 2 Sonic Adventure DX maps in this project? they're not as big and graphically demanding as Vanilla Robo Blast 2 maps, do you think it's possible to insert them in the project?
And what are your plans in the full game maps right now? would be great to know :)
Cheers!
Title: Re: Sonic Z-Treme
Post by: XL2 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).
Title: Re: Sonic Z-Treme
Post by: corvusd on March 07, 2018, 08:11:58 pm
I'm just using the GFS_Load function from SBL.

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

Another step forward! Yeah! run very well in real hardware. Amazing!

Very weird this specific slowdowns... It is possible debug in some-way?? And finding what’s happens?

All the rest beautiful. Very well adjust mip-mapping in levels.

Go head! Greetings!
Title: Re: Sonic Z-Treme
Post by: XL2 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.
Title: Re: Sonic Z-Treme
Post by: corvusd on March 07, 2018, 09:15:09 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.
Well, I don’t know is Johannes implemented some function to help to debug specify in this part of pipeline rendering... For the SGL/SDK well, is possible... I remember some documentation for debug things... but I don’t know if are useful for that.
For your load implementation is absolutely great. By my point of view, You don't spend more time in this. Load very very fast! :D
For the new quad generation, is interesting the exception that you added in your function to draw yours LODs. Very smart indeed. ;)
Congratulations again! :)
Next big step in your TODO list?
Title: Re: Sonic Z-Treme
Post by: XL2 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)
Title: Re: Sonic Z-Treme
Post by: corvusd on March 08, 2018, 07:13:31 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)

Guau!! Already you have the split screen!! +1400 quads in screen? At 30FPS! Amazing job! :D
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on March 15, 2018, 04:10:42 am
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)

Thats going to haunt my nightmares!

Anyway keep up the amazing work! ;D
Title: Re: Sonic Z-Treme
Post by: corvusd on March 15, 2018, 08:47:05 am
Wipeout 1 had LOD system. Look this blog post is very good detailed. http://phoboslab.org/log/2015/04/reverse-engineering-wipeout-psx

Greetings!
Title: Re: Sonic Z-Treme
Post by: Joeveno on March 19, 2018, 11:47:55 pm
Hello! it's me again :D
I have another suggestion :)
Would be possible to port the levels from BUG! or BUG TOO! to the game and make some changes like adding loops or some slopes around the map and changing textures to something Sonic-ish? I think it would help in this project, because BUG! is very similar to the X-TREME concept :D
Cheers!
Title: Re: Sonic Z-Treme
Post by: XL2 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.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on March 20, 2018, 12:14:24 am
My guess is that it would not be that hard to recreate as all the levels are are a bunch of blocks
Title: Re: Sonic Z-Treme
Post by: XL2 on March 20, 2018, 12:18:26 am
You are right. But would anyone want to bother doing that?
Title: Re: Sonic Z-Treme
Post by: Joeveno on March 20, 2018, 01:01:50 am
I think that recreating them would be cool as unfortunately I don't have the 3D models :/
It would help to have some defined level design for each act, just receiving some slight changes to a Sonic-ish level like slopes or loops.
Thanks for Answering :D cheers!
Title: Re: Sonic Z-Treme
Post by: XL2 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.
Title: Re: Sonic Z-Treme
Post by: SkimmingSanshiro on March 20, 2018, 02:33:05 pm
That sounds awesome. I love the Jam level and feel, really makes you think Sonic Adventure Saturn could of been possible.

While I admire XTreme blocky level and uniqueness to the time,  jams style is just downright impressive to look at on a Saturn.
Title: Re: Sonic Z-Treme
Post by: XL2 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.
Title: Re: Sonic Z-Treme
Post by: Joeveno on March 20, 2018, 05:59:27 pm
Hello! wow, the idea of Jam styled levels is magnificent! they were really advanced and look extremely modern! it certainly will take the Saturn to its limits :D
And I have one more question, what do you think about a smooth rotating camera? something like the analog mode from Robo Blast 2?
Cheers :D
Title: Re: Sonic Z-Treme
Post by: XL2 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.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on March 27, 2018, 01:34:39 am
How's development going?
(On a little side note im not sure why but the video you and i did jumped around 2000 views in the past two days, not sure why but lets hope if helps give your project more attention!)
Title: Re: Sonic Z-Treme
Post by: XL2 on March 30, 2018, 05:22:56 pm
I recently restarted working on Sonic Z-Treme, but I'm slowly transitionning to the newer version of the Z-Treme engine.
I pretty much need to discard almost everything I did with Sonic Z-Treme and restart, but it also forced me to make the engine more modular, which is good for future projects.
Right now I'm mainly working on implementing new audio functions to stop using PCM streams and properly use the Saturn's sound CPUs, but I haven't made much progress yet.
I probably won't be showing anything about Sonic Z-Treme until Sage 2018.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on March 31, 2018, 06:05:37 am
No problem, keep up the good work!
Title: Re: Sonic Z-Treme
Post by: corvusd on April 03, 2018, 09:34:10 pm
I recently restarted working on Sonic Z-Treme, but I'm slowly transitionning to the newer version of the Z-Treme engine.
I pretty much need to discard almost everything I did with Sonic Z-Treme and restart, but it also forced me to make the engine more modular, which is good for future projects.
Right now I'm mainly working on implementing new audio functions to stop using PCM streams and properly use the Saturn's sound CPUs, but I haven't made much progress yet.
I probably won't be showing anything about Sonic Z-Treme until Sage 2018.

Really good news!

Natural next step in your progress.

It would very interesting, that you can use at last one ADPCM channel for a BGM/Speech, very long sounds. And up 4 PCM sounds for all rest FX, at low quality. The ADPCM it can be read on the fly and stream form CD, and not use a lot of RAM o Sound RAM. And the PCM FX, shorts sound can be save in the RAM to mix in real time. Ideally, to put at maxium of fx similar to a Sonic Game. It should be use FM sound FX, more small sounds and similar to Sonic Games.

The SGL library an SBL, can be good start to find proper functions to fit in your engine.

Greetings!
Title: Re: Sonic Z-Treme
Post by: XL2 on April 03, 2018, 09:46:19 pm
Yes, but sadly it's really not as easy as it seems.

All the apps to create sequences and tones are Mac-based (6800K cpu).
The only way to use them is either to buy an old mac or to use an emulator.

While using PCM on the main RAM is very easy, you are limited to low quality (for RAM) and it's hogging the B-Bus since you need to DMA data each time you play a file (CPU overhead).
And it's very complicated to use the sound RAM  : Using the PCM functions within the sound RAM doesn't work properly as Sega probably thought everybody would use sequences, but PCM streams are much easier to deal with.

I've been using a Mac emulator, so compatibility isn't that great and I have no Saturn Sound box which was needed to create some of the needed files.
So you need to create the tone data, then setup the sequences (which is where I'm stuck) and make a DSP program (if needed, but it can allow extra effects such as echo).

The SBL library is hard to use for that since the documentation is mostly in japanese and the code isn't really easy to read/understand.
Plus the demos just don't work in emulators for some reasons.

So in other words I'm not sure if I'll find a solution to these issues.
Title: Re: Sonic Z-Treme
Post by: XL2 on April 04, 2018, 08:27:27 pm
Ok, using SBL and the Tone Editor on my Mac emulator, I got audio played from Audio RAM working.
You need to create a bank with the "voices" you want (using AIFF PCM files) and create a map file.

On the Saturn, you load the sound driver and the map data.

For the map file :
Byte 0 : MSB at 0 = used, bits 6,5 and 4 are for the type, with 0 being tone data, 1 for a sequence. The next 4 bits are the bank ID number (so 0 to 15).
Bytes 1, 2, 3 : Last 4 bits of byte 1 and the remaining bits are for the adress of the tone in memory.
Byte 4 : MSB is 0, the rest seems unused.
Bytes 5 to 7 : size of the tone data.
You then need to use end codes for the area map and for the global map : so 0xff and another 0xff.
You could put a couple of map info for more than 1 bank.


Code: [Select]
char sound_map[]= {0x00,
0x00, 0xb0, 0x00, //Start adress
0x00, //except for the MSB, seems unused
0x05, 0x61, 0x22, //size of the tone data
0xff, 0xff //end code
};

That means my sound data takes 352 546 bytes (all at 11,025 khz, mono, 16 bits - using 8 bits would halve that).
The map can include sequences, but I couldn't get the tools working on the Mac emulator, so I use Midi direct commands to the sound driver.

You need to load your tone data in the sound RAM using the offset 0xb000.

Now, to playback the audio, here is the function I wrote :

Code: [Select]
void TEST_AUDIO(Uint8 nb)  //Nb = number, both for voice and channel
{
   SND_CtrlDirMidi(0x02, 0x00, 0x03, nb, 0x20, 0x00);  //Bank change. Not needed if you have only 1 bank
   SND_CtrlDirMidi(0x02, 0x00, 0x04, nb, nb, 0x00);  //Voice change. That's the sound you want to play (16 values max)
   SND_CtrlDirMidi(0x02, 0x00, 0x00, nb, 60, 127); //Stop playing the previous sound on the passed channel. It will stop playing at the end anyway, BUT that channel will remain flagged as used if you don't clear it)
   SND_CtrlDirMidi(0x02, 0x00, 0x01, nb, 60, 127); //Start playing the current sound on the passed channel
}


Sadly it would take a while to study the tone data file in order to recreate a tool on PC to do all that.
The tone data includes stuff like the pitch and loop data.
For the pitch, I put it at 84 (for 11,025 khz) on the tone editor, so I put it at 60 (44,1 khz) for the Midi direct command so that it plays it at the correct speed.

I could probably also check at v-blank which channels are done playing the sound to clear them, it would make it easier to manage the channels.
Title: Re: Sonic Z-Treme
Post by: corvusd on April 04, 2018, 09:45:21 pm
Good work! :D

SS not is the 32bit “easy machine” but in other way, it is a constant give challenges to a clever brain! ;)

I think that issues: “the CPU overhead” and “a little Sound memory”. In count part to PSX, for me is very similar situation. Is true that PSX is capable of use ADPCM, and have more sounds or more quality, or medium sound and quality. But in SDK PSX the sound program have CPU overhead, the access to DMA same situation. And the dev should fight whit this little memory to read on fly ADPCM track or mix ADPCM sound in Memory. In conclusion, for SS is very similar situation, but whit more processor run at same time. In this path the key is a good control of the all flow program bucle data management. Nothing that you not know. XD

For me the big problem, is the need it of specialize hardware to create sound or music in SS. More to load DSP program like, reverb, echoes, surround like or Qsound, 3D Qsound o Yahama 3D. And more, whit a MAC machine?? More good software and without extra hardware, It could been a better situation to compete whit PSX SDK, and sure make easy the life to de devs :)

Ideally, for your project and/or jo-engine in this area is build tools like you said. A tone editor for a modern PC. And we will can get: audio program bank, sequencer or DSP programs, and finally compile sounds in SS format like. I prefer that all this tools develop it whit toolkit open source and multi-platform, to guarantee the long life and maintained. But that you decide this aspect, is your project. ;)

Greetings!
Title: Re: Sonic Z-Treme
Post by: LackofTrack on April 05, 2018, 12:19:28 am
Good Job on figuring out how to use the Audio Ram and Tone Editor XL2!

For the music are you going to try to use SBL PCM-ADPCM Library to play back AIFF files or perhaps encode your audio to use XA ADPCM instead? Or will you just stick to CD Audio?
Title: Re: Sonic Z-Treme
Post by: XL2 on April 05, 2018, 12:29:35 am
Yes, I will mix both.
So for menus or title screen, I might use ADPCM to allow loading in the background and keep some space on cd.
I will use normal  cd audio for ingame for now, but using midi audio would be nice as well.
Title: Re: Sonic Z-Treme
Post by: LackofTrack on April 05, 2018, 12:35:50 am
Using Midi Audio would definitely be nice indeed but, don't you need an actual development kit for that?
Title: Re: Sonic Z-Treme
Post by: XL2 on April 05, 2018, 12:41:09 am
Yes, but the idea would be to write an app to do this. I would certainly take a while, but on another forum someone sent me an app that converts sequences to midi, so I would need to do the opposite.
Title: Re: Sonic Z-Treme
Post by: LackofTrack on April 05, 2018, 12:47:34 am
Ah. Gotcha. Well I hope you succeed in doing so. It would be really impressive for a Saturn homebrew to feature sequences.
I don't think that's ever been accomplished before. Good Luck!
Title: Re: Sonic Z-Treme
Post by: XL2 on April 05, 2018, 05:02:18 am
Thanks.
But if anyone wants to do it, it would be more than welcome for the whole community!
I need to finish the model converter I promised and continue working on the engine for a long overdue update.

Edit : Just added an image of PCM-ADPCM CPU overhead. Note that playing small sounds from memory is less expensive since you don't need to transfer data from the CD, but it still requires DMA and hogs the B-Bus.

Title: Re: Sonic Z-Treme
Post by: corvusd on April 05, 2018, 06:40:12 pm
Thanks.
But if anyone wants to do it, it would be more than welcome for the whole community!
I need to finish the model converter I promised and continue working on the engine for a long overdue update.

Edit : Just added an image of PCM-ADPCM CPU overhead. Note that playing small sounds from memory is less expensive since you don't need to transfer data from the CD, but it still requires DMA and hogs the B-Bus.

I know this table data. :)

But I have a doubt. The overhead are for 1x SH2, for 2x. For the M68000? For all?

And more. The formula use it to calculate this value % is this: R = (100 X Ttask) / Tplay

Whit this, really not know, which CPU refer, or quantity of cycles used for DMA transfers or decompress the ADPCM data... And another doubt is, use it DMA transfers via SCU or directly SH2 to 68EC000 or SCSP. Or both.

Last. ADX form CRI, is possible better implementation of ADPCM for SS. Burning Rangers or Deep Fear, play BGM all time, and use it also for speech or dialogues. I don’t know if is possible play more than one stream or more, play directly from RAM and mix "like" PSX. I cant find the SS library functions form ADX in the web.

Greetings!
Title: Re: Sonic Z-Treme
Post by: ponut64 on April 05, 2018, 08:47:07 pm
Burning Rangers does clearly play multiple CD Audio tracks at once, and I am not sure how it does that.

Maybe I am being fooled, and what they are doing is reading & playing one word at a time, so the voice data stream only consumes as much as the biggest word. Who knows. It's "Redbook Audio" quality, that /e is completely wrong and I am glad there are more educated people in here.
Title: Re: Sonic Z-Treme
Post by: LackofTrack on April 06, 2018, 12:38:22 am
Burning Rangers uses ADX audio which is able to play multiple tracks at once. How many I don't know.
Looking at the files it seems most of the music in BR is definitely not "Redbook Audio" quality. Most of them are only 22500hz which is also the sample rate for speech used in the game.
The sample rate's probably low to reduce the CPU workload. There are however some 44000hz (RedBook) songs in there. They seem to be only used for non CPU intensive areas (Menus, Title screen, etc).

Thanks.
But if anyone wants to do it, it would be more than welcome for the whole community!
I need to finish the model converter I promised and continue working on the engine for a long overdue update.

Edit : Just added an image of PCM-ADPCM CPU overhead. Note that playing small sounds from memory is less expensive since you don't need to transfer data from the CD, but it still requires DMA and hogs the B-Bus.

I know this table data. :)

But I have a doubt. The overhead are for 1x SH2, for 2x. For the M68000? For all?

And more. The formula use it to calculate this value % is this: R = (100 X Ttask) / Tplay

Whit this, really not know, which CPU refer, or quantity of cycles used for DMA transfers or decompress the ADPCM data... And another doubt is, use it DMA transfers via SCU or directly SH2 to 68EC000 or SCSP. Or both.


Last. ADX form CRI, is possible better implementation of ADPCM for SS. Burning Rangers or Deep Fear, play BGM all time, and use it also for speech or dialogues. I don’t know if is possible play more than one stream or more, play directly from RAM and mix "like" PSX. I cant find the SS library functions form ADX in the web.

Greetings!

Corvusd is definitely right. The data chart doesn't really do a good job at explaining what's happening to what.
Although I assume when it refers to CPU overhead it refers to the M68000. This is just a guess though.
Title: Re: Sonic Z-Treme
Post by: XL2 on April 06, 2018, 04:27:30 am
The overhead is, I guess, for the main SH2, since it get decompressed by the SH2, then it's no different from uncompressed audio once it's transfered to the audio RAM.
It could be that the SBL library isn't super efficient, but even for uncompressed audio it's still expensive to use PCM (even if it's "just" 5%.
And more importantly it hogs the B bus, which is the same bus used for the vdp1 and vdp2.
For the DMA, it's always SCU DMA on the b bus.

CD audio goes straight to the DAC, so it doesn't consume cpu power (the SH1 can't be used for anything else than loading). It's the easiest option.

Then sequence audio is great as well, you have the SCSP and the M6800 just for doing that, it has it's own RAM, it can playback PCM data (from its own memory), so it doesn't consume cpu power except for transfering the play commands. It's a bit tricky to use, but for fx sounds it's a no brainer.

PCM audio from CD is good to play voices or play music while loading data, but it should be avoided as much as possible.

PCM audio from memory is easy to use and convenient for that, but it really should be avoided.

I don't know if it's possible to keep data in the CD buffer, so that you could store 512 KB of PCM data in that RAM, but it would be a good option (if possible) to at least save some main RAM if you have to use PCM memory playback.

I would really like to use MIDI audio as it's the more flexible option and keep the CD available, but it's also the hardest to use.

EDIT : The program I mentionned which converts sequences to MIDI. Now we need to figure out how to do the other way around!
https://github.com/mistydemeo/seq2mid/find/master?q=
Title: Re: Sonic Z-Treme
Post by: corvusd on April 07, 2018, 11:29:08 am
Hello community!

[EDIT] For Overhead in sound stuff, From: ST-166-R4-012395
Quote
Overhead During Data Transfer

Since the PCM playback slot is fixed at 44.1 KHz, 1 sample is played back every 22.68 μs from the start of playback. Therefore when Vint is used, 735 samples (16,666 μs ÷  2.68μs) need to be rewritten (transferred) every 16 ms for one stream playback channel.

During DMA burst writes:
1 word transfer = 4 clock cycles (1 clock cycle = 35 ns)
Assuming 1 word transfer = 6 clock cycles to allow a margin of safety, then 6 clock cycles x 735 words = 4410 clock cycles (= 154.35 μs).
The SH2 requires approximately 154 μs to transfer 735 words (1,470 bytes).


However, if other sounds are being generated, or if the DSP is being used, the sound chip can only access the sound memory 20% to 30% of the time per one sound chip cycle (22 μs). This requires extra wait time, and since only 16 words can be transferred in one cycle (22 μs) of the sound chip, about 1 ms is required to transfer 735 words.

The 735 samples referred to by the equation above is for mono playback at 44.1 KHz. Overhead can be reduced to half if playback at 20 KHz is acceptable (equivalent to 368 samples).

When using DMA, avoid long, continuous transfers so that the sound CPU can operate. The sound CPU cannot operate during DMAs if data is transferred continuously.

For the ADPCM by CRI, the only stuff that exist in the web is this links:
https://wiki.multimedia.cx/index.php/CRI_ADX_file
https://wiki.multimedia.cx/index.php/CRI_ADX_ADPCM
https://en.wikipedia.org/wiki/ADX_(file_format)

If you see the principal part of code in examples decoder:
Code: [Select]
#define M_PI acos(-1.0)
 double a, b, c;
 a = sqrt(2.0) - cos(2.0 * M_PI * ((double)adx_header->highpass_frequency / adx_header->sample_rate));
 b = sqrt(2.0) - 1.0;
 c = (a - sqrt((a + b) * (a - b))) / b; //(a+b)*(a-b) = a*a-b*b, however the simpler formula loses accuracy in floating point
 
 // double coefficient[2];
 coefficient[0] = c * 2.0;
 coefficient[1] = -(c * c);

Are a lot the operations, that the SCU can be process really well. The theory that Burning Rangers uses the SCU-DSP is give a push, that whit this need it the SCU can be process this data.

Greetings!
Title: Re: Sonic Z-Treme
Post by: XL2 on April 07, 2018, 12:02:21 pm
Good idea for the SCU DSP.
If that's what Burning Ranger does, the entire code could be retrieved with Yabause.
But I thought they used it for lightning.
You can see when there is voice audio playback if the SCU DSP gets a program change.
Title: Re: Sonic Z-Treme
Post by: corvusd on April 07, 2018, 02:00:27 pm
Well, I will try.

But I think that SCU-DSP can be process the two task in parallel. In my analysis table data you can see that are free memory and registers for that.

 ;)
Title: Re: Sonic Z-Treme
Post by: XL2 on April 07, 2018, 02:49:50 pm
You can issue program change commands, but I highly doubt it can process programs in parallel.
Title: Re: Sonic Z-Treme
Post by: corvusd on April 07, 2018, 03:13:06 pm
You can issue program change commands, but I highly doubt it can process programs in parallel.

[EDIT] Well, is a fact the SCU-DSP are capable to process at 6 process per cycle. A program well design and using concrete types of RAM and DMA, could be possible make two parallel task.
Title: Re: Sonic Z-Treme
Post by: XL2 on April 10, 2018, 11:55:57 pm
Haha, just using the SCU DSP would be a great start!
It has really limited memory, so it can't do that much.

Update on the project, I've now moved from 16 colors Lookup tables to 16 color bank (CRAM). That means no more gouraud shading...but I will be able to use transparency, which is better.
I'm not sure if you can do color calculation over the back screen, but if you want the same effect as depth gouraud shading you can just put a black background and use the VDP2 transparency to have the same effect.
It also offloads work from the VDP1.
The only issue is that the color RAM is really limited, but so far it seems all the maps I tested got everything within about 1000 colors, and if it can't fit in CRAM I put a "safety" measure where it just uses CLUT.

I haven't made much progress on Sonic Z-Treme yet, so the game is currently improving only on a technical level, but I hope to be able to integrate everything in the game soon.

Title: Re: Sonic Z-Treme
Post by: corvusd on April 11, 2018, 09:10:18 am
Haha, just using the SCU DSP would be a great start!
It has really limited memory, so it can't do that much.

Update on the project, I've now moved from 16 colors Lookup tables to 16 color bank (CRAM). That means no more gouraud shading...but I will be able to use transparency, which is better.
I'm not sure if you can do color calculation over the back screen, but if you want the same effect as depth gouraud shading you can just put a black background and use the VDP2 transparency to have the same effect.
It also offloads work from the VDP1.
The only issue is that the color RAM is really limited, but so far it seems all the maps I tested got everything within about 1000 colors, and if it can't fit in CRAM I put a "safety" measure where it just uses CLUT.

I haven't made much progress on Sonic Z-Treme yet, so the game is currently improving only on a technical level, but I hope to be able to integrate everything in the game soon.

You not said that is possible use gouraud whit palleted color like chrome demo? You are check? I can't because I don't  have compiled and mastered iso the demo, and I don't know make it, for analysis in Yabause for see how work it.

In other hand, you can make also liike sonic R. Use gouraud whit lut from near clip to medium distance and change to whitout gouraud whit paleted to make fog fade to foreground vdp2.

Greetings!
Title: Re: Sonic Z-Treme
Post by: XL2 on April 11, 2018, 03:08:26 pm
The way they did it in the Chrome demo is that they use a palette of different luminances.
The VDP1 does the gouraud shading processing, but when it's using paletted sprites it just offsets an index instead of the actual RGB color.
So the result is that by using only red gouraud processing you will exactly offset +- 1 to 16 in each direction for each verticle.
You could do it with 16 colors banks, but then you could only do it with one color and only 7-8 different luminances, else it will overflow.

I could do like Sonic R, but I could also just put static lightning on the textures.
The issue with Sonic R is that you have gouraud on quads close to the camera, then you lose that luminance as it starts disappearing.
I have enough VRAM left to generate other textures for luminance.
From the videos of Saturn Shenmue, it seems to be what they did.
Speaking of Saturn Shenmue video, I noticed lots of triangles in the background (they get clipped out). So I'm not sure if it's running on a real Saturn or if it's using software rendering for backgrounds.
Title: Re: Sonic Z-Treme
Post by: XL2 on April 12, 2018, 03:12:18 pm
I just did a small video (it's not public as there isn't much to show) for the split screen mode and the removal of gouraud shading/use of CRAM sprites.

https://youtu.be/jHaXoe9lfMc (https://youtu.be/jHaXoe9lfMc)
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on April 13, 2018, 09:12:10 pm
Love it! Models kinda remind me of Wolf from VF
Title: Re: Sonic Z-Treme
Post by: corvusd on April 14, 2018, 10:52:32 am
I just did a small video (it's not public as there isn't much to show) for the split screen mode and the removal of gouraud shading/use of CRAM sprites.

https://youtu.be/jHaXoe9lfMc (https://youtu.be/jHaXoe9lfMc)

Really nice improvements!! Congratulations.

We can see source lighting in models no? Yo are calculate level of luminance or brightness, by VDP1 CC or change color palette for this face??

For calculate lighting use SH2 or SCU-DSP?

And finally. You can apply this lighting to scenery faces?

If you can all this without use CC, is possible you can use Full HiRes mode in VDP1 and VDP2.

Greetings!
Title: Re: Sonic Z-Treme
Post by: XL2 on April 14, 2018, 05:24:09 pm
The flat shaded quads in SGL can use flat lightning both in RGB and palette format.
I'm not using the SCU DSP yet, so it's SH2 only.
I can't do realtime light with color bank sprites, but I'm now doing like in Sonic R and Bulk Slash.

I can't use the high res mode, it's super hard to setup, so I don't want to waste time on it.
Title: Re: Sonic Z-Treme
Post by: corvusd on April 14, 2018, 10:42:01 pm
The flat shaded quads in SGL can use flat lightning both in RGB and palette format.
Perfect! :D

I'm not using the SCU DSP yet, so it's SH2 only.
Not mention SCU in the next two years. I promise XD

I can't do realtime light with color bank sprites, but I'm now doing like in Sonic R and Bulk Slash.
Why not? What refer exatly that doing like this games?

I can't use the high res mode, it's super hard to setup, so I don't want to waste time on it.
It is possible, the requirements are many and both VDPs. It is normal that you choose not to get involved in this. But is very attractive, have it full resolution SS in a Sonic game. :)
Title: Re: Sonic Z-Treme
Post by: XL2 on April 14, 2018, 10:56:08 pm
These games use the color calculation  (with ratios) to make a smooth fade in and fade out. It's what I'm doing now. It might be possible with CLUT sprites too, but I have to try a few more things first. But the only way to do actual gouraud shading on color bank sprites requires a ton of color RAM, but you only have 4 KB shared for all the background layers and the color bank sprites.
High res mode is attractive, but you can't simply flip a switch and make it work. You really need to setup everything in a specific way and there are many limitations.
I could try it for menus and such, but even for that I don't want to waste time on it.
Title: Re: Sonic Z-Treme
Post by: XL2 on April 20, 2018, 05:14:51 pm
Just a small update to show the Sonic R-style fade in/out.

https://youtu.be/r4Gkgqitv44
Title: Re: Sonic Z-Treme
Post by: ponut64 on April 21, 2018, 02:24:34 pm
Thanks for posting that here.

I always did have the idea of using VDP2 layers for fade-in / fade-out (obviously, what else would you use).
I'm curious though, are those RBG or NBG layers?
Title: Re: Sonic Z-Treme
Post by: XL2 on April 21, 2018, 03:56:24 pm
Well, gouraud shading works well for fade in/out as long as the color fits the backscreen.
I'm using a NBG0 bitmap layer, but with splitscreen managing the backgrounds gets a bit complicated.
Title: Re: Sonic Z-Treme
Post by: Joeveno on April 22, 2018, 04:19:24 am
Hello! It's me again!

What do you think of a Tony Hawk's approach in level design but with a point a to b style? with slopes, ramps and loops attached to higher ground around the scenario or a certain path for the player?

Something with this approach to level design (but of course, with a point a to b fashion and some of the ramps, and slopes attached to buildings and other areas of the scenario, as well as linear loops) :
(http://sonicretro.org/wp-content/uploads/2011/03/shadow_map1.png)
(https://i.ytimg.com/vi/awf8CJsppMs/maxresdefault.jpg)
                                                                          (http://sonicretro.org/wp-content/uploads/2011/03/shadow_map2.png)
                                                                           (https://vignette.wikia.nocookie.net/tonyhawkgames/images/0/00/THPS3_Tokyo_prev2.jpg/revision/latest?cb=20170820110327)

I Think that this style would work well with the Sonic Jam approach you want to apply into some levels, and would make a good use of the physics when it's more fleshed out :D cheers!
Title: Re: Sonic Z-Treme
Post by: Joeveno on April 22, 2018, 06:53:41 pm
Do you think that a Sonic Utopia gameplay style for Sonic would be possible for the project on Saturn? (have a big focus on momentum based gameplay, being able to curl into a ball and be affected by the terrain, gain momentum in loops, slopes, etc)
(https://i.giphy.com/zmEZXOd4h4kgw.gif)
(https://i.makeagif.com/media/4-22-2018/4kvZNz.gif)

Cheers!
Title: Re: Sonic Z-Treme
Post by: ponut64 on April 22, 2018, 10:01:28 pm
That's possible in some way, the question is, who is gonna make it?
Title: Re: Sonic Z-Treme
Post by: corvusd on April 22, 2018, 10:58:16 pm
Maybe is to soon to say something. XL now are learning and improve your engine, to put at limit SS. All your ideas are great and maybe possible. But, now not is the time to this. And this type of design, maybe, is too big for the machine or the actual technical resources. Thanks for your apports. 👍
Title: Re: Sonic Z-Treme
Post by: XL2 on April 22, 2018, 11:08:32 pm
Here it is running on real hardware.
I'm quite happy with the results as it's not optimized.

https://youtu.be/Bkpy5MdjM8I
Title: Re: Sonic Z-Treme
Post by: Joeveno on May 09, 2018, 07:22:57 pm
Hello!
Do you think that physics similar to Stunts (1990) at slopes and loops are possible in this project?
https://www.youtube.com/watch?v=XgceLrj3upY
Cheers!
Title: Re: Sonic Z-Treme
Post by: XL2 on May 18, 2018, 03:37:51 pm
Still a very long way to go : I'm not done with the rendering part and I haven't started to put gameplay back in (you can just move the camera around now), but I think it looks rather good so far.
You can see the draw distance is quite good!
I might have to reduce it a little bit, but it shouldn't impact too much the visual as the draw distance is a bit too far now (it should still be fine at 30 fps).
Plus with the transparency effect, I think most people won't mind and will instead appreciate the effects ;)
Title: Re: Sonic Z-Treme
Post by: corvusd on May 18, 2018, 09:35:17 pm
Still a very long way to go : I'm not done with the rendering part and I haven't started to put gameplay back in (you can just move the camera around now), but I think it looks rather good so far.
You can see the draw distance is quite good!
I might have to reduce it a little bit, but it shouldn't impact too much the visual as the draw distance is a bit too far now (it should still be fine at 30 fps).
Plus with the transparency effect, I think most people won't mind and will instead appreciate the effects ;)
Absolutely great improve.
Your new build whit the far fade clipping whit the VDP2 CC ratio and priority is great, same that Sonic-R or very similar. Sonic-R use static source Gouraud in all the rest scenery before fade.
And the Sonic and Tails whit Real Time Gouraud Light is amazing! :) All together look very nice an promising! Go Go! :D
You can see that me, are capable to appreciate all this effects and your GREAT efforts!! Thanks!! :D
Title: Re: Sonic Z-Treme
Post by: XL2 on May 18, 2018, 09:38:55 pm
I do plan on having static lights (the quads closer to screen use CLUT while the quads with CC use CRAM banks), but I'm quickly running out of time.
But if I think I can implement it in 1 or 2 hours I will sure try it!
Title: Re: Sonic Z-Treme
Post by: corvusd on May 22, 2018, 11:47:26 pm
I do plan on having static lights (the quads closer to screen use CLUT while the quads with CC use CRAM banks), but I'm quickly running out of time.
But if I think I can implement it in 1 or 2 hours I will sure try it!
fyi
https://www.youtube.com/watch?v=FdD0GvVRSMc&feature=youtu.be
:D
Title: Re: Sonic Z-Treme
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.
Title: Re: Sonic Z-Treme
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!
Title: Re: Sonic Z-Treme
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...
Title: Re: Sonic Z-Treme
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!
Title: Re: Sonic Z-Treme
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.
Title: Re: Sonic Z-Treme
Post by: corvusd on May 28, 2018, 09:58:42 pm
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.
You are great, that you fight for put more at limit the machine. Bravo!!!
I hope, soonly share it with you a little draft of my render pipeline idea.
See you soon! :)
Title: Re: Sonic Z-Treme
Post by: XL2 on June 16, 2018, 05:47:57 pm
Here is a new update on my new engine (WIP!) on real hardware.
I didn't implement back the physics/controls, so don't pay attention to that.
What's new : compressed per-vertex animation with interpolation (a bit like Crash Bandicoot and Quake 2), VDP2 transparency fade in, per-vertex realtime lightning (on Sonic only), audio using tones, splitscreen (not seen here), octree instead of an uniform grid for culling/collision, paletted/CLUT sprites, LOD model autogenerated for distant quads and probably many other things I forgot to mention.
Splitscreen works at a stable 30 fps from what I tested.

It's not optimized yet, so there is room for lot of improvement.

https://www.youtube.com/watch?v=J51wKAvJL7g (https://www.youtube.com/watch?v=J51wKAvJL7g)
Title: Re: Sonic Z-Treme
Post by: XL2 on June 23, 2018, 03:04:20 pm
Here is splitscreen in action (real hardware) : https://youtu.be/A3ClV-6aLdQ
Title: Re: Sonic Z-Treme
Post by: ponut64 on June 23, 2018, 11:04:18 pm
These improvements are hitting pretty rapidly, great work
Title: Re: Sonic Z-Treme
Post by: mindslight on July 10, 2018, 09:07:59 am
Very impressive. Homebrews reached a new level
Title: Re: Sonic Z-Treme
Post by: XL2 on July 10, 2018, 10:20:52 pm
Thanks.
Good news : SAGE as been pushed back one month, which should help me quite a bit to get a demo out in time.
I've also added support for very basic paletted light sources (per face instead of per vertex, so no gouraud for now).
I will have to improve my support for light sources, but it doesn't look bad and comes at no costs since it's just precomputed.

I might stick with this technique and maybe use gouraud shading on special objects to allow bump mapping (see third and fourth images for the SGL tech demos).
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 12, 2018, 06:18:21 pm
For the water, what if you set the name of the material of the water in the .mtl file to, for instance, "__WATER__" and your converter can detect and assign every face with that material to have all of the scripted behaviors and textures on those faces?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 12, 2018, 06:50:53 pm
I'm doing something similar, but I'm not reading the mtl file so I just use the texture name.
I will expand that system in the future to try to allow bump mapping.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 12, 2018, 10:13:53 pm
In one point, are you planning to add a power-up, or character that will utilize environment mapping?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 12, 2018, 10:52:46 pm
Environment mapping is a sure no, it's super slow to read from the framebuffer and there are no texture coordinates.
I am considering power ups but I have many other things to do first.

Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 13, 2018, 01:09:15 am
I thought you could've used the slave CPU to accomplish the task, like in Sonic r,  but what do I know? I'm sure that you've thought of that, but it just wasn't efficient enough to accomplish everything else in a 30th of a second, with environment texturing. Am I right?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 13, 2018, 01:15:38 am
I'm using SGL, which makes heavy use of the slave SH2, so it's not an option. Even in Sonic R they scrapped using it ingame, probably because it was too intensive for such a little effect.
If I were to use software rendering, it would be for something such as transparency on the NBG0 or NBG1 layer, using them as framebuffers.
And only if I could use the SCU DSP or sound cpu to do it.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 13, 2018, 09:56:31 pm
Using CRAM and paletted sprites/gouraud to create a bump mapping effect was easier than I thought.
It works, but sadly using the green gouraud didn't seem to work, so only the red worked for me so far.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 13, 2018, 11:12:13 pm
Can you release a video of the progress so far soon?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 14, 2018, 02:31:38 am
No, I will try to focus more on the gameplay for now.
I spend a bit too much time on graphics, but the gameplay is super buggy now.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 14, 2018, 05:02:29 am
Ok, scratch that, the green gouraud bug works on real hardware as I thought, but not on emulator sadly.
But it does allow pseudo environment mapping and easy switching between flat and gouraud shading.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 14, 2018, 05:09:06 am
Ok, scratch that, the green gouraud bug works on real hardware as I thought, but not on emulator sadly.
But it does allow pseudo environment mapping and easy switching between flat and gouraud shading.

Get your act together, emulators!
Title: Re: Sonic Z-Treme
Post by: ponut64 on July 14, 2018, 09:27:45 am
Do not get me started on the endless trial that is emulators...
Title: Re: Sonic Z-Treme
Post by: XL2 on July 14, 2018, 05:41:48 pm
Yes, it's frustrating. Try all main 3 emulators each time before burning a disk.
You should also try the USB cart if you don't need cd access for your tests.
At least I understand how the whole paletted gouraud shading bug works, so I can at least plan ahead and make sure it works on paper before wasting a disk.
But it does look truly amazing on real hardware, I hope I can expand it for more effects as it looks like something you would see on PS2 or Dreamcast, not Saturn.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 14, 2018, 07:40:11 pm
Are you going to try to have the jump animation vary in speed, depending on the vector of Sonic, like in the Genesis trilogy, or are you going to have it switch between two models, like in Sonic Adventure?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 14, 2018, 07:47:11 pm
I'm not sure I understand what you mean, but I don't have time right now to focus on little details as I barely got some gameplay.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 18, 2018, 06:44:20 pm
So I got some global lightning using per-vertex values, averaged for a flat per face lightning using palette shifts.
It looks ok, but it doesn't look as good as gouraud shading obviously, but with the palette restrictions it might be hard to do much better.


Title: Re: Sonic Z-Treme
Post by: ponut64 on July 18, 2018, 07:34:48 pm
When you have the maps made and shaded like that, it looks like Minecraft. (Which is good)
Is that faster than gouraud shading? probably is

Don't shoot me, I'm sure you get like 15 comments exactly like that on YouTube.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 18, 2018, 08:41:58 pm
It is "free" in terms of rendering speed since it's all precalculated and I'm just doing palette swaps to darken the shadowed areas (again, done offline).
I could easily put gouraud shading on the quads closer to the screen since I'm using a 16 color LUT, but the main issue are the quads away from screen since I'm using palettes for the transparency effect.
As I mentionned before, there is paletted gouraud bug that I can use (I use it on my metal version of Sonic), but it's not easy to use at all and it puts lots of limits.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 18, 2018, 08:49:24 pm
What are the limits that you've found when using this bug?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 18, 2018, 08:51:09 pm
I didn't discover the red gouraud bug, but I never saw anyone else knowing about the green gouraud bug. See previous posts for more information on this.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 18, 2018, 08:54:32 pm
Is it also possible for a blue channel bug exploit? You already have 2/3 of the color channels exploited.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 18, 2018, 09:06:08 pm
It should be, but it didn't seem to work when I used it.
It's not about the colors, but it's about how the hardware interpolates the gouraud shading, which shouldn't work, but since it still sends the interpolated data to the VDP2 you can play with the palette and use it to shift values.
Blue falls at bit 10 to 15, so it's inbetween the palette's address and the color calculation ratios, which means it can't be used unless you use sprite type 4.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 20, 2018, 04:34:32 am
Here it is in action with both the metal effect (working on real hardware nicely) using both green gouraud shifts (when the metal player is invincible) and red gouraud (both when invincible and not).
I added global lightning to the maps using per-vertex lightning and averaging the results to get a per-quad flat lightning shifting palettes.
I also added back rings and ennemies, but the ennemies are static since I didn't code in an insertion function for the octree nodes.

https://www.youtube.com/watch?v=Solq-N_jI28
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on July 20, 2018, 08:21:32 am
Sorry for a long absence but i just want to say thats amazing! I cant wait to finally get all my Sega stuff out of storage in the next week or two and try the new build when its released.

Again and again thanks XL2 you make all of us Saturn fans proud and keep up the good work!  ;D
Title: Re: Sonic Z-Treme
Post by: Joeveno on July 20, 2018, 03:06:20 pm
Hello! I've seen the last video! it's looking simply GORGEOUS!
How are the plans for the implementation of sonic's rolling / rolling attack going? And what about loops and slopes implementation? cheers!
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 20, 2018, 04:51:05 pm
I hate to be rude, but do you have a working capture device? I would like to see all of the gameplay without the glare, and the camera having to focus every time the screen fades to black. Great job, also.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 20, 2018, 04:54:48 pm
I don't have one, else I would be using it ;)
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 20, 2018, 05:03:34 pm
I've made a little animation that you would see probably as soon as the disc loads: https://drive.google.com/file/d/1DHAPk6PKQR4yRIAYsp-m2eDZc9x_s_Xk/view (there is no audio, yet ;))
Title: Re: Sonic Z-Treme
Post by: XL2 on July 21, 2018, 12:16:36 am
Thanks, but I already have logo screens that I use to hide loading.
Adding a video would defeat that purpose.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 21, 2018, 01:17:53 am
Don't sweat it! Besides, it only took one day to make it!
Title: Re: Sonic Z-Treme
Post by: jabfg on July 21, 2018, 09:57:20 am
I have been following your project for a long time and i have to congratulate you for your amazing work. The graphics look really good and the frame rate is consistent.
If you complete the game I will buy it.
But in my opinion the type of levels that Sega planned for the game look a bit too closed. So my question is, can your engine engine handle a more open concept like Mario 64 or, at least like ninpen manmaru (https://www.google.pt/url?sa=t&source=web&rct=j&url=https://m.youtube.com/watch%3Fv%3D6jHdiojWyBg&ved=0ahUKEwjOjsiJ2a_cAhXSPFAKHVd5D08Qo7QBCCQwAA&usg=AOvVaw2X1Sfk0rqsitgzd4UT_CAw)? And what are your ideas for the levels?
Title: Re: Sonic Z-Treme
Post by: ponut64 on July 21, 2018, 10:20:42 am
Every time I try to comment on XL2 / ZT technical information, I'm embarrassed by being incorrect. I will say this however, not for anyone, just an estimation.

- Expanding the game world to be more open [read: more polygons in the level geometry, farther view distance, more free camera] like SM64 entirely axes the possibility of 2-player. Is that important? Not my choice.
- Expanding the game world to be more open like SM64 carries technical possibility, but I think it would increase the texture warping and it would likely come with a decrease in apparent world texture resolution.
(the above based on the assumption that the polygons of world geometry become 'larger' in size to fit the scene into the polygon limit)
- XL2 might be facing memory limitations combined with polygon/sprite/view culling complications. These become worse with more things being potentially visible at once. Solving one or the other could be done with file system usage (reading visibility data based on sector or loading assets over other assets based on sector); combining the two into a unified solution would take a lot of time.
- Looking at Ninpen Manmaru however, I think there is definitely room to move the levels to be like that. But those levels are very very small.

- The big and VERY impressive push we're seeing is probably a build-up to SAGE, after which I imagine he might have more time to look at bigger changes.

Thanks again to XL2 to providing his technical expertise.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 21, 2018, 07:22:04 pm
Yeah, Ponut is right.
Now, offloading a lot of work to the vdp2 using a rgb0 plane would solve many issues, but using it in splitscreen is way harder since you need to use interrupts.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 21, 2018, 08:51:02 pm
Wait, if multiplayer uses interrupts, how did the dust (when you destroy an enemy) penetrate the other half of the screen sometimes?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 21, 2018, 09:12:40 pm
You just dicovered a bug!
I forgot to add an option to render only within the window screen.
It doesn't use interrupts.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 21, 2018, 09:18:03 pm
I forgot to add an option to render only within the window screen.

Aka masking ;)
Title: Re: Sonic Z-Treme
Post by: XL2 on July 21, 2018, 09:21:18 pm
There is an hardware feature, called windows, where it doesn't draw to one part of the screen.
That's what Lobotomy did with their slavedriver games to have little overdraw.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 21, 2018, 09:38:18 pm
Also, some faces in multiplayer actually pop in and out of rendering, even though it seems it's well within the radius of rendering for at least one player.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 21, 2018, 09:40:18 pm
That seems like a z sort issue.
There is no z buffer on the Saturn, so that happens all the time.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 22, 2018, 12:52:56 am
Anyways, can I make the animations for Tails? I have a Sonic R Tails rig in Blender. Would that be sufficient?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 22, 2018, 01:17:10 am
If you can find a way to reduce the number of vertices under 200 and use as few textured quads as possible (I would suggest to not use any textures on the tails), sure!
You can find my model converter in another post and play with it to understand how it all works.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 22, 2018, 08:58:13 pm
I present to you... the animation!  ;D

I just did a lot of limited dissolves in Blender, and some manual tweaking, and surely enough, I got the vertex count under 200!
Title: Re: Sonic Z-Treme
Post by: XL2 on July 22, 2018, 09:12:19 pm
Nice!
I am not in front of my pc for the next week or so, so I won't be able to test it.
Did you try it within an emulator?
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 22, 2018, 11:00:52 pm
It seems that I have to fix the textured polys; they aren't displaying. Oh well! Back to the drawing board!
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 23, 2018, 01:02:22 am
I've assigned the textured polygons in 32x32 blocks, and after all of the compiling and everything, any emulator stops responding. No debug message... nothing. I set all of the .tga files to have RLE compression, and to have the origin be at the bottom left. Is this an issue with the model? Oh, and here's a tree of the input folder:

:
Code: [Select]
    CHEST.tga
    CHEST_2.tga
    C_BLACK.tga
    C_ORANGE.tga
    C_RED.tga
    C_WHITE.tga
    EYE 4.tga
    EYE.tga
    EYE_2.tga
    EYE_3.tga
    tails chest.png
    tails eye.png
    tails.obj
    tails_000001.mtl
    tails_000001.obj
    tails_000002.mtl
    tails_000002.obj
    tails_000003.mtl
    tails_000003.obj
    tails_000004.mtl
    tails_000004.obj
    tails_000005.mtl
    tails_000005.obj
    tails_000006.mtl
    tails_000006.obj
    tails_000007.mtl
    tails_000007.obj
    tails_000008.mtl
    tails_000008.obj
    tails_000009.mtl
    tails_000009.obj
    tails_000010.mtl
    tails_000010.obj
    tails_000011.mtl
    tails_000011.obj
    tails_000012.mtl
    tails_000012.obj
    tails_000013.mtl
    tails_000013.obj
    tails_000014.mtl
    tails_000014.obj
    tails_000015.mtl
    tails_000015.obj
    tails_000016.mtl
    tails_000016.obj
    tails_000017.mtl
    tails_000017.obj
    tails_000018.mtl
    tails_000018.obj
    tails_000019.mtl
    tails_000019.obj
    tails_000020.mtl
    tails_000020.obj
    tails_000021.mtl
    tails_000021.obj
    tails_000022.mtl
    tails_000022.obj
    tails_000023.mtl
    tails_000023.obj
    tails_000024.mtl
    tails_000024.obj
    tails_000025.mtl
    tails_000025.obj
    tails_000026.mtl
    tails_000026.obj

And this is what one of the .mtl files say:
:
Code: [Select]
# Blender MTL File: 'tails walk fix.blend'
# Material Count: 10

newmtl CHEST
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.124741 0.000000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 0
map_Kd C:\Users\ADMIN\Desktop\tails sonic r\tails chest.png

newmtl CHEST_2
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.124741 0.000000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 0
map_Kd C:\Users\ADMIN\Desktop\tails sonic r\tails chest.png

newmtl C_BLACK
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.000000 0.000000 0.000000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 0

newmtl C_ORANGE
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.124741 0.000000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 0

newmtl C_RED
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.640000 0.000000 0.001040
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 0

newmtl C_WHITE
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.800000 0.800000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 0

newmtl EYE
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.640000 0.640000 0.640000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 0
map_Kd C:\Users\ADMIN\Desktop\tails sonic r\tails eye.png

newmtl EYE_2
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.124741 0.000000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 0
map_Kd C:\Users\ADMIN\Desktop\tails sonic r\tails eye.png

newmtl EYE_3
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.640000 0.640000 0.640000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 2
map_Kd C:\Users\ADMIN\Desktop\tails sonic r\tails eye.png

newmtl EYE_4
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.640000 0.640000 0.640000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 2
map_Kd C:\Users\ADMIN\Desktop\tails sonic r\tails eye.png


I don't really understand what I'm doing wrong here...

Thanks!
Title: Re: Sonic Z-Treme
Post by: XL2 on July 23, 2018, 01:09:10 am
My converter doesn't read RLE compression, so I guess that's your issue.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 23, 2018, 01:16:19 am
I just discovered that wasn't the main issue... It's probably the map_kd flag for the materials, because I can't think of anything else wrong at the moment...
Title: Re: Sonic Z-Treme
Post by: XL2 on July 23, 2018, 01:18:42 am
It doesn't even read the mtl file.
Read every post in the other topic about the converter, I think it was all explained there.
Title: Re: Sonic Z-Treme
Post by: ponut64 on July 23, 2018, 01:48:25 am
In essence, in Blender, yes you do export the file with materials. No, the converter does not read the MTL file.
The material name must match the material in Blender.
Another thing I found is the conversion process can be sensitive to file names. make sure they are short and make sure the starting OBJ file name matches the folder name.
Crashing with no error message may indicate you're trying to display an animated model before it is fully loaded, but what do I know?
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 23, 2018, 01:49:27 am
Turns out the crash was because texture EYE_4 wasn't found because I forgot to put the underscore! The textures... were... well... let's just say tails looks absolutely hilarious...
Title: Re: Sonic Z-Treme
Post by: XL2 on July 23, 2018, 01:58:37 am
Please just burn it with fire!!
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 23, 2018, 03:38:22 am
Just a little bug... but the model converter doesn't have an #endif after an #ifndef. just a minor inconvenience, though...
Title: Re: Sonic Z-Treme
Post by: XL2 on July 23, 2018, 03:41:56 am
It wouldn't compile, so are you sure you didn't delete it by accident? Also, please for questions about the converter use the other topic so that we can keep the relevant info there.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 23, 2018, 04:58:06 am
I have been messing around with tails.h, to get rid of what seems to look like inverted backface culling, with copying anorms.h, and I've had no luck. How did you make backface culling work correctly?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 23, 2018, 05:02:43 am
Only use the ztp file.
Make sure your normals are in the correct position in blender (activate backface culling in Blender).
And again, please move your questions about the converter in the converter topic, not here.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 23, 2018, 10:30:05 pm
Here is me running it in yabause, with a buffering frame and all (pardon my lack of consistency of the frame rate, I use a potato): https://youtu.be/1Kx3yX9Pq5g
Title: Re: Sonic Z-Treme
Post by: XL2 on July 24, 2018, 01:53:12 pm
Thanks.
Where the arms intented to swing this way?
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 24, 2018, 04:05:21 pm
The rig was a little messy, I must say. I didn't focus on the animation that much because I was learning how the converter works. I can fix it later.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 25, 2018, 02:12:48 am
No rush, I don't think I will have time to integrate Tails anyway.
But I feel Tails would be overpowered if he can fly, so I have to think about that too.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 25, 2018, 02:43:00 am
I think we can overcome that. Like Sonic Adventure, add the requirement to mash that "A" button, and add a stamina to his duration of flight.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 25, 2018, 03:00:33 am
The maps are rather small, there is no challenge if Tails can go high.
I guess I could allow to only fly higher once and then keep flying until you touch the ground or something like that, but I will see I need to focus on my culling and collision code for now anyway.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 25, 2018, 07:42:29 am
Do you anticipate you’ll be using my animation in the near future?
Title: Re: Sonic Z-Treme
Post by: XL2 on July 25, 2018, 05:46:44 pm
Not in the near futur for sure, I won't have time to implement different gameplay.
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on July 26, 2018, 02:20:56 am
Looks like everyone is doing great work! ;D
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 26, 2018, 08:55:15 pm
Anyway, I made a badnik for Crystal Frost which should be a lot easier to implement. I hope the game is nicely coming along!
Title: Re: Sonic Z-Treme
Post by: XL2 on July 26, 2018, 09:20:31 pm
 How many polygons does it have? I see 200, which is way too much for a single enemy
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 26, 2018, 10:40:58 pm
Got it to use just 45 faces, just by using a cube instead of an icosahedron as its base.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 27, 2018, 01:24:08 am
The Saturn supports quads wrapped around themselves, but the normals will give you problems.
Try to use untextured quads as much as possible as they are super cheap to render. Look at my drill model, it's super limited in quads/vertices but thanks to gouraud shading it looks like it has more polygons, so I can easily put 4 of these enemies on screen without slowing the game down.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 27, 2018, 01:37:34 am
D'oh!
Title: Re: Sonic Z-Treme
Post by: itsstillthinking1999 on July 28, 2018, 05:22:45 pm
Those are amazing! Far better then the recreations iv been working on ;D
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 31, 2018, 04:21:31 pm
I made a Robotnik model, which only has exactly 100 vertices. I don't exactly know how I landed right on 100 with the vertex count.  8)
Title: Re: Sonic Z-Treme
Post by: XL2 on July 31, 2018, 04:24:35 pm
Wow, that's nice.
But are you sure you only have quads/triangles?
Anything with more than 4 faces won't work on Saturn, so I'm just making sure.
I would suggest also to make his nose untextured but in 3D.
Overall that looks really nice!
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 31, 2018, 04:29:46 pm
Yes, I did make sure. There was a pentagon on the bottom. I triangulated it, then made it into quads. His nose is in 3d. However, the normals are acting up even though I made blender calculate them.
Title: Re: Sonic Z-Treme
Post by: XL2 on July 31, 2018, 04:30:31 pm
Good job!
I see you're having fun with my converter :P
Edit : The normals are recalculated with the converter because of the scaling btw. It also uses compressed normals, so the precision isn't that high.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 31, 2018, 06:17:42 pm
Well, what can we do about it? ¯\_(ツ)_/¯
Title: Re: Sonic Z-Treme
Post by: XL2 on July 31, 2018, 06:23:48 pm
What do you mean by "they are acting up"?
If you mean a "round" quad, you can use the DUAL_ flag in front of your texture to make it dual plane, then it won't be affected by the normal.
Only do that for as little quads as possible else you will increase the VDP1 workload.
Title: Re: Sonic Z-Treme
Post by: ponut64 on July 31, 2018, 09:58:54 pm
Check model scale/size if the normals are "acting up".
(go lower, or higher, see if issue persists)
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on July 31, 2018, 10:26:58 pm
I didn't think that the scale of the obj would matter. Thanks!
Title: Re: Sonic Z-Treme
Post by: XL2 on July 31, 2018, 10:35:41 pm
For the animation it does because it compresses the vertices, so you lose precision, mainly at the higher bits.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 01, 2018, 02:29:53 am
Here is Robotnik's running animation: https://www.youtube.com/watch?v=Thn7xbAuM9Q
Title: Re: Sonic Z-Treme
Post by: XL2 on August 01, 2018, 02:31:51 am
Sorry to say that but it looks a bit...special.
Robotnik is way too flat too, his arms are a sheet of paper.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 01, 2018, 02:35:07 am
I thought I was the only one who saw that! The upper half of Robotnik was from Sonic R. But I must agree, they look ludicrously flat. I thought you would let it ride because he’s an NPC.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 01, 2018, 07:01:12 pm
Okay, I made the hands have some depth. However, I’m typing this message on my iPad, so I can’t give you a screenshot right now. 😐
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 01, 2018, 11:17:37 pm
for some reason, the rig I got online had one of Robotnik's arms lodged further in his body than the other. I fixed that, and I made the arms have some kind of depth... It should be fine now. May this also be used in the near future?
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 05, 2018, 08:47:00 pm
So, why do polygons that are right next to the camera have a distortion where it doesn't stay on the same plane? I'm guessing it's because the 4 points cannot go beyond coordinates in this overscan the Saturn has around the screen.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 06, 2018, 12:26:43 am
Here is a fire texture that's more suitable for scrolling: https://drive.google.com/file/d/1YvTsylvIAh6TVqJ7qskU9QG4YX2chWXf/view?usp=sharing

If done correctly, it should look something like this (the pot and flame were made in Flash 8): (https://i.imgur.com/kVdfwFl.gif)
Title: A suggestion for shading
Post by: 20EnderDude20 on August 08, 2018, 08:12:30 pm
So, can you make the shadows normal sprites to get all of the benefits of transparent pixels? Just get rid of perspective distortion and instead use skewing, because it's a minor detail. Would that be a good trade-off?
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 09, 2018, 06:16:51 pm
Actually, you might not even need skewing or even rotation for circular shadows, because it looks the same from all angles. So you might only need to make it a scaled sprite, which can let it be transparent.
Title: Re: Sonic Z-Treme
Post by: jabfg on August 12, 2018, 05:18:54 pm
Any news about Sonic Z-Treme?
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 12, 2018, 06:22:00 pm
Presumably, XL2 went to SAGE, and showcased Sonic Z-Treme, and it went successfully. But I would like to know what's up too.
Title: Re: Sonic Z-Treme
Post by: Jorhlok on August 12, 2018, 11:42:42 pm
Via the last post on SAGE from SonicRetro: http://sonicretro.org/2018/07/sage-2018-information-delay-booths-trailer-and-more/

"SAGE 2018 is DELAYED to August 25th through September 1st."
"We will now be accepting submissions to SAGE up until August 18th."

I imagine at least until the 18th XL2 will be polishing Z-treme as much as possible.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 12, 2018, 11:53:45 pm
I imagine at least until the 18th XL2 will be polishing Z-treme as much as possible.
In his latest video's description, it said,"Here is a SAGE 2018 preview of the demo I will submit in 2 weeks." And the video was uploaded on July 31st.
Title: Re: Sonic Z-Treme
Post by: XL2 on August 14, 2018, 08:25:52 am
I have a newer version for sage, but only a couple more physics and graphical additions.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 14, 2018, 03:46:07 pm
Does that include the loop-de-loop physics?
Title: Re: Sonic Z-Treme
Post by: ponut64 on August 14, 2018, 03:58:33 pm
We'll see from/at SAGE.
Title: Re: Sonic Z-Treme
Post by: 20EnderDude20 on August 14, 2018, 03:59:47 pm
Would this become a full game after sage?