You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A "fix" is to remove the return function in ofThread here:
void ofThread::startThread(bool blocking, bool verbose){
if(thread.isRunning()){
ofLogWarning(thread.name()) << "cannot start, thread already running";
//return; // don't return here and the mouse works just fine.
}
So, basically, threadRunningis getting set to true and the only way I can see that happening is b/c startThead is called somewhere ... I can't figure out where and why it only happens when using the ofGLES2Renderer
The mouse cursor is subject to the shader :) (this is seen in
raspberrypi_ES2ShaderExample)
:) yes, i've fixed the custom shaders so the default shader is set when
end is called, check the shaderExample in examples/gl that should work
ok now
For some reason, when using the ofGLES2Render, when entering the
EGLWindow's infiniteLoop, ofThread throws the error:
this is super weird, i'm not getting it at all, and startThread is
called only once, it seems more some kind of memory corruption or
something like that, where thread isRunning is returning true for some
reason even if it's not really running. it's also weird that you don't
have the thread priority methods, probably you have a different version
of the poco library to that in the headers and that's making the threads
go crazy, i'm not sure what version we are using in the core, the last i
remember compiling is 1.4.3 but it's weird that you don't have the
priority functions in 1.4.4 and i do, the last version seems to be 1.4.5
where those functions exist too
A "fix" is to remove the return function in ofThread here:
|void ofThread::startThread(bool blocking, bool verbose){
if(thread.isRunning()){
ofLogWarning(thread.name()) << "cannot start, thread already running";
//return; // don't return here and the mouse works just fine.
}
|
So, basically, |threadRunning|is getting set to |true| and the only way
I can see that happening is b/c |startThead| is called somewhere ... I
can't figure out where and why it only happens when using the
|ofGLES2Renderer|
—
Reply to this email directly or view it on GitHub #2 (comment).
Yes, I'll bet that my armv6l poco libs are not matched to the header versions. Is there any easy way to check the header versions? Or should we upgrade to poco 1.4.5 across the board?
@arturoc I tested the new shaderExample and it works great! The shader is not applied to the mouse texture.
The apps/devApps/raspberrypi_ES2ShaderExample/ examle does apply the shader to the mouse texture. I believe this is because that example is replacing the default shaders. Is that correct? And is this expected behavior? Or should we also figure out a way to never apply any shaders to the mouse tex?
i think it is ok if the default shader applies to the mouse texture. also most examples shouldn't pass a default shader but use a custom one inside the app, the iphone example was setup like that because there was a problem with the custom shaders but it's fixed now.
about poco, i've been looking for a way to check the version but had no luck, i was thinking that we should try to remove as much libraries as possible and use the system ones, even for poco and opencv unless there's some major incompatibility, that way we will be able to give support for every device
also we could have libraries like tess2 which are just a couple of files as source directly and use a mechanism in the makefiles similar to that we have for addons so if there's an src folder it is compiled with the OF library
Also .. just noticed that the current raspberry pi Poco repo is running poco 1.3.* I don't think that thread priority stuff was added until 1.4. Do you think poco 1.3 will be a problem? Are we relying on any other 1.4+ features (the current poco headers are 1.4.*).
So debian is infamous for defaulting apt-get to older versions. I wonder fi
we should update the sources config of apt-get to include the newer
versions.
On Nov 28, 2012 5:16 PM, "Christopher Baker" notifications@github.com
wrote:
Also .. just noticed that the current raspberry pi Poco repo is running
poco 1.3.* I don't think that thread priority stuff was added until 1.4. Do
you think poco 1.3 will be a problem? Are we relying on any other 1.4+
features (the current poco headers are 1.4.*).
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-10825415.
the problem with the experimental repo is that setting it up can be messy, we could get the packages we need from it and create an ubuntu ppa so we can have some newer versions for packages that are outdated like this although i'm not sure that ubuntu ppa wil support arm
Activity
bakercp commentedon Nov 21, 2012
Mouse examples
e.g https://github.com/raspberrypi/firmware/blob/master/opt/vc/src/hello_pi/hello_triangle2/triangle2.c
e.g. https://github.com/chriscamacho/gles2framework/blob/master/src/input.c
arturoc commentedon Nov 21, 2012
was looking through the examples and that code is also plain linux nothing particular for the rpi so it can be integrated in the ofAppEGLWindow too
Merge pull request #2 from arturoc/gles2
bakercp commentedon Nov 27, 2012
Almost working flawlessly. Two issues @arturoc
A "fix" is to remove the return function in ofThread here:
So, basically,
threadRunningis getting set totrueand the only way I can see that happening is b/cstartTheadis called somewhere ... I can't figure out where and why it only happens when using theofGLES2Rendererarturoc commentedon Nov 28, 2012
On 11/28/2012 12:43 AM, Christopher Baker wrote:
:) yes, i've fixed the custom shaders so the default shader is set when
end is called, check the shaderExample in examples/gl that should work
ok now
this is super weird, i'm not getting it at all, and startThread is
called only once, it seems more some kind of memory corruption or
something like that, where thread isRunning is returning true for some
reason even if it's not really running. it's also weird that you don't
have the thread priority methods, probably you have a different version
of the poco library to that in the headers and that's making the threads
go crazy, i'm not sure what version we are using in the core, the last i
remember compiling is 1.4.3 but it's weird that you don't have the
priority functions in 1.4.4 and i do, the last version seems to be 1.4.5
where those functions exist too
a
bakercp commentedon Nov 28, 2012
Great on the mouse texture shader interaction.
Yes, I'll bet that my armv6l poco libs are not matched to the header versions. Is there any easy way to check the header versions? Or should we upgrade to poco 1.4.5 across the board?
bakercp commentedon Nov 28, 2012
@arturoc I tested the new shaderExample and it works great! The shader is not applied to the mouse texture.
The
apps/devApps/raspberrypi_ES2ShaderExample/examle does apply the shader to the mouse texture. I believe this is because that example is replacing the default shaders. Is that correct? And is this expected behavior? Or should we also figure out a way to never apply any shaders to the mouse tex?This is looking great! Nice work!
arturoc commentedon Nov 28, 2012
i think it is ok if the default shader applies to the mouse texture. also most examples shouldn't pass a default shader but use a custom one inside the app, the iphone example was setup like that because there was a problem with the custom shaders but it's fixed now.
arturoc commentedon Nov 28, 2012
about poco, i've been looking for a way to check the version but had no luck, i was thinking that we should try to remove as much libraries as possible and use the system ones, even for poco and opencv unless there's some major incompatibility, that way we will be able to give support for every device
also we could have libraries like tess2 which are just a couple of files as source directly and use a mechanism in the makefiles similar to that we have for addons so if there's an src folder it is compiled with the OF library
bakercp commentedon Nov 28, 2012
I agree on both accounts. I'll modify the make files to compile core lib sources.
I'll also get RPI running with system poco via
apt-get install libpoco-dev.bakercp commentedon Nov 28, 2012
Also .. just noticed that the current raspberry pi Poco repo is running poco 1.3.* I don't think that thread priority stuff was added until 1.4. Do you think poco 1.3 will be a problem? Are we relying on any other 1.4+ features (the current poco headers are 1.4.*).
bakercp commentedon Nov 28, 2012
There are a lot of changes since 1.3 ...
https://github.com/proxy/raw.github.com/pocoproject/poco/poco-1.4.5/CHANGELOG
danzeeeman commentedon Nov 28, 2012
So debian is infamous for defaulting apt-get to older versions. I wonder fi
we should update the sources config of apt-get to include the newer
versions.
On Nov 28, 2012 5:16 PM, "Christopher Baker" notifications@github.com
wrote:
jvcleave commentedon Nov 28, 2012
you might be able to get it with an experimental repo
http://packages.debian.org/search?suite=experimental&arch=armhf&searchon=names&keywords=poco
arturoc commentedon Nov 29, 2012
the problem with the experimental repo is that setting it up can be messy, we could get the packages we need from it and create an ubuntu ppa so we can have some newer versions for packages that are outdated like this although i'm not sure that ubuntu ppa wil support arm
bakercp commentedon Dec 4, 2012
I think there is some poco thread stuff involved here -- see #62.
bakercp commentedon Dec 4, 2012
This is resolved using the 1.3 debian system poco libs (and should be resolved with @artoroc's recompiled 1.4.3p1 poco libs).
bakercp commentedon Dec 4, 2012
fixed with #63
Merge pull request #2 from elliotwoods/feature-ofParameter
Merge pull request #2 from arturoc/3dprimitives