saturn/SRB2Kart-Saturn
2
0 Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases 23 Wiki Activity

Blending modes (and a few refactors) #158

Merged
Chearii merged 6 commits from blendmodes into Saturn 2025-03-05 10:12:55 +01:00
Conversation 11 Commits 6 Files Changed 34
+1038 -312
Chearii commented 2025-02-03 11:21:34 +01:00 (Migrated from github.com)
Copy link
Copy source

This brings over the blending mode system from SRB2 2.2, along with overhauling elements of the software renderer.
Many of these additions and changes are from toaster and sphere's Blentran pull request for base 2.2, which since has been merged in since 2.2.10.

  • EDIT: Some of these screenshots are from earlier versions of this, where the shadow object was left opaque due to lacking the AST_TRANSLUCENT blendmode. This has since been fixed:
  • kart0053

kart0044
kart0044
kart0040
kart0046

General changes

  • The software renderer now has unique color look up tables, mainly used to find blendmode colors.
  • Related to the above: Gif recording now uses this new LUT system out of necessity.
  • OpenGL rendering has been slightly overhauled, now having support for blending modes.

HUD changes

  • V_DrawStretchyFixedPatch (and its hardware equvalent) can now render with blendmode flags.
    • The blendmode flags, marked with a B_ prefix, are B_ADD, B_SUBTRACT, B_REVERSESUBTRACT, and B_MODULATE
    • Unlike 2.2, blendmode flags are separated into their own field to prevent removing preexisting vflags. To call these in Lua, add the blendmode flags after the colormap field.
    • Currently, only the Lua HUD functions v.draw, v.drawScaled, and v.drawStretched support blendmodes.

Mobj changes

  • Objects now all have a blendmode variable. As with every Saturn-exclusive variable, this is not netsynched!
  • Frame flags have been slightly overhauled, with the inclusion of FF_SEMIBRIGHT, FF_FULLDARK, and blendmode-related frame flags. The blending frame flags allow you to assign blending modes for certain objects easily.
    • The blending frame flags are: FF_ADD, FF_SUBTRACT, FF_REVERSESUBTRACT, and FF_MODULATE. Like in base 2.2, they can be combined with the translucency flags.

Linedefs and FOFs

  • Linedefs have an overhaul, now using a proper alpha value instead of relying on a relay of its special to accomplish the same result.
  • Linedefs and FOFs now use blendmodes.
    • The corresponding linedef specials are identical to base SRB2 2.2.10's.
    • FOF blendmodes can be set by adding a 4th digit to any translucent FOF's translucency value (1 = Additive, 2 = Subtractive, 3 = Reverse-subtractive, 4 = Modulative).

Known issue

  • In software, certain color combinations can cause the LUTs to bug out and render as pure white pixels. I'm unaware of any fix to this issue.
  • This is immediately noticeable by using Additive rendering on a player with the Caribbean color, or using any blendmode in Masters Pack's Autumn Ring.
  • This issue is not present in OpenGL, even with paletted rendering (software on left, OpenGL paletted on right).

softwareblendbug nobugsingl

Test files:

The .zip contains both a test map for additive linedefs and FOFs, and a Lua file for testing blendmodes at different transparencies,
saturn_blendmodetestfiles.zip

All of this was tested on a 64-bit Windows build, compiled with MSYS2. Tested on Software and on OpenGL with various options (models on/off, shaders on/off, palette rendering on/off). A simple test for communication with vanilla clients (loading the test map and hosting a local server) was performed, with no issues.

All changes made here used the Saturn branch (and not Saturn-Next) as a base.

This brings over the blending mode system from SRB2 2.2, along with overhauling elements of the software renderer. Many of these additions and changes are from toaster and sphere's [Blentran pull request](https://git.do.srb2.org/STJr/SRB2/-/merge_requests/1656) for base 2.2, which since has been merged in since 2.2.10. * EDIT: Some of these screenshots are from earlier versions of this, where the shadow object was left opaque due to lacking the ``AST_TRANSLUCENT`` blendmode. This has since been fixed: * ![kart0053](https://github.com/user-attachments/assets/4aea92b4-9cd8-4663-9758-c353fedf3490) ![kart0044](https://github.com/user-attachments/assets/a68a44f8-27fa-415f-bbaf-4e43bc8e366e) ![kart0044](https://github.com/user-attachments/assets/98357216-fa2e-4144-8db3-9d0c230e74f7) ![kart0040](https://github.com/user-attachments/assets/b30b1019-72dd-48df-9dd9-a953aa695166) ![kart0046](https://github.com/user-attachments/assets/c5aa8b79-1efc-411b-9a62-b653c574a35f) ## General changes * The software renderer now has unique color look up tables, mainly used to find blendmode colors. * Related to the above: Gif recording now uses this new LUT system out of necessity. * OpenGL rendering has been slightly overhauled, now having support for blending modes. ## HUD changes * ``V_DrawStretchyFixedPatch`` (and its hardware equvalent) can now render with blendmode flags. * The blendmode flags, marked with a ``B_`` prefix, are ``B_ADD``, ``B_SUBTRACT``, ``B_REVERSESUBTRACT``, and ``B_MODULATE`` * Unlike 2.2, blendmode flags are **separated into their own field** to prevent removing preexisting vflags. To call these in Lua, add the blendmode flags after the colormap field. * Currently, only the Lua HUD functions ``v.draw``, ``v.drawScaled``, and ``v.drawStretched`` support blendmodes. ## Mobj changes * Objects now all have a ``blendmode`` variable. As with every Saturn-exclusive variable, *this is* ***not netsynched!*** * Frame flags have been slightly overhauled, with the inclusion of ``FF_SEMIBRIGHT``, ``FF_FULLDARK``, and blendmode-related frame flags. The blending frame flags allow you to assign blending modes for certain objects easily. * The blending frame flags are: ``FF_ADD``, ``FF_SUBTRACT``, ``FF_REVERSESUBTRACT``, and ``FF_MODULATE``. Like in base 2.2, they can be combined with the translucency flags. ## Linedefs and FOFs * Linedefs have an overhaul, now using a proper alpha value instead of relying on a relay of its special to accomplish the same result. * Linedefs and FOFs now use blendmodes. * The corresponding linedef specials are [identical to base SRB2 2.2.10's](https://wiki.srb2.org/w/index.php?title=Translucent_wall&oldid=115610). * FOF blendmodes can be set by adding a 4th digit to any translucent FOF's translucency value (1 = Additive, 2 = Subtractive, 3 = Reverse-subtractive, 4 = Modulative). ## Known issue * In software, certain color combinations can cause the LUTs to bug out and render as pure white pixels. I'm unaware of any fix to this issue. * This is immediately noticeable by using Additive rendering on a player with the Caribbean color, or using any blendmode in Masters Pack's Autumn Ring. * This issue is not present in OpenGL, even with paletted rendering (software on left, OpenGL paletted on right). ![softwareblendbug](https://github.com/user-attachments/assets/bd2fd05e-5c4c-4961-aa5f-e331231c4b33) ![nobugsingl](https://github.com/user-attachments/assets/9ba85f49-30d1-4c28-aa31-9d34d10ef90a) ## Test files: The .zip contains both a test map for additive linedefs and FOFs, and a Lua file for testing blendmodes at different transparencies, [saturn_blendmodetestfiles.zip](https://github.com/user-attachments/files/18640704/saturn_blendmodetestfiles.zip) All of this was tested on a 64-bit Windows build, compiled with MSYS2. Tested on Software and on OpenGL with various options (models on/off, shaders on/off, palette rendering on/off). A simple test for communication with vanilla clients (loading the test map and hosting a local server) was performed, with no issues. **All changes made here used the Saturn branch (and not Saturn-Next) as a base.**
Indev450 (Migrated from github.com) reviewed 2025-02-03 11:21:34 +01:00
alufolie91 commented 2025-02-03 19:25:44 +01:00 (Migrated from github.com)
Copy link
Copy source

ok this is frickin awesome, been wanting to have these since ages
thanks alot for this! c:
looking forward testing this

ok this is frickin awesome, been wanting to have these since ages thanks alot for this! c: looking forward testing this
🎉 1
Indev450 (Migrated from github.com) approved these changes 2025-02-03 22:12:37 +01:00
Indev450 (Migrated from github.com) left a comment
Copy link
Copy source

All looks good :3
Tried to see why white pixel bug happens but no idea either, but besides that from testing had no other issues

All looks good :3 Tried to see why white pixel bug happens but no idea either, but besides that from testing had no other issues
Indev450 (Migrated from github.com) reviewed 2025-02-04 18:04:10 +01:00
src/r_draw.c
@@ -234,6 +235,189 @@ void R_InitTranslationTables(void)
W_ReadLump(W_GetNumForName("TRANS70"), transtables+0x60000);
Indev450 (Migrated from github.com) commented 2025-02-04 18:04:10 +01:00
Copy link
Copy source

Figured white pixel bug out!
Here, and in all other similar loops, condition should be either <= 0xFF of < 0x100, because otherwise it misses 1 last palette index every time (because 0xFF is 255, so it ignores it even though it is valid index)

Figured white pixel bug out! Here, and in all other similar loops, condition should be either `<= 0xFF` of `< 0x100`, because otherwise it misses 1 last palette index every time (because 0xFF is 255, so it ignores it even though it is valid index)
Chearii (Migrated from github.com) reviewed 2025-02-04 22:33:11 +01:00
src/r_draw.c
@@ -234,6 +235,189 @@ void R_InitTranslationTables(void)
W_ReadLump(W_GetNumForName("TRANS70"), transtables+0x60000);
Chearii (Migrated from github.com) commented 2025-02-04 22:33:11 +01:00
Copy link
Copy source

wow, how didn't I catch that? ^^;
def seemed to do the trick, I'm not encountering the white pixel bug anymore
kart0056

wow, how didn't I catch that? ^^; def seemed to do the trick, I'm not encountering the white pixel bug anymore ![kart0056](https://github.com/user-attachments/assets/6ba36ea0-4046-40c9-b06d-a61c670098a7)
alufolie91 commented 2025-02-09 16:21:27 +01:00 (Migrated from github.com)
Copy link
Copy source

Been testing this for a while now, everything so far seem to work well! c:
Took the liberty to merge this into the Testing branch aswell as adding blendmodes to a few effects, so this can be tested more thorougly

Been testing this for a while now, everything so far seem to work well! c: Took the liberty to merge this into the Testing branch aswell as adding blendmodes to a few effects, so this can be tested more thorougly
❤️ 1 🎉 1
alufolie91 (Migrated from github.com) requested changes 2025-03-04 21:32:28 +01:00
src/hardware/hw_draw.c
@@ -286,7 +287,11 @@ void HWR_DrawStretchyFixedPatch(GLPatch_t *gpatch, fixed_t x, fixed_t y, fixed_t
v[0].t = v[1].t = 0.0f;
alufolie91 (Migrated from github.com) commented 2025-03-04 21:32:11 +01:00
Copy link
Copy source

ok for whatever reason github refused to show my comment here so let me requote it lel

Noticed this while compiling with clang, the flag assingment should be moved back to before the "V_WRAP" handling, otherwise those options get overwritten (and doing any operation on an unitialized value may lead to undefined behaviour)

ok for whatever reason github refused to show my comment here so let me requote it lel > Noticed this while compiling with clang, the flag assingment should be moved back to before the "V_WRAP" handling, otherwise those options get overwritten (and doing any operation on an unitialized value may lead to undefined behaviour)
alufolie91 commented 2025-03-04 23:31:14 +01:00 (Migrated from github.com)
Copy link
Copy source

Ok, after some further testing i did notice an unusual performance regression on a few maps (mostly wandering falls) in opengl, after a bit of investigation i pinned it down to those https://github.com/Indev450/SRB2Kart-Saturn/commit/1e79d464b019817b8ec5805a6683247856fe96cd (HWR_SplitWall not using the blendmode flag was actually something i messed up a while ago oops)
would appreciate if this could be implemented into the pr c:

Ok, after some further testing i did notice an unusual performance regression on a few maps (mostly wandering falls) in opengl, after a bit of investigation i pinned it down to those https://github.com/Indev450/SRB2Kart-Saturn/commit/1e79d464b019817b8ec5805a6683247856fe96cd (HWR_SplitWall not using the blendmode flag was actually something i messed up a while ago oops) would appreciate if this could be implemented into the pr c:
Chearii (Migrated from github.com) reviewed 2025-03-05 01:47:35 +01:00
src/hardware/hw_draw.c
@@ -286,7 +287,11 @@ void HWR_DrawStretchyFixedPatch(GLPatch_t *gpatch, fixed_t x, fixed_t y, fixed_t
v[0].t = v[1].t = 0.0f;
Chearii (Migrated from github.com) commented 2025-03-05 01:47:35 +01:00
Copy link
Copy source

ah, good catch
hopefully these last few commits fix this and the performance issues mentioned

ah, good catch hopefully these last few commits fix this and the performance issues mentioned
alufolie91 (Migrated from github.com) reviewed 2025-03-05 08:00:47 +01:00
src/hardware/hw_draw.c
@@ -286,7 +287,11 @@ void HWR_DrawStretchyFixedPatch(GLPatch_t *gpatch, fixed_t x, fixed_t y, fixed_t
v[0].t = v[1].t = 0.0f;
alufolie91 (Migrated from github.com) commented 2025-03-05 08:00:47 +01:00
Copy link
Copy source

yeah everything looks good to me now c:
sorry again this took so long, the above comment sat here for 2 weeks until i noticed it wasnt even visible lol

yeah everything looks good to me now c: sorry again this took so long, the above comment sat here for 2 weeks until i noticed it wasnt even visible lol
alufolie91 commented 2025-03-05 08:02:26 +01:00 (Migrated from github.com)
Copy link
Copy source

For me this is good to merge now
Big thanks again for this c:
and sorry for the delay lul

For me this is good to merge now Big thanks again for this c: and sorry for the delay lul
🎉 1
Sign in to join this conversation.
Reviewers
No Reviewers
Indev450
Chearii
alufolie91
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
alufolie91 indev
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: saturn/SRB2Kart-Saturn#158