Building a Syphon Cinder block application in Eclipse CDT

[eight]

Hello,

Is Syphon development supposed to happen only in XCode? I am trying to build my app in Eclipse CDT, using Syphon Cinder block. My build fails in the link stages, specifically I am not sure how / whether it is possible to “Add the framework to the Link Binary With Libraries build stage of your application’s target.” (http://syphon.v002.info/FrameworkDocumentation/)

Thanks for sharing your thoughts about this.

[vade]

Im not familiar with Eclipse CDT at all, but it seems as though other people using Eclipse have had similar questions.

Does Eclipse also provide compilation, linker and target info? Ie, is it just a text editor with syntax highlighting, or does it allow you to specify compiler and linker options?

If the latter, you ought to be able to specify linker flags to link the the Syphon.Framework and also have search path setups for compilation so it finds the headers.

I have no idea about Eclipse, but any fully fledge Mac compatible IDE should let you use arbitrary frameworks and link to them.

A quick google search brought up someone with similar questions:

http://stackoverflow.com/questions/5085992/mac-os-x-eclipse-c-how-to-connect-frameworks-to-environment

With no answers. Any reason you are using Eclipse and *not* XCode?

[eight]

I find developing in Eclipse CDT faster, mostly due to the content assist, class/method/calls navigation etc. It is a full fledge C++ IDE, with all the features you mentioned plus a debugger.

Now, if syphon was available in the form of a compiled library, such as a *.a files, then I would have no problem setting up the references to it in the Eclipse CDT project. I, however, don’t see any option to link “frameworks”. Is the latter a Objective C notion? If so, I have not found a way to compile Objective C program in Eclipse CDT.

Is it possible to recompile syphon into regular *.a libraries?

Thanks.

[vade]

Yes, Frameworks are an Obj-C/Cocoa-ism and are Mac Only. We provide Syphon as a framework because Syphon is Mac Only, and leverages many Obj-C and Mac-only technologies. Frameworks offer much improved linking over static libraries as they:

a) Provide versioning. If we put out a new Syphon framework with new features, your old calls will still work because the framework will include an older version of the library that you’ve linked against and used. Static .a libraries can’t do that to my knowledge.

b) Provide included headers and resources that the framework needs, such as nib file, images, etc that are used by the framework.

c) Syphon leverages Obj-C and existing Cocoa frameworks included on Mac OS X, so even if you get a .a out of it, your application will still need to link to other Obj-C frameworks.

I highly recommend finding a way to link against the frameworks (You can use GCC compiler flags on Mac OS X “-framework Syphon” for example)

Check out the first few pages here:

http://developer.apple.com/tools/gcc_overview.html

I am very hesitant to provide a .a, only because of the aforementioned issues and future proofing problems, and it seems to be not directly solving your issue. Also, im not even sure its possible considering we require linking against other frameworks, so its kind of moot, no?

Edit: that said, you might be able to download the Syphon-framework code and edit the XCode project to output a .dylib or .a for the target. Im honestly not super familiar. Check http://code.google.com/p/syphon-framework/ for the most up to date Syphon Framework source and project files.

[eight]

Thanks, vade. After reading about frameworks, I realized that it is possible to link against them in Eclipse CDT. For the record: Project Properties->MacOS X C++ Linker ->Miscellaneous->Linker flags.

I only now need to teach it to compile .mm files (they come with the cinder block) together with the corresponding *.h files.

–8

[vade]

Awesome. Im glad its starting to sort itself out. Definitely let us know what you end up making with Syphon. Always curious to know what people are doing with it.

[eight]

I am trying to crop and warp a very wide image in cinder and pass it over to isadora via syphon cinder block. I looked in the documentation, but still can’t figure out how the scaling is done and what texture formats are supported in

[(SyphonServer *)mSyphon publishFrameTexture:texID textureTarget:GL_TEXTURE_2D imageRegion:NSMakeRect(0, 0, inputTexture->getWidth(), inputTexture->getHeight()) textureDimensions:NSMakeSize(inputTexture->getWidth(), inputTexture->getHeight()) flipped:false];

calls.

My cropped and warped texture is displayed correctly in cinder (http://forum.libcinder.org/topic/crop-image-with-polygons#23286000000721008), then frames are published into a syphon server via above call, but in the Simple Client they are blown up (please see the picture: http://post.scriptum.ru/svalka/dragToSyphon.png

(cinder display on the left, client display on the right)

I would appreciate a clarification about the texture formats and scaling rules while publishing frames on the Syphon server.

Thanks.

–8

[eight]

Actually, I figured that out — I simply can change the texture type to my type and that fixed the scaling issue. However the crop and warp still aren’t transferred to the client, but rather an unwarped complete texture: http://post.scriptum.ru/svalka/dragToSyphon.png, when i get the texture to publish via a ci::gl::Texture mTex = ci::gl::Texture(ci::app::copyWindowSurface());

I would appreciate your thoughts how this should be done properly.

Thanks

–8

[bangnoise]

Heyhey, glad you seem to be getting there…

publishFrameTexture… does no scaling. imageRegion defines a sub-area of the texture to be published – useful if you are using a 2D texture with power-of-two dimensions beyond the size of your image. Internally Syphon draws your texture onto the shared surface, so any texture format is supported.

If you have a large texture you want to crop and warp, then either create an intermediate cropped-and-warped texture, and pass that to Syphon, or don’t use publishFrameTexture… at all, and instead -bindToDrawFrameOfSize: and -unbindAndPublish with code to scale/crop/warp and then draw your large texture between the calls.

The latter would be the fastest.

That make sense?

The current SVN has support two new features which might be of interest

1. The ability to indicate a preferred internal texture format, if you want to pass formats other than BGRA8 around. Support for this is working but not perfect.

2. The ability to inspect the current frame from the Server side, so you could use bindToDrawFrameOfSize: and then use the frame image elsewhere for your own drawing in the Server app, if that’s something you need to do.

[bangnoise]

Sorry, we posted simultaneously and I didn’t see your second message.

Without knowing what you’re doing to crop and warp the texture, it’s hard to know – but it sounds as if doing whatever you’re doing between calls to -bindToDrawFrameOfSize: (passing the size you’d like to SyphonServer to send images as) and -unbindAndPublish might work – otherwise perhaps if you share some more code we can give more precise pointers.

[eight]

Hi bangnoise!

Thanks a lot, I am almost there. I tried your suggestion to use bindToDrawFrameOfSize and unbindAndPublish, and got my warped and cropped image in the Simple Client…with up to 60 fps (which is the whole point of this exericise!) with a caveat. It seems the Simple Client draws a larger size texture, than I am calculating between the bind.. and unbind..

http://post.scriptum.ru/svalka/syphonClientWarpandcrop.png

Here is a code I am using, I think it should be clear what I am doing:

void dragToSyphon::draw()
{
	glClearColor( 0.0f, 0.0f, 0.0f, 1.0f );
	glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );

	Rectf cropRect = Rectf(0.5f * mTexture.getWidth()+shift, 0.0f * mTexture.getHeight(), 1.0f * mTexture.getWidth()+shift, 1.0f * mTexture.getHeight());

	mScreenSyphon.bindToDrawFrameOfSize(cropRect.getX2() - cropRect.getX1(),cropRect.getY2()-cropRect.getY1());

	gl::setMatricesWindow(getWindowBounds().getWidth(), getWindowBounds().getHeight());

	gl::pushModelView();

	//mTransform is responsible for warping -- calculated using opencv library
        gl::multModelView( mTransform );

	mTexture.enableAndBind();

	Rectf warpRect = Rectf(0, 0, mMovie.getWidth(), mMovie.getHeight());

	//Cropping
	drawTexturedRect( warpRect, cropRect, true );

	gl::popModelView();

	mScreenSyphon.unbindAndPublish();
	mTexture.unbind();

	gl::color( Color( 1, 1, 1 ) );
}

Entire cpp file: http://post.scriptum.ru/svalka/dragToSyphon.cpp

–8

[vade]

First thing I notice is that you want to clear *after* you mScreenSyphon.bindToDrawFrameOfSize, since that call binds an FBO, and that FBO ought to be cleared.

Im not sure what I ought to be seeing as far as imagery is concerned though. You are setting the matrixWindow (not sure what that corresponds to in GL terms, the viewport?) to the window size of your app, but the FBO’s extent is the crop-rect. Could that be part of the issue?

Are you getting an image that is the same size as you are specifying in cropRect? The newest Simple Client / Simple Server in SVN gives you the image size, so you can debug easier. Are you using the latest public download of Syphon, or the SVN source of the framework and implementations?

[eight]

Yes, setMatricesWindow sets the viewport and its origin. The fresh Simple Client shows the correct size of the crop area, so I think the bug is in the crop procedure itself. Anyway, even with the current state, I can move on, since I seem to have been able to solve main issue of dynamically cropping the textures on the graphics card and handing them over to isadora — thanks to Syphon!

http://post.scriptum.ru/svalka/serverClient.png

Best regards and thanks — you guys are great.

–8

[Author]

Posts