As the recent requests indicate, it's probably about time for some updated binaries for Windows and OSX. Jamie will be in Chicago later this week which might be a good time to wrap up the OSX end.
I have been working on parts of the Windows code and have a few bug fixes and features added (mainly QT stuff). The main lack of functionality on Windows is the shader code. I tried GLEW but the resultant binary always crashes during window creation. I think it might require more reworking of the windows code than just replacing a few of the includes, so my question is whether we try to move to GLEW with Windows (and also Mac and Linux?) or just hack in the calls for ARB_fragment/vertex/etc and go?
cgc
On Jan 17, 2006, at 2:50 PM, chris clepper wrote:
As the recent requests indicate, it's probably about time for some updated binaries for Windows and OSX. Jamie will be in Chicago later this week which might be a good time to wrap up the OSX end.
I have been working on parts of the Windows code and have a few bug fixes and features added (mainly QT stuff). The main lack of functionality on Windows is the shader code. I tried GLEW but the resultant binary always crashes during window creation. I think it might require more reworking of the windows code than just replacing a few of the includes, so my question is whether we try to move to GLEW with Windows (and also Mac and Linux?) or just hack in the calls for ARB_fragment/vertex/etc and go?
...incorporating GLEW across the board while we're in the same room sounds like a good goal, especially since it dovetails with my gl clean-up of late...
james
Just to follow up on this, I have a GLEW version for WIndows, but it requires more code changes to make it work right. My thoughts are to put together a release before all the GLEWing just to have a more recent version than 0.90 available.
New/fixed items :
- separator memory leak looks fixed as long as the separator comes after the texturing objects - pix_coordinate bug appears fixed by IOhannes - I have gotten Quicktime not to crash when loading clips on Windows, but this introduced a small leak - pix_record is working on OSX and Windows - pix_film pause/play is better on OSX when using the auto setting - playback of production HiDef codecs is improved on OSX - ARB_fragment/vertex support on OSX
There are probably other items, but it looks like the added functionality and stability is worth a 'maintenance' release for these two platforms. Or do we want to wait for GLEW on all three platforms for a release?
cgc
chris clepper wrote:
New/fixed items :
- pix_record is working on OSX and Windows
damned, that should be working on all platforms (i should do that)
- ARB_fragment/vertex support on OSX
and linux!
There are probably other items, but it looks like the added functionality and stability is worth a 'maintenance' release for these two platforms. Or do we want to wait for GLEW on all three platforms for a release?
i would suggest to make a release before the glewifying. (which reminds me of all the unfinished work: vertex, model-loader, multiple-windows,... - but still we should release asap)
mfg.dr. IOhannes
IOhannes m zmoelnig wrote:
chris clepper wrote:
- pix_record is working on OSX and Windows
damned, that should be working on all platforms (i should do that)
just because i am currently looking into how to integrate [pix_record] for linux: could we please find a common way of how such highly platform dependent objects should be done in the future? it should have been fairly easy to build [pix_record] using a mechanism like in [pix_film](NEW), [pix_movie](NEW) and [pix_video](NEW).
the basic idea is to split the code into 2 parts: A is to interface pd, B is to interface the library-API.
this way we can have one object support multiple APIs _and_ have clean code in the implementations of all APIs.
the way [pix_film] used to handle this was fooling pd by having different (os-specific) objects (in different files) that share the same class name. i think this is awful. the other possibility is having a nightmare of ifdefs within one single file. this is even worse.
if you have strong objections, we can discuss it here. it would be really nice if we could find a common agreement on that in order to not frustrate the other ones....
mfg.a.dsr IOhannes
On Feb 2, 2006, at 3:18 PM, chris clepper wrote:
Just to follow up on this, I have a GLEW version for WIndows, but it requires more code changes to make it work right. My thoughts are to put together a release before all the GLEWing just to have a more recent version than 0.90 available.
New/fixed items :
- separator memory leak looks fixed as long as the separator comes
after the texturing objects
- pix_coordinate bug appears fixed by IOhannes
- I have gotten Quicktime not to crash when loading clips on
Windows, but this introduced a small leak
- pix_record is working on OSX and Windows
- pix_film pause/play is better on OSX when using the auto setting
- playback of production HiDef codecs is improved on OSX
- ARB_fragment/vertex support on OSX
...and then also off the top of my head:
- GLSL shader support - VBO support - FBO support - any number of new pix objects: freeframe, fid*, vpaint - pqtorusknots - multitexture support (kinda) - loads of new gl wrappers - fix for HaveValidContext() hack on osx - better glError detection, especially useful when working with glWrappers - etc.
...it'd be better to go thru the ChangeLog, which I'll run cvs2cl today and see where we are...
There are probably other items, but it looks like the added functionality and stability is worth a 'maintenance' release for these two platforms. Or do we want to wait for GLEW on all three platforms for a release?
...I agree we should do a release of some sort (it's been what, almost 2 years?) before GLEW-ifying, if only because that touches every file...IOhannes also mentions vertex_array, model_loader, and multiple_window improvements that aren't quite there for wide distribution: I say we look at what's in cvs now, make sure it works on all platforms (somewhat: multitexture/FBO needs love, and I'm not sure freeframe is 100% on osx yet)...
...can we get it done for valentine's day?
jamie
james tittle wrote:
...can we get it done for valentine's day?
yes, i think that is a goal.
apart from that: i have no made a version of [pix_record] that (kind of) works on linux. for this i have split the functionality (as described in previous mail). while i tried to keep chris' QT-code intact, i am pretty sure it will not work out of the box now that it is in recordQT.{cpp,h}
should i just commit it to the CVS? (don't know why i dont't just do it :-))
mfg,a,d IOhannes
On Feb 3, 2006, at 10:54 AM, IOhannes m zmoelnig wrote:
apart from that: i have no made a version of [pix_record] that (kind of) works on linux. for this i have split the functionality (as described in previous mail). while i tried to keep chris' QT-code intact, i am pretty sure it will not work out of the box now that it is in recordQT. {cpp,h}
should i just commit it to the CVS? (don't know why i dont't just do it :-))
...yeh, just commit it and we can work on it from this end...perhaps this is a good moment to admit that while I have understood the need for splitting things up like this, I have been lazy and actually not been using the pix_*NEW code! :-\ So I guess now is the time to transition the osx side to it...
...then we'll all be on the same page...
jamie
james tittle wrote:
On Feb 3, 2006, at 10:54 AM, IOhannes m zmoelnig wrote:
...yeh, just commit it and we can work on it from this end...perhaps this is a good moment to admit that while I have understood the need for splitting things up like this, I have been lazy and actually not been using the pix_*NEW code! :-\ So I guess now is the time to transition the osx side to it...
yes it would be great. i mean i understand that after both of you have put a lot of efforts into pix_filmDarwin you are not easily willing to change everything in there. however, pix_record is quite new and it would have been the same amount of coding (at the beginning)
but better late than never...
mfg.acad-vre IOhannes