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.
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!
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)
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!
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 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.
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))
(PS what is Retro Barcelona? 8))
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.
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.
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.
Sonic on Quake level ;D OMG :D
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.
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
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.
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!!!
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.
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).
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.
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.
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.
The Doom engine has large open space, which isn't too great on the Saturn.
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.
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!
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
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).
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).“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?
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.
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.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.
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.
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)
You mean with the Jo Engine functions?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.
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.
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)
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)
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.
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
};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
}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.
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!
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.
#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);You can issue program change commands, but I highly doubt it can process programs in parallel.
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.
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)
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. :)
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.Absolutely great improve.
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 ;)
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.fyi
But if I think I can implement it in 1 or 2 hours I will sure try it!
Nice, I didn't see it.Your current implementation is very good.
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.
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.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.
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...
I think I found a solution!You are great, that you fight for put more at limit the machine. Bravo!!!
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.
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.
I forgot to add an option to render only within the window screen.
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
# 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 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.
Does that include the loop-de-loop physics?
slCDDAOn(127, 127, 0, 0);slCDDAOn(127, 127, -127, 127);I'm using SBL for the audio.
You mean only the left or right speaker is outputting cd audio?
SND_SetCdDaPan(-15, 15);I'm using SBL for the audio.
You mean only the left or right speaker is outputting cd audio?
No I mean both channels are being "squished" into the center as if the audio was mono. Also If you are using SBL I think the correct command is:Code: [Select]SND_SetCdDaPan(-15, 15);
Yeah, but the solution is to subdivide the map further. The PS1 had that feature in the sdk from day one. The Saturn, as usual, doesn't and can't really do it. I'm trying to find a way to clip textures in vram to subdivide it in 4, but I'm not sure it will work.These days I was watching what you told me that the SCU-DSP would not be useful for real time tesselation. Looking at the PSX SDK, it seems that it uses the GTE for it, but I'm not sure that it's for everything. I mean, I think for tessellation. The GTE is used to recalculate the UV coordinates of the new polygon or polygons. But I think that to divide it uses the CPU. In a technical document a developer asks which is better to divide the GTE or the CPU and they respond to the CPU. Which we can apply to the SS because the SCU-DSP and the GTE are very similar doing addition and multiplication to dot product mainly. And the SH2 has divison instruction. Unless divisions can be made with multiplications of decimal numbers in the GTE and in SCU-DSP?
Quake maps do work with OKish draw distance, but have a very high poly count and vertices count. Still, 30 fps with Sonic and some 920 drawn polygons on screen isn't too bad considering all the overdraw.
I made some little progress on the bsp tree, but there are many problems to solve as nothing found online mentions quads or small polygons, so it might take a while to make it all work.