Recent Posts

Pages: [1] 2 3 ... 10
1
Yes, I would suggest you to start with 2d, it's much easier.
2
Maybe just some little 2d game to try to understand it all?
3
General discussion about the Sega Saturn / Re: Porting games like System Shock a dumb idea?
« Last post by XL2 on December 13, 2018, 08:50:18 pm »
I would suggest you to start small, porting such a game would require a ton of work.
4
About you / hi-o!
« Last post by dave5678 on December 13, 2018, 06:45:10 pm »
Recently found Jo Engine. I am not a programmer at all but I am getting back into Saturn collecting and play it every night with my son. Hoping to get programming and learning on the Saturn. I don't care about anything modern and its not a part of my career so no big deal. My free time at work and home will be learning what I can do with this. Thank you!
5
I am not a programmer at all but I have always loved the Saturn. I want to be a part of this team. Is there anyway I could port something written in C to the Saturn using Jo Engine? Or am I just not understanding this?

...back to my nonstop YouTube videos regarding C++, lol!
6
General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn
« Last post by XL2 on December 06, 2018, 06:02:02 am »
Ok, so I got a technique similar to Burning Rangers working.
I'm doing like BR, letting the VDP1 rasterize the sprites, SCU DMA the frame buffer to work RAM, then SCU DMA it to VDP2 VRAM, but instead of swapping the frame buffers or clearing it, I'm actualy using an offscreen area of the frame buffer.
So I don't have that 16 ms latency that BR had (well, it's my understanding from reading the VDP1 technical manual), so the game can still hit 60 fps in some areas (there is an impact on framerate, but lower than what BR did).
I had to work around SGL to get these working as, obviously, SGL never planned the hardware to be used in such a way.

If anyone is wondering how to do it :
1) Set your NBG0 or NBG1 layer to bitmap, 16 bits, scale x up by 2.2, y by 2.
2) Modify your system clip command to allow a range from 0 to 511 for the x value. No need to modify y.
3) Each frame, use a local coordinate of 432, 56, write a custom draw command and use a scaled sprite (8x1, no preclipping (faster this way), using a VDP2 palette value of 0 with no transparent pixels). Leave if in vram if you aren't using SGL. Also use a clipping window (352 to 511, and 0 to 111)

4) For each loop in your game's logic, start by DMAing the frame buffer array to the NBG0/1 VRAM (I use bank A0) with a for loop (like y=0; y<112; y++) and send the array in work ram line by line using SCU direct DMA.

5) Write - using custom draw commands - sprites or polygons that you will need to scale them (multiply) by x:0.454545 and y:0.5 in screen space coordinates to an offscreen area. Either use SGL's windows (far) for the transparent sprites, or just send them far in your drawing list to make sure they get drawn first and, more importantly, make sure they are affected by the correct local coordinates command.

6) Some time before vblank, DMA the frame buffer to work ram using again a loop to skip the lines and data. If you want to be safe, you can use the VDP1 registers to make sure you got past all transparent objects before DMAing the data. It will pause the drawing, so be warned! Transfer only what you need and ASAP.

7) Vblank, go back to point 4.

Of course, it won't solve the sorting issues since your transparent objects will be on top of everything, so you can use a low-quality model of your avatar using again mask values (0) and send them to the offscreen area, sorting everything with the current draw commands. You would also need to either send polygons masking the walls and all to the offscreen area or use a more fancy no-overdraw technique (such as portals, BSP, etc.).


7
General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn
« Last post by corvusd on November 26, 2018, 11:17:37 am »
Hello XL2,

forgive me for not answering you before, here or in Discord.

As you had planned, your idea to do H-T without overdraw is another genius work on your part. :)

After thinking about it a little. I agree with you that it can be a problem, this amount of Draw Calls. In a way it reminds me of Doom and Defcon 5. I do not know if there are any more games that I draw by "lines" in SS. But both are quite bad in SS, similar or worst to 3DO, in contrast to PSX much better than both. It may be that it is easier to optimize calls on PSX because of the simplicity of the system against SS, or even because of the best optimized tools, although this year I doubt they were available even on PSX. Finally it is true that both are two ports very improvable for SS and that they had come from previous systems, which does not help.

All in all, I think it is a very good solution, for elements such as: Crystals, square shadows ... in short, simple forms, with a quad or two triangles. Still it would be possible to save the problem of mixing it with the VDP2. But as a sub-function within a larger function that simplifies this "subject" in SS, it would be ideal. Come on, what should have been done in his day.

Thank you for your great work!

Regards,
8
General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn
« Last post by XL2 on November 23, 2018, 07:42:25 pm »
I spent some time writing a proper software rasterizer.
The full-software mode doesn't work correctly yet, but the line rasterizer works pretty well (you calculate the edges and then send them to be rendered as lines for each scan line).
It does create a few issues :
-The edges overlap, which leads to overdraw (solution will be to have some kind of active edges and clip them against each other).
-It creates many lines (like 800 for a 12 triangles cube), which should be reduced with the active edges clipping and by allowing the lines to be rendered vertically as well depending on the height/width ratio. Another solution would be to use polylines with a depth of 2 pixels (so each line covers 2 scanlines, so one polygon - with other techniques - takes maximum 112 polylines for a size of 224 pixels).
-It is more CPU intensive than just sending the data to hardware as is.

While the Burning Rangers technique seems very nice, it's also quite hard to pull off and it's probably quite slow.
But its "worst" case scenario will be much faster than my worst case scenario for sure.
Another idea I might try is to use scaled sprites instead of lines and play with the RAM addresses. But it will have some weird distortion for sure.

Anyway, this whole technique could be useful for games such as racing games or for one effect (like a window) in a game.

9
Project announcement / Re: Sonic Z-Treme
« Last post by XL2 on November 14, 2018, 02:54:00 pm »
Well, I'm not working on Sonic Z-Treme anymore, while I put very little time on the fps project. It should take a few months before I have something to show on Saturn.
10
Project announcement / Re: Sonic Z-Treme
« Last post by jabfg on November 13, 2018, 07:42:46 pm »
How is your project going, XL2?
Pages: [1] 2 3 ... 10
SMF spam blocked by CleanTalk