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.

[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