Gliden64: Feature: new GUI

[gonetz]

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.

[LuigiBlood]

I actually like this GUI better overall. I do have one issue (not that I'll ever use it though):

I saw there was supposed to be arrows on the buttons?

[oddMLan]

Looks good but I still think the Frame buffer copy/depth sections should use comboboxes so less text is occupying the interface in the Frame buffer tab. That would also allow us to get rid of the white space at the bottom of the window in other tabs providing a small, compact and functional UI, while making it look less cluttered with text.

Seriously though this seems like the perfect window size.

[Aquatakat]

@oddMLan @gonetz

About the comboboxes vs. the radio buttons I like both layouts. The reason I changed it back to radio buttons was at gonetz' suggestion. Maybe we just need a little more input on it.

@LuigiBlood

It looks like you're using Windows 7? I'll have to find out which fonts preinstalled on Windows 7 include those arrows, or maybe just make some arrow graphics myself.

---

I'm getting ready to prepare another pull request with this added feature:

[LuigiBlood]

Yeah I'm a Windows 7 user.

[Aquatakat]

I used some skills I have with Paint.net to create some new arrows. They're a bit bold but they do the job.

[ghost]

Looks quite nice 👍

[gonetz]

There is a problem with custom icons.
I use static build of QT libs. GLideN64.dll contains all necessary resources, but icons not displayed. I don't know why. Green N in window caption is missing. Warning icon in fb emulation tab is missing also. The same will be for arrows.

[Aquatakat]

@gonetz Is it because I manually edited the .qrc file rather than using the Creator? I couldn't figure out where to add it so I manually edited the .qrc XML file.

[gonetz]

No, I have the same issue in master branch.

[Aquatakat]

@gonetz I wonder if it works with an Icon.ico rather than PNG.

http://aquatakat.flussence.eu:81/Icon.ico

[Mario54321]

Sorry. I posted in the wrong spot. See https://github.com/gonetz/GLideN64/issues/885#issuecomment-258751503

[Aquatakat]

@Mario54321 For clarity, here's the comment mentioned:

Instead of just saying "Aspect ratio" you can specifically put the type of aspect ratio it is (storage aspect ratio, display aspect ratio, pixel aspect ratio)

"Display aspect ratio" or "Output aspect ratio" might be a good option.

[gonetz]

I wonder if it works with an Icon.ico rather than PNG.

No, it does not.

I found these discussions:
https://forum.qt.io/topic/13034/solved-qt-static-missing-icon-plugin
https://forum.qt.io/topic/34969/static-link-q_import_plugin-qico-unresolved-external-symbol

First says, that qico plugin must be used.
Second says how to do it with Visual Studio.

Unfortunately, it does not help. I imported qico plugin, but icon still missing.

[Mario54321]

I think it might be better if "Texture cache size" is placed in the Texture enhancement tab instead of the Video tab

[Aquatakat]

@gonetz

Maybe adding add LIBS += to the .pro file?

[Aquatakat]

This is where I looked this up:
https://forum.qt.io/topic/13034/solved-qt-static-missing-icon-plugin/6

[Aquatakat]

@Mario54321

I thought the same originally, but that texture cache only affects textures that haven't been enhanced.

[gonetz]

Bingo!
Icon.ico works.
There is a problem: when QT plugin for MSVS creates .vcxproj project from .pro, it writes resources names into the project. I changed Icon.png to Icon.ico in icon.qrc, but autogenerated ui_configDialog.h still uses ":/Icon.png". I changed it to ":/Icon.ico" and finally got the main window's icon.

[Aquatakat]

I generated my PNGs from ffmpeg. There must be some kind of parsing problem with them. I'll give you .ico's for each instead.

[gonetz]

Ok.

[gonetz]

Current WIP:
https://drive.google.com/file/d/0B0YqMPjGo3B2RzFhelNmaVlyZzA/view?usp=sharing

[oddMLan]

Looks good, but again, the Framebuffer tab makes the entire window taller than it needs to be, creating tons of ugly whitepace on an UI that would look perfect if the window was shorter - could you make a prototype with comboboxes instead of radio options? These options don't have to be radio buttons if they barely need to be touched. With a proto people could decide on which layout is better.

Before

After

Before

After

After is much better IMO.

[gonetz]

'Frame buffer swap on' also should be replaced by combobox then. This option hardly should be changed on desktop.

[gonetz]

I think it might be better if "Texture cache size" is placed in the Texture enhancement tab instead of the Video tab

It is control for video memory cache. It is not related to cache for enhaced textures.

@Aquatakat looks like 'texture cache size' is confusing name for that option. It should be something like "video memory usage limit".

[gonetz]

New WIP build:
https://drive.google.com/file/d/0B0YqMPjGo3B2QVVzLWJzbTk4RlU/view?usp=sharing

[gonetz]

Alternative layout of frame buffer emulation page suggested by oddMLan:
https://drive.google.com/file/d/0B0YqMPjGo3B2bllFdV93OF85UnM/view?usp=sharing

[AmbientMalice]

So here are my suggestions rephrased from https://github.com/gonetz/GLideN64/issues/1216:

Add a "native N64 resolution" checkbox near the resolution slider. Its description should be something like "(more accurate)" The tooltip should explain that it fixes various issues such as Quest 64's text. When the checkbox is ticked, the resolution scaler should be greyed out.

This "native N64 resolution" setting should be something that can be set globally, or per-game in the ini file, and I'll draw up a list of 2D games where forcing native resolution would arguably be best in the near future.

[gonetz]

Add a "native N64 resolution" checkbox near the resolution slider.

It hardly will look nice with current design.

I suggest to put that checkbox into 'Emulation' page. It already has 'Render 2D elements in N64 resolution'. Add new checkbox 'Render everything in N64 resolution (accurate but low-res)' Made them mutually exclusive.

BTW, 'Render 2D elements in N64 resolution' is confusing. User may think, that 2D will be small and low-res. Actually, 2D first rendered in native resolution, then result rendered in user defined resolution. May be 'Multi-pass rendering of 2D elements'?

[AmbientMalice]

I suggest to put that checkbox into 'Emulation' page. It already has 'Render 2D elements in N64 resolution'. Add new checkbox 'Render everything in N64 resolution (accurate but low-res)' Made them mutually exclusive.

It's a bit muddled to have the "ratio of N64 resolution" slider and the "render at 1x native resolution" checkbox on different tabs. Especially if enabling the checkbox greys out the slider.

[Aquatakat]

Would it make sense to move the render at factor of N64 resolution slider to the emulation tab? Then it could live next to a "render at N64 resolution" checkbox and not be confusing when the slider is disabled.

BTW, 'Render 2D elements in N64 resolution' is confusing. User may think, that 2D will be small and low-res. Actually, 2D first rendered in native resolution, then result rendered in user defined resolution. May be 'Multi-pass rendering of 2D elements'?

I have a few ideas about this - I'll make something.

[AmbientMalice]

Would it make sense to move the render at factor of N64 resolution slider to the emulation tab?

Hmm... Maybe? Dolphin does separate internal and output resolution settings. Output is on the first tab, internal+AF+AA+per pixel lighting are on the second.

[gonetz]

Would it make sense to move the render at factor of N64 resolution slider to the emulation tab?

I don't see a contradiction here. Use of native resolution factor does not change output resolution.

[Aquatakat]

1227

[oddMLan]

To be honest since this alters the video resolution (or output), this would be more fitting under the "Video" tab.

Also I think the "Original N64 resolution" option is redundant with a slider there. You could just make the 1x option say "1x (Original N64 resolution)"

That is, if this is technically possible under QT

[AmbientMalice]

@oddMLan Well, Dolphin puts its internal resolution stuff on the second tab. I think this is a good compromise.

@Aquatakat I would suggest removing the 0x factor setting. So that when you select the Factor of N64 resolution setting, it starts at 1x.

What would the ini setting be to force native on a per-game basis?

[AmbientMalice]

I would change "Video resolution" to "Screen resolution".

Also, I would change "Render output" to "Internal resolution". I think internal resolution is a reasonably well known concept now that so many games separate their internal and output resolutions. (Doom, Call of Duty, Shadow Warrior, Serious Sam, etc.)

[oddMLan]

Internal resolution factor?

Yeah, it is a widely used term in emulators, true. But I still think N64 resolution factor sounds a bit more understandable for someone who isn't familiar with the term.

[AmbientMalice]

But I still think N64 resolution factor sounds a bit more understandable for someone who isn't familiar with the term.

No, I meant the section heading.

It says "Render output at:"

I would change that to "Internal Resolution:" Because you're changing the internal resolution. The output resolution is controlled by the resolution settings on the other tab.

I think "Factor of N64 resolution" is fine for that subsection.

[oddMLan]

Oh yes, then I would agree with you.
Also with that change the section suddenly sounds more fitting under "Emulation".

[oddMLan]

On a sidenote:

WIP build:
https://drive.google.com/file/d/0B0YqMPjGo3B2TGpsenpZeTVsWUU/view?usp=sharing

Alternative layout of frame buffer emulation page suggested by oddMLan:
https://drive.google.com/file/d/0B0YqMPjGo3B2bllFdV93OF85UnM/view?usp=sharing

Something must've regressed between the first and the second build. The performance I'm getting on the second build in Mario Tennis is atrocious (48 VI/s), while the first build works super fast (166 VI/s).
@gonetz Did you build debug on the second one by mistake?

[Aquatakat]

@oddMLan @gonetz

I noticed the performance problems also. I was originally getting 60 VI's in The New Tetris (with frame limiting) vs. about 30-40.

[gonetz]

I agree with @AmbientMalice:

Rename "Render output at:" to "Internal Resolution:".

It is really good explanation of that option.
The first option should be "Same as output resolution"
Second option is ok.
Slider for the third option should start from 2.

[oddMLan]

But what about this

Also I think the "Original N64 resolution" option is redundant with a slider there. You could just make the 1x option be more specific "1x (Original N64 resolution)"

Supress the second option, just leave the slider.

[gonetz]

@oddMLan First build is release one, others are non-optimized debug builds. These builds posted to test UI, not the plugin itself.

[gonetz]

What would the ini setting be to force native on a per-game basis?

[frameBufferEmulation]
nativeResFactor=1

[AmbientMalice]

@oddMLan That doesn't make it clear that literally every resolution that isn't 1x breaks things. If you want games to not be broken, you select the clearly marked "Original N64 resolution".

[gonetz]

Slider should start from 2, because 0 and 1 correspond to first two options.

[AmbientMalice]

Slider should start from 2, because 0 and 1 correspond to first two options.

So in other words...

nativeResFactor=0 Plugin selects "Same as output resolution."
nativeResFactor=1 Plugin selects "Native N64"
nativeResFactor=2+ Plugin selects appropriate setting on slider.

That makes sense. And the ini settings will be nice and clean this way.

[oddMLan]

This is less redundant overall IMO.

@AmbientMalice People usually pick 1x resolution for faithfulness, not necessarily accuracy. That is more accurate can be specified in a tooltip when you hover over the radio option.

[Aquatakat]

@gonetz We could have the radio buttons change the slider (and disable it) and the slider disable the incorrect radio buttons.

[oddMLan]

That sounds good to me.

[AmbientMalice]

@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.

[AmbientMalice]

@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.)

[oddMLan]

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.

[gonetz]

@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.

[gonetz]

@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.

[Aquatakat]

@gonetz Is there a difference between 1x and 0x anti-aliasing?

[AmbientMalice]

0x is Off. 1x is presumably 2x MSAA or something like that. And I assume it goes 2/4/8/16x MSAA.

[gonetz]

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.

[Aquatakat]

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.

[gonetz]

No, we can't
0 means AA off

[Aquatakat]

Alright.

[AmbientMalice]

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

[gonetz]

AFAIR, it is possible to set slider's step.

[Aquatakat]

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.

[AmbientMalice]

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.

[gonetz]

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.

[AmbientMalice]

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?

[gonetz]

Interesting. I don't know. Do you see any AA effect with 1x?

[Aquatakat]

Just with a quick check 1x doesn't seem to affect the Star Fox 64 intro in any way.

[gonetz]

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.

[Aquatakat]

It seems like disabling 1x and treating it as either 0x or 2x might be a good option.

[gonetz]

Good option is to allow only power of two values for MSAA.

[gonetz]

I suggest to leave it as is for the moment, since all values from this sliders are correct for OpenGL.

[Aquatakat]

@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.

[Aquatakat]

@AmbientMalice Mega Man 64 works for me (ATI card) btw.

[gonetz]

Current WIP build:
https://drive.google.com/file/d/0B0YqMPjGo3B2ZnB3NWdsQWtHbE0/view?usp=sharing

Suggestions and feedback are welcome.

[gonetz]

Aspect ratio: Adjust option needs a hint that it activates "widescreen hack"

[Aquatakat]

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.

[gonetz]

"Enable hardware lighting" - better rename to "Enable Phong shading", to reflect its true nature. Phong shading explanation easily googled.

[gonetz]

Maybe just renaming the label: "Try to adjust game to fit"?

Ok

[Aquatakat]

"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.

[gonetz]

N64 uses Gouraud shading. Phong shading produces better result, but it requires much more computations.

[AmbientMalice]

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.

[gonetz]

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.

[gonetz]

"per pixel lighting" is Phong shading

[Aquatakat]

Per pixel lighting may be a more user-friendly term. We could put Phong shading into the tooltip.

[gonetz]

Ok

[Aquatakat]

I'm not sure what causes the UI to pre-highlight the top-left button. I'll see if I can figure it out.

[gonetz]

"Phong shading" sounds more scientific and imposing

[Aquatakat]

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

[gonetz]

It is matter of taste, as any option, which changes original look of the game.

I agree with per pixel lighting.

[Aquatakat]

It's good that that's the option I made a pull request for then :)

[gonetz]

Current state. Everything is done. Only some minor issue left.
https://drive.google.com/file/d/0B0YqMPjGo3B2SnR2WXlwaktobzg/view?usp=sharing

[Aquatakat]

@gonetz There's a small bug with refresh rates. There are duplicates:

I think this is caused by multiple monitors.

[gonetz]

I know about it, but don't have time to fix it.

[AmbientMalice]

@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.

[gonetz]

Current WIP. Some logic fixed:
https://drive.google.com/file/d/0B0YqMPjGo3B2RXNLODZCUGJMejQ/view?usp=sharing

[gonetz]

@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.

[oddMLan]

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.

[gonetz]

I guess you compiled the debug build by mistake

No. Next WIP build can be debug too. Sometimes it is more convenient for me.

[gonetz]

Heyy, the GUI is looking pretty damn awesome & professional.

I like it too. However, if you see some issues or have a suggestion, it is not late to correct the design.

[ghost]

To be honest I've never seen af and aa options with odd numbers... only with even numbers at the power of 2:
off, 2, 4, 8, 16, 32 (though on my nvidia cards with a normal installation, they are capped at 8x aa and 16x af)

[oddMLan]

I don't really see a difference between 3x and 4x
same case with other non^2 numbers.
1x just breaks graphics with no AA whatsoever.

AA and Anisotropic should be power of 2 only. It's that way in all other emulator projects and software.
Also the slider splits at power of two numbers.

[Aquatakat]

The slider currently has ticks at every 2x. Maybe every 2x is the best separation. I also couldn't tell the difference between 3 and 4.

[gonetz]

AA and Anisotropic should be power of 2 only.

GL does not specify that.

[gonetz]

Current WIP (warning: debug build) . Some logic fixed:
https://drive.google.com/file/d/0B0YqMPjGo3B2RC1MQVlzTkxPT0E/view?usp=sharing

[AmbientMalice]

So phong shading/per pixel lighting is more faithful to real N64 behavior?

[gonetz]

I'm not sure, what faithful means in given context.
N64 games implements Gouraud shading. Most of other 3D games on all other platforms also use Gouraud shading. Phong shading used mostly by professional renders, like CADs.

[Aquatakat]

In this context faithful would mean most accurate. Maybe I should adjust the tooltip.

[gonetz]

Most accurate by which criteria? Closest to original view - no. Most realistic with given model and set of lights - yes.

[Aquatakat]

Based on @AmbientMalice 's original sentence: faithful -> most accurate

So phong shading/per pixel lighting is _most accurate_ to real N64 behavior?

[Aquatakat]

Or possibly "closest to real N64 behaviour."

[AmbientMalice]

"More accurate to the N64" strongly implies/flat out states that this mode more closely resembles a real N64's behavior.

It should probably just be worded as "Lighting will be smoother."

[gonetz]

So phong shading/per pixel lighting is most accurate to real N64 behavior?

No, because Phong shading gives different result. It should not be compared in that terms as "closest to real N64 behaviour." It is an improvement. As texture filtered with HQ filter is not closest to real N64 texture

[gonetz]

"More accurate to the N64" strongly implies/flat out states that this mode more closely resembles a real N64's behavior.

which is not true.

[gonetz]

"When checked, lighting is more accurate and realistic than with original N64 lighting method."

[Aquatakat]

Alright, how about this language? #1238

[gonetz]

Language is fixed, thanks!
How about my suggestion:
https://github.com/gonetz/GLideN64/pull/1238#issuecomment-261473210
?

[Aquatakat]

I'll put the tooltips back on each control/label. The only real reason I did it this way was so if there were any changes to the tooltips they only needed to be changed in one place rather than, for example, 6 (like on the sliders).

[gonetz]

I usually pick group of controls with mouse + Ctrl pressed, then with right mouse button select "change tooltip" to update tooltiop for all selected elements.

[Aquatakat]

Oh, I'll remember that if any need to be changed in the future.

[gonetz]

Current WIP:
https://drive.google.com/file/d/0B0YqMPjGo3B2WHI0cm1CSEc2SDg/view?usp=sharing

I have no more requests atm.
@Aquatakat, great work!
Thanks to all participants for help, criticism and advises.

[Aquatakat]

@gonetz I was reading some Qt documentation and I realised in a lot of spots where I just used a Layout to group controls I should have used a QFrame. You can apply a tooltip to a QFrame as well which makes more sense than applying the same tooltip to 6+ controls/labels. I'm going to change the form to use QFrames unless you know any reason why that might not be a good idea. I don't think any adjustment to the C++ will be necessary.

[gonetz]

Ok, I have no objections.

[gonetz]

Current WIP:
https://drive.google.com/file/d/0B0YqMPjGo3B2R0FxVmRYa1kwNk0/view?usp=sharing

One issues left:
If internal resolution is set to Original and then we disable FB emulation, 2D fixes remained disabled.

[gonetz]

Current WIP:
https://drive.google.com/file/d/0B0YqMPjGo3B2Zy1TNzFQblQwWkk/view?usp=sharing

Seems to be fully functional.

[Aquatakat]

With the new QFrame based signals some code might be redundant now. But everything is working properly ATM so it might be best to leave it alone - if it ain't broke, don't fix it.

[gonetz]

If you see some code, which looks redundant - let me know. I'll clear it and test.

[Aquatakat]

void ConfigDialog::on_fbInfoDisableCheckBox_toggled(bool checked)
{
    ui->readColorChunkCheckBox->setEnabled(!checked);
        ui->readDepthChunkCheckBox->setEnabled(!checked);
}

This behaviour may be fixed with the new signal to frameBufferOptionsFrame.

void ConfigDialog::on_nativeRes2D_checkBox_toggled(bool checked)
{
    ui->fixBlackLinesLabel->setEnabled(!checked);
    ui->fixTexrectDisableRadioButton->setEnabled(!checked);
    ui->fixTexrectSmartRadioButton->setEnabled(!checked);
    ui->fixTexrectForceRadioButton->setEnabled(!checked);
}

This behaviour may be fixed with the new signal to nativeRes2DFrame.

Inside ConfigDialog::on_frameBufferCheckBox_toggled:

    ui->readColorChunkCheckBox->setEnabled(checked && ui->fbInfoEnableCheckBox->isChecked());
    ui->readDepthChunkCheckBox->setEnabled(checked && ui->fbInfoEnableCheckBox->isChecked());

These may be fixed by the new signal to frameBufferOptionsFrame.

Also inside ConfigDialog::on_frameBufferCheckBox_toggled:

    const bool bCustomCropEnabled = checked && ui->cropImageComboBox->currentIndex() == Config::cmCustom;
    ui->cropImageWidthLabel->setEnabled(bCustomCropEnabled);
    ui->cropImageWidthSpinBox->setEnabled(bCustomCropEnabled);
    ui->cropImageHeightLabel->setEnabled(bCustomCropEnabled);
    ui->cropImageHeightSpinBox->setEnabled(bCustomCropEnabled);

I'm not sure but the signal sent to cropImageFrame might fix this.

Everything else looks OK.

[gonetz]

I tried to understand, how to replace on_toggled methods by signals, but failed. When I open edit signals/slots mode in QT Creator, I can't understand how you edit this mess?

Could you show, how to replace

void ConfigDialog::on_fbInfoDisableCheckBox_toggled(bool checked)
{
    ui->readColorChunkCheckBox->setEnabled(!checked);
        ui->readDepthChunkCheckBox->setEnabled(!checked);
}

by a new signal to frameBufferOptionsFrame ?

[Aquatakat]

The behaviour in the preview is correct, and the preview doesn't use any of the C++, so therefore you should be able to remove those lines. The signals/slots that govern whether or not those checkboxes are checked are these:

First, this QFrame which contains all of the options on the frame buffer tab except for the checkbox is enabled/disabled. Controls within a QFrame seem to remember whether or not they're disabled when their containing QFrame is enabled/disabled.

These lines should directly replace the code you quoted, as long as fbInfoEnableCheckBox is toggled properly in the C++, which it is.

When I open edit signals/slots mode in QT Creator, I can't understand how you edit this mess?

It is a bit of a mess. It's not the best system. It makes more sense to edit signals/slots with the GUI editor if possible:

and if not I found it easier to just write the XML in the .ui file myself.

Keep in mind: a few revisions ago the signals and slots editor contained dozens of entries for every specific control the frame buffer checkbox enabled. It's much cleaner now.

[gonetz]

Ok, thanks for explanation. I removed some code. No issues found. New binary:
https://drive.google.com/file/d/0B0YqMPjGo3B2UE04UHU2SGtYaHc/view?usp=sharing

[gonetz]

I updated translation files: c050d22553

Most of text strings changed, so lots of translation work need to be done again.
It would be great to have at least some translations ready before release.

[Aquatakat]

If you haven't received any translations yet I could provide comments/disambiguation texts if that would be helpful.

[gonetz]

I haven't received anything related to translations yet. I suppose, if somebody will start new translations, comments/disambiguation texts will be helpful.

[Aquatakat]

The fact that the GUI is basically done isn't really common knowledge, either. It might be worth it to re-advertise for translators as a new issue here and on the blog and possibly other places like emutalk.net.

It might even be time to show what the plugin can do on this repository's readme - I think possibly it's met and surpassed any HLE N64 video emulation to date.

[gonetz]

Useful links:
https://github.com/gonetz/GLideN64/tree/feature_new_gui/translations
https://github.com/gonetz/GLideN64/wiki/Internationalization

[gonetz]

First translation is ready! IlDucci, thanks!

[Aquatakat]

It looks really good! I'm super happy!

[IlDucci]

Thanks guys! A couple of notes here:

• Where can I find a compiled version for testing?
• You guys might want to find the old translators and giving them a PM before looking elsewhere. Keep in mind that folks like me will be looking after the master branch instead of the alternative branch (Like what happened with me, I translated the GUI twice: The one with the master copy and the one with this copy).

[Aquatakat]

It sounds like it might be time to take the plunge and merge feature_new_gui into master.

[gonetz]

New build - About dialog re-designed
https://drive.google.com/file/d/0B0YqMPjGo3B2VkszcFp2NnRoVWs/view?usp=sharing

Now it sounds like it is ready for master.

[Aquatakat]

I hope it goes smoothly.

[gonetz]

I will do it this weekend.

[oddMLan]

Looks good, but I can't see the 32x32 icon to the left of "GLideN64"

1277

[gonetz]

Me too :( It not shown in QTCreator also

[gonetz]

Something is wrong with Icon.ico. QTCreator can't open it.

[gonetz]

I tried to save Icon.ico with IrfanView, but resulted icon has black outline:

Help needed.

[oddMLan]

Icon format is correct with Windows-spec. It uses compressed PNG for bigger sizes, eg 128x128 and 256x256. Icon was saved using program especially designed for that purpose. Most likely QT doesn't support PNG compression. Since icon in the window title and taskbar is managed by Windows itself, it shows with no problems. Icon in the GUI it's displayed by QT, which cannot load the icon. Moreover, it seems that it's scaling down the icon from the full-sized version. I measured the dimensions in that screenshot and the icon shows as 34x34, which is an invalid icon size. My theory is that since a 34x34 icon doesn't exist in the file QT is trying to scale down the full-sized 256x256 PNG-compressed icon. Try to fix the size to see if it can read the 32x32 icon from the file.

Also are you using the current version of QT creator? @Aquatakat didn't have any error message AFAIK

[Aquatakat]

I'm using Creator 4.10 on Qt 5.7. I'll try extracting one of the bmp sizes into its own file and using that instead.

I think it's probably likely that whatever Qt that gonetz is using to compile doesn't support PNG at all. I remember when I originally designed the form and all the various icons in it I was using plain jane .png files which worked on my preview but not when compiled.

[Aquatakat]

Alright, @gonetz #1281

[oddMLan]

Now that you mention it, I think the version he uses is actually stripped of any PNG support, It's a situation in which the inbuilt libpng library in QT conflicts with Hi-res texture support, so he uses his own static libpng build lib into the project.

@gonetz The current stable version of QT is 5.7.0 and has MSVC 2015 support. Do you think it's time to upgrade the solution? It's a bummer that QT takes so long to install and setup though.

Maybe the new version doesn't have the problem with the PNG support.

[Aquatakat]

I'm wondering if we could just archive the 128x128 and 256x256 icons for now - there's not currently anywhere they're displayed.

[gonetz]

we could just archive the 128x128 and 256x256 icons for now

Yes, we could.

[gonetz]

The feature merged to master.
I squashed all dev commits into 1 commit.
Ryan, Thanks!

[Aquatakat]

You're welcome.

[oddMLan]

Is the question mark (?) useful for anything?

It should be removed from the titlebar.

[Aquatakat]

@oddMLan I tried to figure out a way to remove that question mark in the XML but I wasn't successful. Maybe I'll poke around in the C++.

[Aquatakat]

@gonetz It looks like a quick and easy change based on this to remove the "What's This" question mark from the title bar by changing the two spots where QDialog() is called to include Qt::WindowTitleHint | Qt::WindowSystemMenuHint as the second argument. I would create a pull request, but C++ is too foreign to me―I don't even know if Qt is an accessible object there.

[gonetz]

Yes, it works. Thanks!

[oddMLan]

I see two issues now

• You removed the What's This button, but now the close button is disabled.
• Gamma override combobox stays grayed out when you check it. To get it enabled you have to check it, press OK and then open the configuration again.

[gonetz]

@Aquatakat

Can the problem with Gamma override combobox be fixed without cpp modification?

[Aquatakat]

@gonetz Unfortunately not, but the fix is simple. #1299

[gonetz]

Thanks!