GUI not showing up in 32 bit Windows build


#1

Hi folks,

In a weird inverted deja vu thing, I am having an issue where the GUI in my 32-bit VST is showing up as a white window. No sliders or knobs are visible, but I can use the mouse to grab on and change the values of the invisible sliders and knobs. This is similar to a bug I posted a few months back (where the GUI disappeared in the 64-bit build), but my 64-bit build works great.

I added some new ImageButtons for this build, as well as a few minor graphic changes. Things compile great on OSX - it is just the 32-bit Windows code that is giving me grief. I am using VS2010.

Any suggestions for what I should be looking out for? I’ve set the FP mode to precise (which was linked to the 64-bit bug), but this doesn’t fix things.

Regards,

Sean Costello


#2

There was definitely some kind of floating-point setting in win32 that makes it over-optimise and breaks all the rendering code. Can’t remember the details but you should be able to find something about it in the forum somewhere.


#3

OK, I turned off “Whole Program Optimization” in the VC2010 Properties->Configuration Properties->C/C+±>Optimization section (for Win32), and the GUI now shows up.

The next issue that came up: one of my buttons wasn’t transmitting its toggle state in the Win32 build. This is kinda weird. I fixed this by turning off optimization on my editor .cpp file. Which I will probably start doing as a basic practice from now on.

Sean Costello


#4

Are you transmitting your button’s toggle state with a bool flag somewhere? If so, maybe you need to make it volatile or use an Atomic, otherwise if it’s shared between threads, the compiler might be caching its value separately in each thread.


#5

Hi,

Here is the thread about this issue: http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=3664&hilit=sse+png
Culprit turned out to be SSE.

Hope this helps
Robert


#6

It’s a pity that there’s no practical way to figure out which bit of code is getting optimised incorrectly… If so, I’d probably be able to find a workaround and avoid the issue, but it could be anywhere in the 10000+ lines of code involved in rendering.