GEM-dev December 2005

gem-dev@lists.iem.at

11 participants
20 discussions

udev dv input
by Georg Holzmann 15 Dec '05

15 Dec '05

Hallo gem-devs! As I use udev now I cannot use the dv input in Gem anymore. The problem is the following (i think): with devfs the device was /dev/dv1394 (on my computer) now (udev) the device is on my computer /dev/dv1394/0 The problem is, that /dev/dv1394 is hardcoded in videoDV4L.cpp, so changing line 194: if ((fd=open("/dev/dv1394", O_RDWR)) < 0) { to: if ((fd=open("/dev/dv1394/0", O_RDWR)) < 0) { fixes the problem ! So we would need an additional message, to set the proper device - don't know which one... (pix_video is already very confusing) anyway, I don't have the time to make a clean implementation now - have to make a video till friday ... :) LG Georg

2 1

GemMan wonderings
by james tittle 14 Dec '05

14 Dec '05

...I just noticed that when I create a border-less window, then destroy it and close the patch, if I then open another patch and open a window, it will start without a border! Obviously some window state is not being destroyed or re-initialized correctly... ...so then I look and sure enough, we have all the "statics" at the top of GemMan.cpp (including "int GemMan::m_border = 1;"), but in gemwin a borderMess call directly assigns it's value to GemMan::m_border :-( This doesn't seem right...I mean, if we're going to have statics, they shouldn't change, right? ...then I thought to look at the destroyWindow() stuff, and it calls windowCleanup(), which does nothing... ...so I look at windowInit(), and it's filling out a WindowHints structure from the statics...that's ok, as long as those statics aren't touched...but, I'm then confronted with: myHints.shared = constInfo.context; ...which I still cannot figure out where constInfo is declared, much less constInfo.context! ...does anyone know the real difference between a constWindow and a Window? They both seem to do similar things... ...lastly, I was wondering where GemMan::createContext() was called, and it is in gemwin: seems to me like this should be created outside of gemwin, but I guess I don't know where the names derive from... ...I'm imagining that we should have window creation something like this (which would also work for multiple_windows): - somewhere in GemMan, there should be the default, static, initial values for window parameters - create a context not attached to window and assign it as the "share" context - gemwin, when it calls GemMan::createWindow, also passes it's own WindowHints structure, such that GemMan::createWindow (or a sub- function) takes care of filling in default values or whatever has been requested during gemwin's creation, but that shares the "share" context - gemwin then only modifies it's own WindowHints, but can retain them when the window is destroyed, and pass them back again if that same window is re-created (for instance, if you decided you didn't want a titlebar/border, and are on a window system that doesn't allow window titlebars to be changed on the fly) ...come to think of it, I bet this is mostly along the lines of multiple_windows, but I don't have that project open in front of me... thoughts? jamie

2 1

GL extensions on Windows
by chris clepper 13 Dec '05

13 Dec '05

I have attempted to build a version of GEM on Windows that supports GL greater than 1.1 without success so far. Google has given me some conflicting info about the process stating 'use SGI glext.h' or 'don't use anything from SGI' or 'use GLEW or the like'. I have glext.h which allows for a clean compile but linking always fails with something like this: fragment_program.obj : error LNK2019: unresolved external symbol _glGetProgramivARB@12 referenced in function "protected: virtual void __thiscall fragment_program::printInfo(void)" (?printInfo@fragment_program@@MAEXXZ) Well, duh. The MS opengl32.lib obviously knows jack about the changes to GL since 1996. It doesn't look like an alternative lib exists. So what the heck does one do? I have a little sample code that basically cuts and pastes the typedefs from glext.h into the source, assigns a pointer to a local var and doesn't include glext.h, but that seems like an obnoxious way to deal with the 800 billion extensions since GL 1.1.

2 1

constInfo.context?
by james tittle 10 Dec '05

10 Dec '05

...in GemMan, there's a "constInfo.context" that I'm having a hard time figuring out where it's actually assigned a value: any ideas? This came about because I finally got around to putting some code into GemMan::initGem that creates a non-window-associated gl context ("masterContext") which can be used to the create "shared Contexts" later on, associated with a window...this has two purposes: 1. it allows me to remove all the stupid "HaveValidContext()" calls that are sprinkled thruout the code in #ifdef __APPLE__'s: the cool thing here is that osx users will now be able to loadbang gl calls that'll actually mean something (like loading models, images, programs, ...): apple's gl is very strict about context association, and would crash before... 2. it allows me to fix the multiple_windows problem of not actually sharing some gl items, like textures, programs, framebuffers, etc...I'm now trying to update that branch so that I can release another test, and of course to extend work on it... ...so I'm wondering if GLX/WGL needs a "masterContext" to share resources with? more l8r, james

1 0

pix_snap2tex
by Erich Berger 08 Dec '05

08 Dec '05

hello, some changes in the code of pix_snap2tex prevent the possibility of using pix_coordinate to tile the texture onto a geos. i guess pix_snap2tex would need a mode, repeat message like pix_texture i hate to ask this but is there a possibility for a quick fix,? would i only need to uncomment the following lines or is there more: // glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); // glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); best erich --------------------- http://randomseed.org

2 2

filmQT windows etc.
by chris clepper 07 Dec '05

07 Dec '05

I fixed the constant crashing when using QT movs on Windows, by eliminating the DisposeGWorld() call in the close() method. This introduces a ~4k per call memory leak when switching files. I might get around to working out a leak free fix, but in the finest Microsoft development tradition it's 'good enough' for now. I also took out the RGBA transfer function in getFrame() since it was just a fairly pointless memcpy(). This is also on the TODO list for Windows: Make pix_videoDS work with sizes other than 320x240 Figure out how to make texturing performance not completely suck Add in YUV path pix_record Anyone know how to get the damned debugger to work with Gem.dll? It refuses to stop at breakpoints. Oh and nobody seems to ship code with symbols in Windows land. Makes finding QT crashes a total joy. cgc

1 0

Re: [GEM-dev] Re: GEM shader usage
by james tittle 07 Dec '05

07 Dec '05

hey ben, ...bringing this back: On Oct 20, 2005, at 6:23 AM, B. Bogart wrote: > Indeed it seems entry is broken on .39, I'm still using .38 > > Anyone feel free to take a look and see whats up, as I'll probably not > have time to look at it any time soon. I guess something in gcanvas > is not > working as in 38... ...grrr, turns out I can't get it to behave with pd-extended-RC5, which is 0.38-4...so any idea which pd it last worked on? When hitting bang, I get "unmatched open quote in list"...also, does this mean it just outputs the text as a list of symbols? james

5 10

render chains: positive vs. negative differences
by james tittle 06 Dec '05

06 Dec '05

...I've come across a stumbling block on the road to gem shader nirvana, and I'm not sure why it's happening ;-\ ...here's what's happening: the "positive" render chains are rendered after the perspective and view have been changed in the gemwin, but "negative" render chains are always locked to the default values for some reason? It seems to me that they should also receive the perspective and view messages in the same way the positive render chains do... ...Is there something here I'm not seeing? james

2 2

Offscreen naming poll!
by james tittle 03 Dec '05

03 Dec '05

hey, ...this weekend I wrote an object that allows offscreen rendering (or "render-to-texture") on a per renderchain basis, using framebuffer objects (FBO's, GL_EXT_framebuffer_object): it is really useful for playing with multiple rendering passes and shaders...I'd like to commit it, but it occurred to me that it might be good to see what we should name it, and where it should go in the folder hierarchy? Currently it's named [gemframebuffer], but really I think [gemoffscreen] would be better, since it could be implemented using pbuffers instead of FBO's, which would allow for some backward's compatibility (I think)...? ...also, on my harddrive I put it in src/controls (it would be inserted into a gemchain after [gemhead]), but I guess it could also go in src/manips, or even src/Nongeos? ...to give a bit more overview, it works by setting up color/depth/ stencil rgb or float buffer(s) that you can render into, and basically it get's enabled at the start of render() and disabled in the postrender() call...the buffer is also bound to a texture ID, which can then be used in later gemchains (currently via [pix_multitexture]), where it currently requires using the glwrappers to make a geo to display on: I'd like to fix this so that there's an easier way to pass textures around based on their ID's: any ideas? Unless there's a way to determine width/height from a given texture ID, I think that dimension data will also have to be passed... james

4 11

building pix_videoDS
by chris clepper 03 Dec '05

03 Dec '05

I have built GEM 0.90 wihtout pix_videoDS and am now trying CVS to see if it will work. This is the errorr I get during linking and have very little idea what it means. DSgrabber.obj : error LNK2019: unresolved external symbol "long __stdcall ATL::AtlWinModuleInit(struct ATL::_ATL_WIN_MODULE70 *)" (?AtlWinModuleInit@ATL@@YGJPAU_ATL_WIN_MODULE70@1@@Z) referenced in function "public: __thiscall ATL::CAtlWinModule::CAtlWinModule(void)" (??0CAtlWinModule@ATL@@QAE@XZ) pix_videoDS.obj : error LNK2001: unresolved external symbol "long __stdcall ATL::AtlWinModuleInit(struct ATL::_ATL_WIN_MODULE70 *)" (?AtlWinModuleInit@ATL@@YGJPAU_ATL_WIN_MODULE70@1@@Z) DSgrabber.obj : error LNK2001: unresolved external symbol "class ATL::CAtlBaseModule ATL::_AtlBaseModule" (?_AtlBaseModule@ATL@@ 3VCAtlBaseModule@1@A) pix_videoDS.obj : error LNK2001: unresolved external symbol "class ATL::CAtlBaseModule ATL::_AtlBaseModule" (?_AtlBaseModule@ATL@@ 3VCAtlBaseModule@1@A) ../Gem.dll : fatal error LNK1120: 2 unresolved externals I built the DirectShow Sample stuff (which is now no longer part of DirectX SDK?!?) and I'm using VS Pro 2003 which is quite painful. Any clues?

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev December 2005