Reading from the framebuffer?

And it seems like it works!
I haven't tried on real hardware, but it should work too.
In these pictures, only the "sparkles" are using VDP2 transparency so it might be a bit hard to see.
It's also very low definition at just 160x112 so I guess it will look better with flat polygons and gouraud shading.

The only remaining issue is the scale as I just want to scale x by 0,455 and y 0.5 to have everything fit where it should go, but simply scaling my matrix will lead to issues (I just want screen space scaling).
Maybe I'll just manualy fix the draw commands or manualy generate draw commands, but it would be better to avoid always "patching" SGL and redo everything it does.

Edit : Added another picture with a basic box to better show how the transparency works on both VDP2 layers and VDP1. But the scale is still wrong, I will try to find a way to fix it this week.
 

Attachments

  • vdp2_trans.png
    vdp2_trans.png
    191.7 KB · Views: 340
  • vdp2_trans2.png
    vdp2_trans2.png
    177 KB · Views: 411
  • vdp2_trans4.png
    vdp2_trans4.png
    267.7 KB · Views: 393
  • vdp2_trans5.png
    vdp2_trans5.png
    147.9 KB · Views: 337
Last edited:
Excellent work.

This is a bit off topic, but I wonder if it's possible to use the SCU-DSP for software translucency (similar to PlayStation blending modes).

Possibly perform it in 8x8 or 16x16 "tiles". You have two tiles in each bank, and DMA the results to VDP2.
 
Excellent work.

This is a bit off topic, but I wonder if it's possible to use the SCU-DSP for software translucency (similar to PlayStation blending modes).

Possibly perform it in 8x8 or 16x16 "tiles". You have two tiles in each bank, and DMA the results to VDP2.
You mean using software rendering? I already wrote a simple software renderer using lines for transparency before trying the current technique.
The line technique is looking quite good but it creates too many draw commands.
The SCU could be useful to create the edges, but it has too limited memory for anything ambitious.
You can of course use different transparency ratios on the NBG0 or NBG1 layer, but it will apply on the whole layer.
I never tried per pixel color ratios, but that could be another solution using the BR technique for different blending values.
The only negative points are the sorting and the low definition.
For the speed, it seems to be quite fast with little impact on the framerate, but I need to use custom draw commands as it doesn't play nice with SGL.

Edit : With custom draw commands and proper scaling. I could probably not scale up that much and accept some lost pixels on the side of the screen to avoid such large edges, but I don't know if I should.
 

Attachments

  • 20181205_233139.jpg
    20181205_233139.jpg
    380.5 KB · Views: 396
  • Transparency.png
    Transparency.png
    71.3 KB · Views: 380
Last edited:
Tested on real hardware and it works fine!
The framerate is mostly at 30 FPS, but it slows down more often to 20 than before (some optimizations would help improve that).

On a side note, could anyone give me a hand transforming some SGL functions?
It would be faster that using my own code since I could just use the whole SGL pipeline.
I just need to scale at screen space (again, x * 0.454545 and y * 0.5) after the transformation.
I know almost nothing about assembly atm, so could anyone point me where to look at?
Thanks!

Code:
sglC08.o:     file format coff-sh


Disassembly of section SLPROG:

00000000 <_slPutPolygon>:
       0:    e0 01           mov    #1,r0
       2:    c0 73           mov.b    r0,@(115,gbr)
       4:    c5 55           mov.w    @(170,gbr),r0
       6:    70 01           add    #1,r0
       8:    c1 55           mov.w    r0,@(170,gbr)
       a:    c6 22           mov.l    @(136,gbr),r0
       c:    51 41           mov.l    @(4,r4),r1
       e:    63 03           mov    r0,r3
      10:    c6 1d           mov.l    @(116,gbr),r0
      12:    65 3d           extu.w    r3,r5
      14:    62 0d           extu.w    r0,r2
      16:    32 1c           add    r1,r2
      18:    32 56           cmp/hi    r5,r2
      1a:    8d 46           bt.s    aa <ptpl_09>
      1c:    65 29           swap.w    r2,r5
      1e:    52 43           mov.l    @(12,r4),r2
      20:    43 29           shlr16    r3
      22:    40 29           shlr16    r0
      24:    30 2c           add    r2,r0
      26:    30 36           cmp/hi    r3,r0
      28:    8d 3f           bt.s    aa <ptpl_09>
      2a:    25 0d           xtrct    r0,r5
      2c:    d6 7b           mov.l    21c <IMM_ComRdPtr>,r6    ! 260ffc44
      2e:    c6 12           mov.l    @(72,gbr),r0
      30:    63 62           mov.l    @r6,r3
      32:    67 03           mov    r0,r7
      34:    30 30           cmp/eq    r3,r0
      36:    8f 3a           bf.s    ae <ptpl_01>
      38:    c6 07           mov.l    @(28,gbr),r0
      3a:    17 11           mov.l    r1,@(4,r7)
      3c:    17 23           mov.l    r2,@(12,r7)
      3e:    66 03           mov    r0,r6
      40:    c6 09           mov.l    @(36,gbr),r0
      42:    41 08           shll2    r1
      44:    41 08           shll2    r1
      46:    30 1c           add    r1,r0
      48:    c2 09           mov.l    r0,@(36,gbr)
      4a:    e0 fc           mov    #-4,r0
      4c:    24 09           and    r0,r4
      4e:    51 40           mov.l    @(0,r4),r1
      50:    52 42           mov.l    @(8,r4),r2
      52:    53 44           mov.l    @(16,r4),r3
      54:    21 09           and    r0,r1
      56:    22 09           and    r0,r2
      58:    e0 fe           mov    #-2,r0
      5a:    23 09           and    r0,r3
      5c:    17 12           mov.l    r1,@(8,r7)
      5e:    17 24           mov.l    r2,@(16,r7)
      60:    17 35           mov.l    r3,@(20,r7)
      62:    e1 14           mov    #20,r1
      64:    17 10           mov.l    r1,@(0,r7)
      66:    60 53           mov    r5,r0
      68:    c2 1d           mov.l    r0,@(116,gbr)
      6a:    77 18           add    #24,r7
      6c:    50 60           mov.l    @(0,r6),r0
      6e:    51 61           mov.l    @(4,r6),r1
      70:    52 62           mov.l    @(8,r6),r2
      72:    53 63           mov.l    @(12,r6),r3
      74:    17 00           mov.l    r0,@(0,r7)
      76:    17 11           mov.l    r1,@(4,r7)
      78:    17 22           mov.l    r2,@(8,r7)
      7a:    17 33           mov.l    r3,@(12,r7)
      7c:    50 64           mov.l    @(16,r6),r0
      7e:    51 65           mov.l    @(20,r6),r1
      80:    52 66           mov.l    @(24,r6),r2
      82:    53 67           mov.l    @(28,r6),r3
      84:    17 04           mov.l    r0,@(16,r7)
      86:    17 15           mov.l    r1,@(20,r7)
      88:    17 26           mov.l    r2,@(24,r7)
      8a:    17 37           mov.l    r3,@(28,r7)
      8c:    50 68           mov.l    @(32,r6),r0
      8e:    51 69           mov.l    @(36,r6),r1
      90:    52 6a           mov.l    @(40,r6),r2
      92:    53 6b           mov.l    @(44,r6),r3
      94:    17 08           mov.l    r0,@(32,r7)
      96:    17 19           mov.l    r1,@(36,r7)
      98:    17 2a           mov.l    r2,@(40,r7)
      9a:    17 3b           mov.l    r3,@(44,r7)
      9c:    e0 30           mov    #48,r0
      9e:    30 7c           add    r7,r0
      a0:    d1 5f           mov.l    220 <IMM_FRT_INTR>,r1    ! 21000000
      a2:    c2 12           mov.l    r0,@(72,gbr)
      a4:    21 01           mov.w    r0,@r1
      a6:    00 0b           rts  
      a8:    e0 01           mov    #1,r0


[...]
And so on...
 

Attachments

  • 20181207_172125.jpg
    20181207_172125.jpg
    5.6 MB · Views: 372
  • 20181207_172134.jpg
    20181207_172134.jpg
    4.8 MB · Views: 380
  • sglC08.txt
    88.8 KB · Views: 200
(very) Slowly getting everything together.
On a side note, gouraud shading on the Saturn simply looks amazing, even with OpenGL's default gouraud shading settings you can't replicate such amazing lighting.
I ditched the color bank sprites for RGB sprites only to allow better lighting.
I think it's worth it as long as I can keep up the draw distance.
While I still have a ton of things to do on the engine, hopefully next year I'll be able to add dynamic lighting.

Here are some shots in SSF.
 

Attachments

  • Shading test.png
    Shading test.png
    231.4 KB · Views: 394
  • Shading test 2.png
    Shading test 2.png
    247.6 KB · Views: 344
  • Shading test 3.png
    Shading test 3.png
    166.5 KB · Views: 338
Seriously XL2.

You are amazing. Little by little, you are getting very far away! Congratulations!! Again XD

With respect to penalize drawing distance. You know what will happen, it is expensive to calculate. But you also know, that you have room to optimize. Just like you can apply a LOD by distance, for vertices and textures. You can scale the lighting detail by distances. From Gouraud with four vertices to a flat face. That affects several local lights to only one or only pre-calculated light. Finally for geometry in the far-clipping directly without shading, since with so few pixels hardly notice the effect. Adding up everything, you can compensate to have that magnificent light closer to the camera.

We already know, that all this will depend on your implementation of BSP or similar that you finally do. And that is a lot of work. Even, really, I do not know where SGL (closed) will let you do all this, to be able to optimize even more. It is clear that your creativity has no limit! Cheer up!

For anything you know that you can count, humbly, with my help.

Regards! :)

PD: It is difficult see in the screenshots. Is possible the Local Light are sum to main Paralell Light source in Sonic model?
 
Seriously XL2.

You are amazing. Little by little, you are getting very far away! Congratulations!! Again XD

With respect to penalize drawing distance. You know what will happen, it is expensive to calculate. But you also know, that you have room to optimize. Just like you can apply a LOD by distance, for vertices and textures. You can scale the lighting detail by distances. From Gouraud with four vertices to a flat face. That affects several local lights to only one or only pre-calculated light. Finally for geometry in the far-clipping directly without shading, since with so few pixels hardly notice the effect. Adding up everything, you can compensate to have that magnificent light closer to the camera.

We already know, that all this will depend on your implementation of BSP or similar that you finally do. And that is a lot of work. Even, really, I do not know where SGL (closed) will let you do all this, to be able to optimize even more. It is clear that your creativity has no limit! Cheer up!

For anything you know that you can count, humbly, with my help.

Regards! :)

PD: It is difficult see in the screenshots. Is possible the Local Light are sum to main Paralell Light source in Sonic model?
About possible slowdowns, I meant mainly with the gouraud shading adding something like 20 or 25% rendering time, which is quite a lot.
About the CPU, it can always be optimized, so I'm not too worried.
I will try to use the current octree implementation and add a PVS to it.
It should work as I can already build the BSP tree on the computer (I use it for lighting), so I just need to raycast to find visible nodes/leaves.
But that raycasting will be slow, so I might need to speed it up.
It won't eliminate overdraw, but it should reduce it quite a bit, even if it's useless to solve the problem with VDP2 transparent sprites.
That octree/pvs system won't be as efficient as a BSP/portal system obviously, but it's simplier for now to reuse what I have and it will work with Z-Treme's maps, so I can quickly test.
About the light on Sonic, it's just a "demo" light that turns around, I haven't implemented local lights on the Saturn side (only while converting on PC).
For the dynamic lighting, I will probably just use it on the high quality model, not on the low quality model. I want to try something like that :


But that's something that won't happen for a long time as I have many more important things to do on this project.

EDIT : I did a quick test on real hardware (gouraud shading on everything + BR-style transparency) and the game still ran at 20-30 fps. There is room for improvements, hopefully I can reach a stable 30 fps will all these effects.
 
Last edited:
Impressive work!! Hey , you are working in framebuffer effects right? Its hard do a similar effect like Tomb Raider save state from ps1? 1:25:50 This effect copy the framebuffer to a polygon and put a purple pallete.
 
Impressive work!! Hey , you are working in framebuffer effects right? Its hard do a similar effect like Tomb Raider save state from ps1? 1:25:50 This effect copy the framebuffer to a polygon and put a purple pallete.

Yes and no. The problem is the lack of texture coordinates, which limits what you could do.
 
Sonic R not make exactly the same. The texture reflection is static.
In other hand. Tomb Raider in PS1 not use a UV refraction mapping, only a planar proyection of the previous frame buffer how texture plus inked and light whit gouraud source light.
All this is possible in SS, in fact actually the SS version had the inked Gouraud sourced part. The miss part is the frame buffer texture, possible like XL2 made it. And last the UV planar protection, RockinB made it a long time.
All is possible in SS, tricky but possible.
 
Last edited:
News in your engine? Can i download the last build? I really like this project :D Burning Rangers transparency is really cool!
Do you test multiplicative lighting to see if run better than additive?
 
News in your engine? Can i download the last build? I really like this project :D Burning Rangers transparency is really cool!
Do you test multiplicative lighting to see if run better than additive?
Nothing new, I didn't have much time recently, but I put back collision detection and removed the framebuffer clearing to gain a bit more rendering speed.
I'm not sure I'll keep the BR style transparency because of limited ram and vram, and it's also slower.
About multiplicative lighting, it's one option right now for smoother shading, I know it can probably be done using lookup tables, but normal additive lighting isn't bad either.
The problem is that it would kill vdp1 half transparency, which was my backup plan instead of BR-style transparency (by using lines to rasterize polygons).
 
  • Like
Reactions: vbt
Still no name nor any gameplay to show, but here is some footage from last month's version.
The textures aren't very good and they are too dark and I didn't put enough lights so it's hard to see.
I didn't have much time recently so I haven't made much progress, but I am currently working on a Quake .map converter, which should allow me to make maps faster and help with moving entities/switches/doors.
Anyway, it runs at 30 fps, but I still have visual glitches that I will try to fix once I am done with the converter.
 
I see this video! Really impressive!!! The texture mapping is really nice in this demo! And running at solid 30fps show the power of your engine. This small glitches is not really a big problem the demo is really nice!! I love one day get your code and study hard this game and the awesome Sonic Z. Using bsp tree speed up the Sonic Z game? Not clearing the framebuffer cause visual glitches?
 
I see this video! Really impressive!!! The texture mapping is really nice in this demo! And running at solid 30fps show the power of your engine. This small glitches is not really a big problem the demo is really nice!! I love one day get your code and study hard this game and the awesome Sonic Z. Using bsp tree speed up the Sonic Z game? Not clearing the framebuffer cause visual glitches?
Not clearing the framebuffer doesn't cause glitches if you always overwrite all the pixels, which is what I do.
The glitches must be related to dma or cache, I will work on that later.
As for Sonic Z-Treme, the maps wouldn't work with a bsp tree and I don't see how I could ever make it work, so this project is on hold, most likely cancelled.
The bsp helps mainly for visibility calculation (pvs, portals), which is very nice for indoor maps, but not so much for outdoor maps.
 
All times i turn on my saturn i NEED play Sonic Z many times! Its a dream play a sonic3d into saturn hardware. "this project is on hold, most likely cancelled" :( man not give up your project is really nice. I understand its hard create big levels because of saturn ram size, Sonic Xtreme team in past not have saturn in mind when create the xtreme. If you put Sonic Z as a Scroll Plane game will be much better to extract power of the saturn. A similar game can be done with saturn using 2 scroll planes one for water and other for the level and can use your nice sonic 3d model.
 
Last edited:
Here is a demo for lighting using lightmaps and alpha blending on the VDP2. It's still the same framebuffer trick I mentionned before. The edges are sadly a bit too rough, so they don't fully cover the cube, but if it was an interior map with the screen filled with polygons it would be OK.
 

Attachments

  • sl_coff.zip
    52.8 KB · Views: 311
  • 00000022.png
    00000022.png
    31 KB · Views: 384
  • 00000023.png
    00000023.png
    28.8 KB · Views: 374
Impressive work again! This texture mapping is software? Your engine is really nice and get better and better all days. Nice Work man!
 
Back
Top