From jan.dvorak at kraxnet.cz Mon Feb 12 20:43:04 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Tue, 13 Feb 2007 02:43:04 +0100 Subject: [ruby-opengl-devel] Project status Message-ID: <200702130243.04888.jan.dvorak@kraxnet.cz> Hello, what is the current status of the projects ? I'm asking because the docs says that the development stalled, and i have few ideas i'd like to implement. Jan From hoanga at alum.rpi.edu Mon Feb 12 21:20:07 2007 From: hoanga at alum.rpi.edu (Al Hoang) Date: Tue, 13 Feb 2007 11:20:07 +0900 Subject: [ruby-opengl-devel] Project status In-Reply-To: <200702130243.04888.jan.dvorak@kraxnet.cz> References: <200702130243.04888.jan.dvorak@kraxnet.cz> Message-ID: <20070213022007.GW11009@samsara.bebear.net> On Tue, Feb 13, 2007 at 02:43:04AM +0100, Jan Dvorak wrote: > Hello, > > what is the current status of the projects ? I'm asking because the docs says > that the development stalled, and i have few ideas i'd like to implement. > Actually, that needs to be updated. The development status is no longer stalled due to mkrf as a new release of mkrf fixes those problems. The next step was for me to kick off a release as is but I needed to clean up the Rakefiles so that it will cleanly generate a gem. Once the build system gets clean, I think development can really start plodding forward again. I'd happily accept patches for anything you're thinking of implementing. What were your ideas? Cheers, Alain From jan.dvorak at kraxnet.cz Tue Feb 13 20:52:16 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Wed, 14 Feb 2007 02:52:16 +0100 Subject: [ruby-opengl-devel] Project status In-Reply-To: <20070213022007.GW11009@samsara.bebear.net> References: <200702130243.04888.jan.dvorak@kraxnet.cz> <20070213022007.GW11009@samsara.bebear.net> Message-ID: <200702140252.16439.jan.dvorak@kraxnet.cz> On Tuesday 13 February 2007 03:20, Al Hoang wrote: > Actually, that needs to be updated. The development status is no > longer stalled due to mkrf as a new release of mkrf fixes those problems. > The next step was for me to kick off a release as is but I needed to clean > up the Rakefiles so that it will cleanly generate a gem. Once the build > system gets clean, I think development can really start plodding forward > again. Thats good to hear. > I'd happily accept patches for anything you're thinking of > implementing. What were your ideas? I was thinking about best way to continue development to get full OpenGL 2.1 support, along with most extensions (although considering their number, this is more of wishfull thinking). Currently in the bindings there is good support for 1.0,1.1 and some functions from 1.2 version; the system is static, what functions are included in ruby bindings depends on what GL headers are installed on the system at compile-time - which isn't good, as on 90% or so systems the headers version doesn't match what is actually supported in drivers. (This is most prevalent on windows, where there are only GL 1.1 or 1.2 headers included in most compilers/IDEs). And even if they match, it still means recompiling the bindings each time new graphics drivers are installed should you want to use the additional capabilities. My suggestion is to dynamically load functions of versions 1.2+ (taking version 1.1 as lowest common denominator, as it is available on windows 98). The way wrapper functions are written won't change much: [pseudocode] void (*glFunction)(int,int) = NULL; // define function pointer prototype ... static VALUE gl_Function(.... { ... if (glFunction==NULL) { // can be macroized glFunction = our_dyn_load_func("glFunction"); // which will call glXGetProcAddress on unix, // wglGetProcAddress on windows or // dlsym/dyndl functions on mac // if fail, raises "Function not available" or "OPenGL context not set" } ... rest of function as usual } [/pseudocode] The function address will get loaded on first use of the function, so there is no initliazation overhead for scripts which doesn't use any it. Once loaded, only one "if" is executed on each function call, so this should also not be problem performance-wise. There should also be ruby function mapped directly to our_dyn_load_func, which will allow the user to check if specific function is available in runtime. Of course, the implementation is the easy part (it can be built slowly, version after version - there is not that much functions), the real problem is testing. Most of OpenGL functions cannot be tested automatically, the tests needs to be interactive. I guess we don't need to write individual test for each function, we can test multiple functions of the same subset at once - i was thinking about screen displaying some stuff and describing text like "you should see three rows of red, green and blue quads, press Y/N". (Because OpenGL doesn't really change, and the wrapper functions are standalone, not dependent on others, these tests should fortunatelly be executed by developer only if someone changes the code of function in question.) As for GLU, it doesn't have means for dynamic function loading as it usually isn't part of the drivers. Latest revision is 1.3, with previous version 1.2 being distributed along OpenGL 1.1 (which as i wrote can be taken for granted) so it is only small number of functions which availability would depend on compile-time. The good thing is, all of GLU functions are higher-level stuff, using only other GL functions, meaning that if really needed, they can be (re)implemented even in Ruby itself without need for C code or wrapper. As for Glut, the situation is the mostly the same as with GLU. It's more complicated as there are both higher level and core functions interfacing with the GUI API (glX/wgl etc.) which needs to be implemented. As the original Glut is not developed anymore, there are also many spinoffs (freeglut..), with different functions and extensions. Fortunatelly, the core functions didn't really change from 1994 or such (so we can safely assume all are available at compile time), and the rest is also mostly higher-level functions as with GLU. Now, i didn't really read the list archives, so if any of this was already discussed please point me to the relevant threads. Any comments are of course welcome. Regardless of any of this, i already started implementing the few 1.0 and 1.1 functions that are currently missing from the bindings, and i'll put the code on my ftp when i'll check everything is working ok (i can also provide patches if needed). Jan From jan.dvorak at kraxnet.cz Sun Feb 18 23:35:03 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Mon, 19 Feb 2007 05:35:03 +0100 Subject: [ruby-opengl-devel] Project status In-Reply-To: <200702140252.16439.jan.dvorak@kraxnet.cz> References: <200702130243.04888.jan.dvorak@kraxnet.cz> <20070213022007.GW11009@samsara.bebear.net> <200702140252.16439.jan.dvorak@kraxnet.cz> Message-ID: <200702190535.03529.jan.dvorak@kraxnet.cz> On Wednesday 14 February 2007 02:52, Jan Dvorak wrote: > Regardless of any of this, i already started implementing the few 1.0 and > 1.1 functions that are currently missing from the bindings, and i'll put > the code on my ftp when i'll check everything is working ok (i can also > provide patches if needed). Sorry for the delay, here it is: http://www.gleamless.org/tmp/ruby-opengl-update.tar.gz - just the changed files http://www.gleamless.org/tmp/ruby-opengl.patch.gz - patch against last SVN http://www.gleamless.org/tmp/funclist.txt - list of functions added filelist: ext/common/rbogl.[c,h] - i've added more helper functions for other GL types ext/common/gl-enums.h - these are all OpenGL enums, (so we don't have to depend on what is specified in user's gl.h), including extensions generated from enum registry http://www.opengl.org/registry/api/enum.spec and http://www.opengl.org/registry/api/enumext.spec for internal use by C code (all modules) ext/gl/gl-enums.c - all the enums as above, defined as ruby constants ext/gl/gl-1.0-1.1.c - most code copy-pasted from original gl.c, added functions as per OpenGL 2.1 spec. The only function not supported form is glGetTexImage, while it's base functionality is trivial to implement, the allocated size needed for return buffer is subject to all pixel packing settings - the code i've tried was long and didn't give proper results in all cases, so i postponed it for now. Also, glGetPointerv doesn't support returning pointers to selection and feedback buffers, for obvious reasons. Other than that, OpenGL 1.0 and 1.1 support should be complete. I've fixed some minor things in the already present functions (some missing sanity checks, added v1.3+ enums to switch statements etc.). ext/gl/gl.c - this is gateway to calling specific initializations in gl-XXX files ext/gl/gl-1.2.c - contains the opengl 1.2 functions that were implemented in svn (copy-pasted only), for now, commented out, as i still didn't get reply for my previous email (the dynamic loading thing). ext/glu/glu.c - changed call to ary2* as the name changed in rbogl.c/h, also renamed init function to Init_glu, as the former initialize didn't work in SVN. I've tried to match the existing coding style (whether this is good i'll leave to you to judge :) ). As always, any comments are welcome. Jan From sean.m.long at gmail.com Mon Feb 19 14:20:15 2007 From: sean.m.long at gmail.com (Sean Long) Date: Mon, 19 Feb 2007 11:20:15 -0800 Subject: [ruby-opengl-devel] Mac OS X Fixes Message-ID: I made some fixes to the mkrf_conf files so the library will compile correctly on OS X. I also moved the functionality of build.sh into the Rakefile and made it work correctly on OS X, so build.sh can be removed. I am including a single patch with the changes. The changes were tested on 2 different Macs one PPC and one Intel both running 10.4.8. Also used the mkrf 0.2.0 gem. Thanks for doing this project so I did not have to start my own :) Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: ruby_opengl_diff.patch Type: application/octet-stream Size: 3539 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070219/bcc1f6ff/attachment.obj From hoanga at alum.rpi.edu Mon Feb 19 21:08:19 2007 From: hoanga at alum.rpi.edu (Al Hoang) Date: Tue, 20 Feb 2007 11:08:19 +0900 Subject: [ruby-opengl-devel] Project status In-Reply-To: <200702190535.03529.jan.dvorak@kraxnet.cz> References: <200702130243.04888.jan.dvorak@kraxnet.cz> <20070213022007.GW11009@samsara.bebear.net> <200702140252.16439.jan.dvorak@kraxnet.cz> <200702190535.03529.jan.dvorak@kraxnet.cz> Message-ID: <20070220020819.GF11009@samsara.bebear.net> On Mon, Feb 19, 2007 at 05:35:03AM +0100, Jan Dvorak wrote: > On Wednesday 14 February 2007 02:52, Jan Dvorak wrote: > > Regardless of any of this, i already started implementing the few 1.0 and > > 1.1 functions that are currently missing from the bindings, and i'll put > > the code on my ftp when i'll check everything is working ok (i can also > > provide patches if needed). > Sorry for the delay, here it is: This is excellent! I've been sick in bed for the past few days so haven't had much energy to do much besides look at the ceiling. I've looked at the patches and it doesn't look like it intereferes with anything currently so I'm going to commit it into the svn trunk if you don't mind. I've made some more changes in the Rakefile so I'm HOPING all that is required for getting ruby-open to compile properly (at least on Linux and OS X boxes) is: 1. Install gems 2. Install mkrf (>= 0.20) 'gem install -y mkrf' 3. Run 'rake' in the top level directory 4. Run 'rake gem' to build the gem 5. 'gem install pkg/ruby-opengl-blahblah.gem' Unfortunately, I'm still trying to understand if it's possible for the gem mechanism to build multiple extensions if they are properly structured however from what I've seen I'm not having much luck in finding this information but hopefully the procedure for building is a little bit more lightweight than the previous ones. > > I've tried to match the existing coding style (whether this is good i'll leave > to you to judge :) ). As always, any comments are welcome. This is inherited code for me too so I guess we can always change around the style if it's that annoying. Cheers, Alain From hoanga at alum.rpi.edu Mon Feb 19 22:55:13 2007 From: hoanga at alum.rpi.edu (Al Hoang) Date: Tue, 20 Feb 2007 12:55:13 +0900 Subject: [ruby-opengl-devel] Project status In-Reply-To: <200702140252.16439.jan.dvorak@kraxnet.cz> References: <200702130243.04888.jan.dvorak@kraxnet.cz> <20070213022007.GW11009@samsara.bebear.net> <200702140252.16439.jan.dvorak@kraxnet.cz> Message-ID: <20070220035513.GH11009@samsara.bebear.net> Hi Jan, Sorry for the extremely slow response on this message. I've been meaning to respond to this message for awhile now but wanted to make sure I fully digest what you said :-) On Wed, Feb 14, 2007 at 02:52:16AM +0100, Jan Dvorak wrote: > I was thinking about best way to continue development to get full OpenGL 2.1 > support, along with most extensions (although considering their number, this > is more of wishfull thinking). Currently in the bindings there is good Better support for more recent releases of OpenGL sounds great. I had a much lower goal of just making sure that 1.0, 1.1 support was solid and seeing what to do from there but you seem to have a much clearer idea on how to shoot for more recent support without busting what is there. I'm all for this. > support for 1.0,1.1 and some functions from 1.2 version; the system is > static, what functions are included in ruby bindings depends on what GL > headers are installed on the system at compile-time - which isn't good, as on > 90% or so systems the headers version doesn't match what is actually > supported in drivers. (This is most prevalent on windows, where there are Interesting. This is something I didn't consider at all but something definitely that makes sense. Well putting in this support now is good although at the current moment, ruby-opengl doesn't do much to build anything on win32 at the moment. I'd really like to have this fixed but mkrf itself doesn't seem to support building on win32 except perhaps via cygwin so most likely changes to mkrf will have to be made to support this. > My suggestion is to dynamically load functions of versions 1.2+ (taking version > 1.1 as lowest common denominator, as it is available on windows 98). The way > wrapper functions are written won't change much: This sounds perfectly fine. In fact it's probably already in the svn trunk since I committed your patch a couple of hours ago. > version after version - there is not that much functions), the real problem > is testing. Most of OpenGL functions cannot be tested automatically, the I was afraid of this. I have been agonizing trying to think of a way to automate testing OpenGL but it just doesn't seem possible. The best that could be done is test whether calling to a certain OpenGL function will return an error or not but even that sounds iffy. > tests needs to be interactive. I guess we don't need to write individual test > for each function, we can test multiple functions of the same subset at > once - i was thinking about screen displaying some stuff and describing text > like "you should see three rows of red, green and blue quads, press Y/N". This sounds fine. I actually think what would be handy is to have a small thumbnail picture that should resemble or be a smaller rendition of what the user should expect to see. If the files aren't that large we can stuff them in the test directory under the same name as the test itself for easier identification. > depend on compile-time. The good thing is, all of GLU functions are > higher-level stuff, using only other GL functions, meaning that if really > needed, they can be (re)implemented even in Ruby itself without need for C > code or wrapper. This might not be a bad idea at all or perhaps we can try to take advantage of Ruby's DL library to bind to the GLU library dynamically. > > As for Glut, the situation is the mostly the same as with GLU. It's more > complicated as there are both higher level and core functions interfacing > with the GUI API (glX/wgl etc.) which needs to be implemented. As the > original Glut is not developed anymore, there are also many spinoffs > (freeglut..), with different functions and extensions. Fortunatelly, the core > functions didn't really change from 1994 or such (so we can safely assume all > are available at compile time), and the rest is also mostly higher-level > functions as with GLU. Perhaps, GLUT could just stay the way it is in ruby-opengl as I'd imagine people would move onto some other windowing toolkit if they wanted more features than what the current basic GLUT interface can provide. Alain From hoanga at alum.rpi.edu Tue Feb 20 03:37:59 2007 From: hoanga at alum.rpi.edu (Al Hoang) Date: Tue, 20 Feb 2007 17:37:59 +0900 Subject: [ruby-opengl-devel] Mac OS X Fixes In-Reply-To: References: Message-ID: <20070220083759.GI11009@samsara.bebear.net> Hi Sean, On Mon, Feb 19, 2007 at 11:20:15AM -0800, Sean Long wrote: > I made some fixes to the mkrf_conf files so the library will compile > correctly on OS X. I also moved the functionality of build.sh into the > Rakefile and made it work correctly on OS X, so build.sh can be > removed. Thanks for testing this on OS X and reporting back the results and an even bigger thanks for a patch. > > I am including a single patch with the changes. > > The changes were tested on 2 different Macs one PPC and one Intel both > running 10.4.8. > Also used the mkrf 0.2.0 gem. Great! I looked through the patch and noticed that I already made a bunch of changes to the Rakefile to use the built-in mkrf tasks better for building the plugins which is incompatible with your patch I'm afraid however I've incorported the other changes to the mkrf_conf.rb files and have commited these into svn. It seems the latest patches from Jan also triggered another bug in OS X but a quick fix to rbogl.h for the rb2cint definition fixed this. If you get a chance, please try the latest SVN revision and see if this builds alright for you. # Install mkrf if not already installed 1. gem install -y mkrf 2. Run 'rake' at the top level 3. Run 'rake gem' to build a gem 4. Run 'gem install pkg/*.gem' to install the built gem 5. Run 'ruby -rubygems examples/plane.rb' and see if you get a nice picture > > Thanks for doing this project so I did not have to start my own :) I'm just the steward carrying it on. I think the originators too ;) Thanks, Alain From sean.m.long at gmail.com Tue Feb 20 10:56:03 2007 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 20 Feb 2007 07:56:03 -0800 Subject: [ruby-opengl-devel] Mac OS X Fixes In-Reply-To: <20070220083759.GI11009@samsara.bebear.net> References: <20070220083759.GI11009@samsara.bebear.net> Message-ID: I followed the instructions you gave and it worked perfectly. Thanks Sean > # Install mkrf if not already installed > 1. gem install -y mkrf > 2. Run 'rake' at the top level > 3. Run 'rake gem' to build a gem > 4. Run 'gem install pkg/*.gem' to install the built gem > 5. Run 'ruby -rubygems examples/plane.rb' and see if you get a > nice picture From jan.dvorak at kraxnet.cz Tue Feb 20 23:17:45 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Wed, 21 Feb 2007 05:17:45 +0100 Subject: [ruby-opengl-devel] Project status In-Reply-To: <20070220035513.GH11009@samsara.bebear.net> References: <200702130243.04888.jan.dvorak@kraxnet.cz> <200702140252.16439.jan.dvorak@kraxnet.cz> <20070220035513.GH11009@samsara.bebear.net> Message-ID: <200702210517.45876.jan.dvorak@kraxnet.cz> On Tuesday 20 February 2007 04:55, Al Hoang wrote: > Interesting. This is something I didn't consider at all but something > definitely that makes sense. Well putting in this support now is good > although at the current moment, ruby-opengl doesn't do much to build > anything on win32 at the moment. I'd really like to have this fixed but > mkrf itself doesn't seem to support building on win32 except perhaps > via cygwin so most likely changes to mkrf will have to be made to support > this. I don't think that is that much of an issue. The code itself compiles on win32 cleanly. Now, i'm newcomer to ruby, but i have some idea about the distribution system, as well about the problems with compiling extensions on windows. I've seen that most ruby extensions on win simply distribute binaries (either as .exe installer or as binary .gem). We don't use any external libraries (apart from glu/glut) or API, so i guess we can simply have one-size-fits-all binary and distribute it as gem, and also (when it's complete and tested) ask the ruby-lang guys to include it into the windows one-click installer (which happens to currently include the original Yoshi bindings). > This sounds perfectly fine. In fact it's probably already in the svn > trunk since I committed your patch a couple of hours ago. I didn't include it in the patch just to be on the safe side. Also i have to yet test it on MacOSX (currently trying to install it into emulator :) ). There's also the issue that MacOSX 10.3+ uses different dynamic loading functionality (POSIX-like dlopen) then older versions - how much are versions <10.3 prevalent on the market ? I ask for whether we should support both interfaces, or just stick with the modern one for this. Of course even in that case, users of older MacOSX version will still be able to use 1.0/1.1 functionality (which is the whole functionality of the bindings as of now :) ). > This sounds fine. I actually think what would be handy is to have > a small thumbnail picture that should resemble or be a smaller rendition > of what the user should expect to see. If the files aren't that large > we can stuff them in the test directory under the same name as the test > itself for easier identification. Thats good idea. > This might not be a bad idea at all or perhaps we can try to take > advantage of Ruby's DL library to bind to the GLU library dynamically. Also good idea, i wasn't aware of this. > Perhaps, GLUT could just stay the way it is in ruby-opengl as I'd > imagine people would move onto some other windowing toolkit if they wanted > more features than what the current basic GLUT interface can provide. I'd say you're right, although there aren't exactly that many windowing toolkits available to ruby capable of creating GL context for now. Anyway, i know that there are one or two functions missing from Glut core functionality (like leaving fullscreen mode), but i haven't yet time to really look at what other stuff is missing. Jan From hoanga at alum.rpi.edu Wed Feb 21 00:49:33 2007 From: hoanga at alum.rpi.edu (Al Hoang) Date: Wed, 21 Feb 2007 14:49:33 +0900 Subject: [ruby-opengl-devel] Release 0.33.0 of ruby-opengl Message-ID: <20070221054933.GL11009@samsara.bebear.net> Hi all, I'm happy to announce the first release of ruby-opengl since its inception. I'm calling this version 0.33.0 in tradition of following the original author's (Yoshi) numbering scheme. Now that I've finally figured out how to get the gem to properly build the C-bindings on gem installation time I think this makes it much easier for people to try out ruby-opengl and delete it if it does not suit their purposes. I've currently tested the gem install on the following platforms: * Ubuntu Linux 6.06 64-bit edition * Mac OS X 10.4.8 PPC with Darwinports installed version of Ruby Please try it out and let me know if you're having any problems or if you wish to just mention what OS you installed it on. At present there is NO Windows gem available however I hope to iron that out as soon as I figure out how. Cheers, Alain From sean.m.long at gmail.com Wed Feb 21 02:33:37 2007 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 20 Feb 2007 23:33:37 -0800 Subject: [ruby-opengl-devel] Project status In-Reply-To: <200702210517.45876.jan.dvorak@kraxnet.cz> References: <200702130243.04888.jan.dvorak@kraxnet.cz> <200702140252.16439.jan.dvorak@kraxnet.cz> <20070220035513.GH11009@samsara.bebear.net> <200702210517.45876.jan.dvorak@kraxnet.cz> Message-ID: > I'd say you're right, although there aren't exactly that many windowing > toolkits available to ruby capable of creating GL context for now. I initially got interested in this project because I want to get OpenGL to work on WxRuby (which I am one of the developers), so in the not so distant future WxRuby may fill this roll. Sean From jan.dvorak at kraxnet.cz Fri Feb 23 14:51:25 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Fri, 23 Feb 2007 20:51:25 +0100 Subject: [ruby-opengl-devel] dynamic loading + fixes Message-ID: <200702232051.25300.jan.dvorak@kraxnet.cz> Hello, here's another patch: - dynamic loading of opengl functions above 1.1, should work on linux, mac os X 10.1+, windows, and all systems using GLX in general. - re-added the four 1.2 functions from original code - glDrawRangeElements, glTexImage3D, glTexSubImage3D, glCopyTexSubImage3D - some fixes to the 1.0/1.1 funcs - glGetTexImage implemented - glGetPointerv now returns also feedback and selection buffers As for near future i'm planing implementing the rest of the 1.2 functions, writing some more documentation about using the bindings (differences between C and ruby usage), and also writing some tests to ensure everything's working before implementing 1.3 and beyond. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: dl+fixes.patch Type: text/x-diff Size: 20749 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070223/f1a28833/attachment.bin From jan.dvorak at kraxnet.cz Sun Feb 25 09:20:49 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Sun, 25 Feb 2007 15:20:49 +0100 Subject: [ruby-opengl-devel] dynamic loading + fixes In-Reply-To: <200702232051.25300.jan.dvorak@kraxnet.cz> References: <200702232051.25300.jan.dvorak@kraxnet.cz> Message-ID: <200702251520.49891.jan.dvorak@kraxnet.cz> On Friday 23 February 2007 20:51, Jan Dvorak wrote: > As for near future i'm planing implementing the rest of the 1.2 functions, And here is follow-up patch, that implements the rest of 1.2 functions - glBlendColor,glBlendEquation,glColorTable,glColorTableParameterfv,glColorTableParameteriv, glCopyColorTable,glGetColorTable,glGetColorTableParameterfv,glGetColorTableParameteriv, glColorSubTable,glCopyColorSubTable,glConvolutionFilter1D,glConvolutionFilter2D, glConvolutionParameterf,glConvolutionParameterfv,glConvolutionParameteri, glConvolutionParameteriv,glCopyConvolutionFilter1D,glCopyConvolutionFilter2D, glGetConvolutionFilter,glGetConvolutionParameterfv,glGetConvolutionParameteriv, glGetSeparableFilter,glSeparableFilter2D,glGetHistogram,glGetHistogramParameterfv, glGetHistogramParameteriv,glGetMinmax,glGetMinmaxParameterfv,glGetMinmaxParameteriv, glHistogram,glMinmax,glResetHistogram,glResetMinmax Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.2.patch Type: text/x-diff Size: 27648 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070225/3954c2f6/attachment-0001.bin From jan.dvorak at kraxnet.cz Sun Feb 25 20:05:23 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Mon, 26 Feb 2007 02:05:23 +0100 Subject: [ruby-opengl-devel] dynamic loading + fixes In-Reply-To: <200702251520.49891.jan.dvorak@kraxnet.cz> References: <200702232051.25300.jan.dvorak@kraxnet.cz> <200702251520.49891.jan.dvorak@kraxnet.cz> Message-ID: <200702260205.23255.jan.dvorak@kraxnet.cz> On Sunday 25 February 2007 15:20, Jan Dvorak wrote: > And here is follow-up patch, that implements the rest of 1.2 functions - And another followup - this patch adds all GL 1.3 functionality (for list of functions, view the patch). As everything is proceeding faster than i expected, i've changed my mind about priorities - i'll go for implementing all OpenGL base functionality up to and including 2.1, postponing writing tests to after that (as there is very good chace that 90%+ of stuff will work out-of-box without any need for prooftesting due to their simplicity - at least for now). Note that the patch are meant to be added incrementaly as i'm posting them, but if needed can be probably bent to apply independently. As always, any comments are welcome :) Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.3.patch Type: text/x-diff Size: 22798 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070226/9b0d558e/attachment.bin From jan.dvorak at kraxnet.cz Mon Feb 26 17:46:16 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Mon, 26 Feb 2007 23:46:16 +0100 Subject: [ruby-opengl-devel] dynamic loading + fixes In-Reply-To: <200702260205.23255.jan.dvorak@kraxnet.cz> References: <200702232051.25300.jan.dvorak@kraxnet.cz> <200702251520.49891.jan.dvorak@kraxnet.cz> <200702260205.23255.jan.dvorak@kraxnet.cz> Message-ID: <200702262346.16321.jan.dvorak@kraxnet.cz> Here's all of 1.4 functionality. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.4.patch Type: text/x-diff Size: 19090 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070226/84409c6e/attachment-0001.bin From jan.dvorak at kraxnet.cz Mon Feb 26 18:56:38 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Tue, 27 Feb 2007 00:56:38 +0100 Subject: [ruby-opengl-devel] dynamic loading + fixes In-Reply-To: <200702260205.23255.jan.dvorak@kraxnet.cz> References: <200702232051.25300.jan.dvorak@kraxnet.cz> <200702251520.49891.jan.dvorak@kraxnet.cz> <200702260205.23255.jan.dvorak@kraxnet.cz> Message-ID: <200702270056.38943.jan.dvorak@kraxnet.cz> Sorry, the previous 1.4 patch contained typo, here is fixed one. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.4-fixed.patch Type: text/x-diff Size: 19089 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070227/dd728230/attachment.bin From jan.dvorak at kraxnet.cz Tue Feb 27 17:30:35 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Tue, 27 Feb 2007 23:30:35 +0100 Subject: [ruby-opengl-devel] dynamic loading + fixes In-Reply-To: <200702270056.38943.jan.dvorak@kraxnet.cz> References: <200702232051.25300.jan.dvorak@kraxnet.cz> <200702260205.23255.jan.dvorak@kraxnet.cz> <200702270056.38943.jan.dvorak@kraxnet.cz> Message-ID: <200702272330.35993.jan.dvorak@kraxnet.cz> And following up, with 1.5 functionality. The VBO (vertex buffer object) mapping is read-only, as glMapBuffer returns pointer to driver memory which should be directly modified by client program, which can't be elegantly done in Ruby - so Gl.glMapBuffer makes copy of the memory chunk and returns it as classical string. (Users still have to call Gl.glUnmapBuffer afterwards. ). For this reason, Gl.glGetBufferPointerv also returns 'nil' regardless of whatever is mapped. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.5.patch Type: text/x-diff Size: 10607 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070227/3528468a/attachment-0001.bin