Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a different Shader get-method in Blitter.blit() #6923

Closed

Conversation

Lordfirespeed
Copy link

Closes #6726

I'm not 100% on what effect this has, however in Vanilla, getPositionTexShader returns a ShaderInstance created using the same resource location as getPositionTexColorShader, the only difference is the "vertex configuration".

With the change implemented:
image

Clearly the widgets aren't perfect but that could be solved using a resourcepack etc.

Closes AppliedEnergistics#6726 

I'm not 100% on what effect this has, however in Vanilla, `getPositionTexShader` returns a `ShaderInstance` created using the same resource location as `getPositionTexColorShader`, the only difference is the "vertex configuration".
@Lordfirespeed Lordfirespeed changed the title Use getPositionTexShader over getPositionTexColorShader Use a different Shader get-method in Blitter.blit() Feb 6, 2023
@62832
Copy link
Member

62832 commented Feb 6, 2023

That "resource pack" simply requires you to runData in your dev environment prior to starting the client.

@Lordfirespeed
Copy link
Author

Lordfirespeed commented Feb 6, 2023

That "resource pack" simply requires you to runData in your dev environment prior to starting the client.

Oh, that's how you populate that stuff! Thankyou so much!

We're talking about different things, though - I meant the GUI widgets - the icons for sort order / direction are quite hard to see in the darker settings.

@62832
Copy link
Member

62832 commented Feb 6, 2023

Ah, right. Yes, I imagine those could do with a bit of tweaking.

@Technici4n
Copy link
Member

Interesting! This seems to have some side-effects, however it gives me hints for an approach to fix this. Thank you! I will look further into this once Dark Mode Everywhere is available for 1.19.4.

@Lordfirespeed
Copy link
Author

Interesting! This seems to have some side-effects, however it gives me hints for an approach to fix this. Thank you! I will look further into this once Dark Mode Everywhere is available for 1.19.4.

No problem! Glad to be helpful :)

@Lordfirespeed
Copy link
Author

@Technici4n

Interesting! This seems to have some side-effects, however it gives me hints for an approach to fix this. Thank you! I will look further into this once Dark Mode Everywhere is available for 1.19.4.

Dark Mode Everywhere has now released for 1.19.4; here's the CurseMaven dependency (Forge):

runtimeOnly fg.deobf("curse.maven:darkmodeeverywhere-574123:4524796")

@shartte
Copy link
Member

shartte commented May 30, 2023

Just changing the shader but not the vertex format and not actually making sure that r,g,b,a is applied in some other way -> no bueno.

@shartte shartte closed this May 30, 2023
@Lordfirespeed
Copy link
Author

Lordfirespeed commented May 30, 2023

Hey @shartte, I understand that the pull request cannot be merged (so it is totally reasonable to close it) but I would really appreciate it if you could help me get in touch with @Technici4n to look into making this work.

Do you have any ideas for how the vertex format should be changed so as to not cause problems?
I'm also not entirely sure what you mean by 'applying r,g,b,a'.
Sorry to be a pain, I'd just really like this to work.

@Technici4n
Copy link
Member

getPositionTexColorShader allows multiplying the color of each vertex by some RGBA value. Removing it risks making all sorts of things rendering without the proper coloration. However I was keeping this PR open to remember to have a look at this eventually, not to merge it as is. Possibly we just need to add a parameter to how we create some blitters. ;)

@shartte regarding what was mentioned on Discord, I think it would be nicer to integrate with dark mode everywhere than make our own dark mode config that everyone will have to adjust separately.

@Technici4n Technici4n reopened this May 31, 2023
@shartte
Copy link
Member

shartte commented May 31, 2023

Well I don't think the general case will necessarily work reliably. But if we have our own handling, integration could be as simple as forcing.the config if the dark mode mod is installed. Doing their shading reliably is harder. But we could go and port everything to generated backgrounds to make that easier

@Lordfirespeed
Copy link
Author

Lordfirespeed commented Jul 6, 2023

@Technici4n Any updates?
I'm about to start work on refactoring the DarkModeEverywhere shaders, so I should be able to implement a TexColorPosition shader once done with that - which I think might resolve this problem altogether, without anything from your end.

@Technici4n
Copy link
Member

No progress on our side as we're busy with other things, but I'm not forgetting this. If the problem fixes itself magically then it's even better. 😄

@Lordfirespeed
Copy link
Author

Upon (brief) testing, I think the changes I've proposed work out of the box with AE2 on 1.18.2! Can't say for sure yet regarding 1.19 and 1.20 but I see no reason it won't work the same way.

Took a bit of doing. But I discovered the 3 default shaders that DME was built on previously (Toasted Light, Less Perfect Dark, Perfect Dark) were actually three identical shaders with different parameters.

I parameterized those shaders into one dark_position_tex shader and added a new dark_position_tex_color shader. With all that done, I added a second mixin that changes the return value from getPositionTexColorShader (in addition to the original getPositionTexShader).

That last bit is the key point - because it's the method that AE2 has been using all along!

@Technici4n
Copy link
Member

As far as I understood this was fixed with some changes in DME.

@Technici4n Technici4n closed this Aug 15, 2023
@Lordfirespeed Lordfirespeed deleted the patch-1 branch August 15, 2023 16:19
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for Dark mode everywhere
4 participants