Project64: Glide64 drop down selection and tooltips broken

[Frank-74]

Clicking on the down arrow next to a dropdown box, doesn't show the options. Have to select it and use arrow keys to change options instead.

Also tool tips are no longer working.

[project64]

if compiled in VS2013 it works fine, broken in vs2008 which the release version should be released with. The dropdown box I know how to solve now, still looking at how to get the tool tips working,

[oddMLan]

Why using VS2008 instead of VS2013/2015 for the release versions?

[JunielKatarn]

Why using VS2008 instead of VS2013/2015 for the release versions?

Beats me. I have compared builds from both versions continuously and there seems to be no advantage in using older compilers. Moreover, using VS2008 forces maintaining a duplicate set of makefiles.

[AmbientMalice]

Preserving legacy support is worthwhile.

[oddMLan]

One can compile VS2015 builds with Windows XP support just fine?
Not to mention, the manifest generation is broken in VS2008 as well, so Project64 ends up not having themed controls and buttons.

[project64]

there was an issue with the XP version on higher visual studios, that has been fixed, the version from VS2008 I know has been well tested. I really need comparisons to say one version is actually faster or better, often VS seems to build slower resulting files as they do more security checks.

older versions generally good at running on current and newer systems, newer versions are not always so good at running on older systems. Most of the time as well newer VS need a while to be tested and used for them to be stable, something like 2013 might be stable enough, I do not think vs2015 is likely to be there yet.

[oddMLan]

Agreed. VS2013 seems to be good enough, and that's what a lot of current projects use. Heck, even VS2010 is still somewhat used, but VS2008 seems too obsolete and I dont know of any other projects who still use it

[project64]

I may consider using VS 2013 or vs 2012 for project64 2.4, but I am not going to mess around and change the build server before 2.3 is released, so 2.3 will be released using vs2008

[oddMLan]

Fair enough.

[cxd4]

The only time newer versions of MSVC are going to offer stability or security improvements is with more arbitrary things like the interfaces by Microsoft, such as the framework, run-time interfaces, etc..

In the absence of that, newer versions are primarily for automatic optimizations. Unless disabled, the increase of said optimization has time and time again proven to lead to losses of stable functionality with large code bases, and the optimizations can, have, and will sometimes have failed and lead to less performance instead of more. These are the things that you need to have properly tested over an extensive period of time to make sure that an upgrade to newer versions of a proprietary compiler is warranted or even of positive change.

Until that reality, the development of the code is a much more interesting occupation of time.

[JunielKatarn]

Preserving legacy support is worthwhile.

@AmbientMalice VS2015 builds work perfectly fine on XP.
VS2013 is not more stable than 2015. Microsoft uses 2015 for current development, actually.
I'd like to test whether there's any real (non-rhetoric and user experience-based) performance benefit on using older compilers. Has anyone run such a test for Pj64?

[LegendOfDragoon]

Until that reality, the development of the code is a much more interesting occupation of time.

Agreed.

Changing compiler versions won't even make a big difference in performance if the main bottleneck is JIT code or API functions.

[project64]

I have found that microsoft focus new versions of Visual studio on there current interest, was dot net, now mobile, that is where it gets improved for, with c++ very little changes. You get new things like a proper rounding function, but in general not much. I usually also find that newer VS versions actually have worse performance. It would be interesting to compare VS2008 version vs 2013 or 2015 and see if there is any performance difference.

with this actual bug, https://github.com/project64/project64/commit/d2821871a2fbe697c43958ad99175365ac7d70fd should fix the drop down. i did work out the tool tips, will get a commit tonight most likely.

[project64]

https://github.com/project64/project64/commit/56f9194b704fcbfafe41d40bda8989573479dfa8 should fix the tool tips

[Frank-74]

Yes, its fixed now.

Just doing some tidying up of the tooltip formatting. A few newlines are not needed.

[cxd4]

Changing compiler versions won't even make a big difference in performance if the main bottleneck is JIT code or API functions.

Basically. The difference in performance applies to how much you rely on implicit optimization.

We disagree on how much the code should be left readable for automatic optimizations applied, but anything hard-coded like the JIT or anything out of C's jurisdiction, like Microsoft's own closed-source libraries, makes that begin to get negligible.

I have found that microsoft focus new versions of Visual studio on there current interest, was dot net, now mobile, that is where it gets improved for, with c++ very little changes. You get new things like a proper rounding function, but in general not much. I usually also find that newer VS versions actually have worse performance. It would be interesting to compare VS2008 version vs 2013 or 2015 and see if there is any performance difference.

That's pretty much what I conjectured. This also with C99, or newer C standards which are not backwards-compatible, nor completely conformed to in any version of MSVC. It makes little sense to not just use forwards-compatible standard code, unless there is a compelling reason to use C99 features--most of which inhibit the portability of C as a language.

The worse performance is tested out to easily be from assumptions from automatic optimizations: Almost every optimization by the compiler--the harder it is for us to conceive hard-coding it ourselves--has a chance of depleting performance instead of increasing it. (VC2013 is the exact same as 2008 in this regard to branch prediction output.)

That being said, the latest MSVC is always recommendable for the purpose of causing these aggressive (many times wrong/slower) optimizations, if it means causing the program to crash and show bugs in the code's evasiveness to implementation-defined behavior and the like.

[project64]

@Frank-74 thanks, I wanted to get rid of wx library, so had to rebuild all the UI, was just trying to make sure it stayed functionally the same