Closed gonetz closed 7 years ago
That sounds good to me.
@oddMLan The N64 is a special case. The primary reason to pick 1x is because you either don't want 2D games to look wrong (black lines, blending issues, etc) or you don't want your games to be bugged. (Quest 64) A lot of games require 1x exactly to render correctly.
The jump from 1x to 2x is fairly catastrophic in terms of 2D accuracy currently. This isn't like the PS1 where it just causes a few minor niggles.
@Aquatakat That seems needlessly complex. Gonetz's suggestion works perfectly.
Output resolution. Native resolution. Slider that goes from 2x native upwards.
If people want "internal = output" they select output. If they want games to stop breaking, they select Native. If they want to supersample or anything like that, they adjust the internal resolution slider. (People taking really high resolution screenshots love stuff like this.)
I see your point but not all the end users are familiar with N64's emulation quirkiness-es. Then again you, Gonetz and Aqua seem to prefer having 3 radio options so I guess I'll just roll with that ☺️
I guess in the end the 3 radio layout is also more clear for end users.
@Aquatakat Yes, slider should be enabled only when third option is selected. If slider will start from 2, it will not interfere with previous two options.
@oddMLan I thought to make just one slider with "output resolution" for 0, "Original ..." for 1, and nx for others. But radio buttons solution looks more clear.
@gonetz Is there a difference between 1x and 0x anti-aliasing?
0x is Off. 1x is presumably 2x MSAA or something like that. And I assume it goes 2/4/8/16x MSAA.
0 is Off. Any value above zero is used as parameter for multi sampling.
Cite glTexStorage2DMultisample description: "samples specifies the number of samples to be used for the texture and must be greater than zero and less than or equal to the value of GL_MAX_SAMPLES.@
Thus, 1 is valid value for samples. I guess that result will be as without AA though.
I did a little testing, (not a lot) and it seemed like 1x was the same as 0x. I was wondering if we could remove 0x and have 1x as the minimum.
No, we can't 0 means AA off
Alright.
Would it be possible to tweak the slider so it goes in multiples? 0/2/4/8/16? That's how most AA solutions work.
Also, yea, 1x minimum is no good. AA should also probably have an override when running at 1x native because it breaks stuff.
0x
1x
AFAIR, it is possible to set slider's step.
An exponential step (2, 4, 8, 16) may require a little work. I'm not sure it's necessary though: MegaMan 64 (MegaMan Legends) almost famously has black lines in 2D and 3D elements.
An exponential step (2, 4, 8, 16) may require a little work. I'm not sure it's necessary though
If you want your AA solution to work traditionally it will. The current maximum is 4x MSAA. Of course that's more than enough for N64 games, though. 1x MSAA should be removed at the very least. I don't think MSAA can work properly with only one sample.
MegaMan 64 (MegaMan Legends) almost famously has black lines in 2D and 3D elements.
It's far more prone to it than other games. But raising the AA beyond 2x immediately causes black lines in games like Army Men: Air Combat.
The current maximum is 4x MSAA.
Actually 8x
1x MSAA should be removed at the very least. I don't think MSAA can work properly with only one sample.
It can. 1x MSAA == no MSAA. no MSAA works properly.
But I agree, better to use exponential step (2, 4, 8, 16) Slider step is already set to 2, but you can set odd value with mouse.
It can. 1x MSAA == no MSAA. no MSAA works properly.
When you set slider to 1x, it breaks Mega Man. So what is going on there?
Interesting. I don't know. Do you see any AA effect with 1x?
Just with a quick check 1x doesn't seem to affect the Star Fox 64 intro in any way.
Well, I don't know what is going on with 1x MSAA. 1 is correct number of samples for msaa texture, as well as 3 or 5. I guess, result for such 'odd' sampled textures is hardware dependent.
It seems like disabling 1x and treating it as either 0x or 2x might be a good option.
Good option is to allow only power of two values for MSAA.
I suggest to leave it as is for the moment, since all values from this sliders are correct for OpenGL.
@gonetz I checked a few games and couldn't find a difference. @AmbientMalice should probably prepare a new issue with games that are affected and their video card.
@AmbientMalice Mega Man 64 works for me (ATI card) btw.
Current WIP build: https://drive.google.com/file/d/0B0YqMPjGo3B2ZnB3NWdsQWtHbE0/view?usp=sharing
Suggestions and feedback are welcome.
Aspect ratio: Adjust option needs a hint that it activates "widescreen hack"
Maybe just renaming the label: "Try to adjust game to fit"?
"Try" implies the plugin is making an effort to do a thing that may not be possible.
"Enable hardware lighting" - better rename to "Enable Phong shading", to reflect its true nature. Phong shading explanation easily googled.
Maybe just renaming the label: "Try to adjust game to fit"?
Ok
"Enable hardware lighting" - better rename to "Enable Phong shading", to reflect its true nature. Phong shading explanation easily googled.
I can't recall - is this feature to make it more N64-accurate or is it just to make everything look better?
In the first case the label should probably be "Enable N64-style shading," but otherwise "Enable Phong shading" would be more correct.
N64 uses Gouraud shading. Phong shading produces better result, but it requires much more computations.
I believe the more common term is "per pixel lighting". As opposed to per vertex lighting, which the N64, and all other consoles in the 5th and 6th generation used.
I see one issue: OSD tab, top left arrow is somehow highlighted, even if other position is selected. When you press any arrow button, that highlight disappears.
"per pixel lighting" is Phong shading
Per pixel lighting may be a more user-friendly term. We could put Phong shading into the tooltip.
Ok
I'm not sure what causes the UI to pre-highlight the top-left button. I'll see if I can figure it out.
"Phong shading" sounds more scientific and imposing
There's two options here:
Enable per-pixel lighting
People try the option and like it
Enable Phong shading
Or people avoid the option because the checkbox is too complicated.
If we want the first, "Enable per-pixel lighting" is a better choice For the second, "Enable Phong shading" is a better choice
It is matter of taste, as any option, which changes original look of the game.
I agree with per pixel lighting.
It's good that that's the option I made a pull request for then :)
Current state. Everything is done. Only some minor issue left. https://drive.google.com/file/d/0B0YqMPjGo3B2SnR2WXlwaktobzg/view?usp=sharing
@gonetz There's a small bug with refresh rates. There are duplicates:
I think this is caused by multiple monitors.
I know about it, but don't have time to fix it.
@gonetz When are you planning on releasing an official updated version? (1.3, I assume.) Because I should probably draw up a list of 2D games that benefit from forced native and make a PR.
Current WIP. Some logic fixed: https://drive.google.com/file/d/0B0YqMPjGo3B2RXNLODZCUGJMejQ/view?usp=sharing
@AmbientMalice I hope to finish with current fixes and regressions before the new year. New GUI need to be translated. It can be done after release, but better to have at least some translations to release date. Custom ini cleanup and fixes. Etc etc. New year is optimistic date.
Current WIP. Some logic fixed: https://drive.google.com/file/d/0B0YqMPjGo3B2RXNLODZCUGJMejQ/view?usp=sharing
I confirm that the performance regression I saw before is no longer present in this build. I guess you compiled the debug build by mistake 😛 Now that I realize, when using that build I triggered an assertion error when playing Mario Tennis and enabling Copy Aux buffers to RDRAM. It's been too many times I can't count in which I start compiling the debug build only to cancel and set it to Release.
Heyy, the GUI is looking pretty damn awesome & professional. I like the wording changes made as well.
Aquatakat designed new nice GUI layout. Code is in https://github.com/gonetz/GLideN64/tree/feature_new_gui feature branch.
WIP build: https://drive.google.com/file/d/0B0YqMPjGo3B2TGpsenpZeTVsWUU/view?usp=sharing
We need your feedback.