Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - XL2

Pages: [1] 2 3 ... 9
1
Wow, that was fast!

If the nb of bytes remaining to be read is less than the sector count, will it get past that point or does it ajust accordingly?

I say that because I need to split where the data goes since my files are larger than the available RAM and reading past the limit will break everything up.

EDIT : I did a quick test, and as I suspected there is no "safety net". I guess the way around this is to check if the remaining number of bytes to be read is less than the sector count, then switch to reading one sector at a time.

2
Jo Engine Wish List / Re: Import Tilemaps
« on: February 20, 2018, 06:33:40 pm »
Good to know!
2D on Saturn is indeed very interesting, sadly I don't have the patience to create sprites and deal with animations, so I'll stick with 3D for while. ;)

3
After doing some tests on real hardware, I came to the conclusion that the read_next_bytes function is super slow.

If I understand correctly, it's reading 1 sector at a time, which causes waits as data gets transfered from the CD buffer to the memory.
As an example, reading a 1,4 Mb file took me around 1 minute 30 seconds, but in a game such as Quake the same file would take around 20 seconds or less to load.

I really like the flexibility with the read next bytes since it allows me to load files larger than 1 MB, but I think it could be improved a lot by doing something more like the asynch read (like read 10 sectors at a time, send the data straight into the specified buffer - Low work RAM in my case -  like in the SBL documentation vol.1 p. 18).

In the meantime, I started to try to write my own functions, but it would be nice to have a speed boost within the default Jo Engine functions.


4
Jo Engine Wish List / Re: Import Tilemaps
« on: February 20, 2018, 05:32:11 pm »
It wouldn't work simply because how the SGL workarea works.
You will need to cull the sprites that aren't on screen.
It should be quite easy using a simple grid, but since I never use the 2D functions I couldn't tell you exactly how you could do it.
The idea is that if each tile is like 32 pixels wide and your screen is 320 pixels wide, you only show tiles that are within 5 or 6 units of the screen's center.
Perhaps a new map rendering function would need to be create as I don't think the current functions cull-away the sprites that aren't onscreen.
SGL will discard the sprites that aren't on screen, but they will still get processed and fill the workarea quickly, so you need to do culling on your end too.

5
Project announcement / Re: Sonic Z-Treme
« 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.

6
Project announcement / Re: Sonic Z-Treme
« 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.

7
Project announcement / Re: Sonic Z-Treme
« 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.

8
Project announcement / Re: Sonic Z-Treme
« 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.

9
Project announcement / Re: Sonic Z-Treme
« 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.

10
Project announcement / Re: Sonic Z-Treme
« 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).

11
Project announcement / Re: Sonic Z-Treme
« 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


12
Project announcement / Re: Sonic Z-Treme
« 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.

13
Project announcement / Re: Sonic Z-Treme
« 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

14
Project announcement / Re: Sonic Z-Treme
« 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.

15
General Jo Engine Help / Re: TGA not found
« on: February 08, 2018, 02:49:07 pm »
Make sure you have no RLE compression and that your TGA files are in the "cd" folder. For binary, just use the Jo Engine editor.

Pages: [1] 2 3 ... 9
SMF spam blocked by CleanTalk