0.9.1 Release Candidate 1

I’m still investigating. In the setup method I’ve a call to a method that generates a mesh. I’m also using ofxGui, with 2 listeners on 2 sliders, both of the 2 listeners goes to re-generate the mesh when the value is changed. The thing is that these 2 listeners are triggered also when the app starts. In OF 0.9.0 this was not a problem, but in 0.9.1 it is. I’ve cleaned up my app, removing all the thing that are not used and pushed it here https://github.com/edap/Lsystem/tree/error

@braitsch - I believe that was also the case in 0.9.0
Have you been using 0.9.0 with HiDPI? or 0.8.4?

but when you run the application under xcode doesn’t the debugger stop on a specific line?

@arturo it stops at line 24 of openFrameworks/3d/ofNode.cpp. It is not the GUI, I’ve removed it and the error it is still happening.

@theo I’ve been using 0.9.0 since the pre-releases so it looks like something’s changed between 0.9.0 & 0.9.1.

Here’s what I get in a new project (default settings) with high resolution capable enabled in both 0.9.0 & 0.9.1

v0.9.0

ofGetWidth() -> 1024
ofGetScreenWidth() -> 2880

v0.9.1

ofGetWidth() -> 2048
ofGetScreenWidth() -> 2880

can you post some code that has the problem?

@arturo was it referred to me or to braitsch? the code is here https://github.com/edap/Lsystem/tree/error, the entry point is the build method in the LSystem class. I will also have a look tomorrow

@edapx the problem is that you are using push_back to push elements into the vector which will move things in memory so when you set a node as another’s parent but then push back the previous address for that node becomes invalid. an easy way to solve this is to use a vector of shared_ptr instead of directly ofNode which will alocate the nodes in the heap and even if the vector grows the nodes won’t move from where they are

@braitsch - I believe that was a change that was made intentionally as a start towards getting retina better supported in OS X. On iOS this is how things behave - (if you enable retina you get a window with twice as many pixels).

The reason it is different between 0.9.0 and 0.9.1 is that in 0.9.0 the screen width was actually not getting reported correctly.

as an experiment if you try drawing a circle at (1024, 0) in 0.9.0 and in 0.9.1 they should both draw in the top middle of the screen as the screen size isn’t different between 0.9 and 0.9.1 but the width was not being reported correctly for retina enabled apps.

I hope that explains it.

Right now for retina you have to handle the scaling etc yourself - (we just give you a bigger frame buffer)
For 0.10.0 we should aim to have the ability to have the retina scale passed through to the renderer so it requires no changes on the user’s end.

actually @braitsch - please ignore that last message, this is actually a bug which I think I introduced trying to solve another issue.

thanks for reporting this.
I’ll work on a fix.

fyi - we’ll be doing a bunch of work on Retina for 0.10.0 - so things might change a bit with how it works ( right now you get a smaller window when requesting retina )

Ok cool. I was gonna say this seemed a bit weird because if I setup my app in main with:

int main( )
{
	ofSetupOpenGL(1920, 1080, OF_WINDOW);
	ofRunApp(new ofApp());
}

and enable retina ofGetWidth() returns 3840 even though the window doesn’t fill the screen which ofGetScreenWidth() reports as 2880 wide.

Hi guys,

great job as always!

I have a question on 0.9.1RC1 and emscripten:

  1. when I run emmake on a project, the compilation is successful!
    but it seems that after the compilation to run a --emrun.

–emrun seems to start by default with Safari? obviously this on Linux is bad! (true?)

it seems that the offending piece:

config.emscripten.default.mk:PLATFORM_LDFLAGS = -Wl,–as-needed -Wl,–gc-sections --preload-file bin/data@data --emrun

you think you can add a “IF” for the platform in “config.emscripten.default.mk”?

or am I doing wrong in something?

Have a nice day!
Dario

what would be the correct flags then? i don’t think the flags passed to the compiler have any influence on the browser chosen by emrun. you can also choose the browser by running emrun --browser firefox bin/example.html for example and you can also call emrun --list_browsers to check which browsers emrun is detecting, if it’s detecting safari in linux there might be something wrong in your config

My problem was solved using the right data structure suggested in this thread.

I apologize this is a false problem, I dug, I got fooled by my configuration emscripten that was pointing to a browser that does not exist, photo:

(I have to find out why my emscripten provides an empty field as browser!!!)

obviously this does not have anything to do with the flags of compilation, sorry…

Is ofTrueTypeFont::drawString() in this release supposed to work with Unicode letters such as Korean?
I tested but could not make it work.

no not yet, we’ll merge that for 0.10. 0.9.1 is a bugfixes only release

Thanks Arturo.
Fortunately ofxTrueTypeFontUC still works with 0.9 for drawing Unicode letters. Looking forward to seeing 0.10.

The good news is that

The RC1 is broken on MSYS2. GCC crashes when compiling DirectShowPlayer. Filed issue #4748.