Understanding NBOpenGL
Locked
1234
1234
 
|
Ok so I tried to learn Opengl ES 2 (and opengl 4) during my eastern vacations because I realised
that I dont really need Athens or vector graphics for my GUI , since I will be dealing mostly with 3d graphics anyway. (My project "ephestos" will be an effort of creating a 3d app for pharo, see also "blender") So when I tried to run the demos i get an error with NBMacGLContextDriver>>supportsCurrentPlatform "obviously, for Mac intel-32 only :)" ^ NativeBoost platformId = NativeBoostConstants mac32PlaformId My mac is "obviously" not 32-bit but 64 bit, but I dont know if that matters since pharo is only 32 bit anyway. The bug is also obvious it should be mac32PlatformId and not mac32PlaformId. I correct and proceed and gives me a new error this time in NBMacGlApi>>glApiCall: fnSpec index: fnIndex attributes: attributes context: contextToRetry ^[ (NBCallFailureHandler for: contextToRetry) retryWith: [ :targetClass :targetMethod | (NBFFICallout targetClass: targetClass targetMethod: targetMethod fnSpec: fnSpec) stdcall; generate: [ :gen | self emitCall: fnIndex generator: gen ] ] ] on: NBNativeCodeError do: [:err :handler | err errorCode = ErrorFnNotAvailable ifTrue: [ "Native code is installed, but function pointer not loaded yet. Try to load function and retry the call" (self tryGetFunctionPointer: (self class glFunctions at: fnIndex)) ifFalse: [ ^ err pass ]. ^ handler retrySend ]. err pass ] The problem here that NBCallFailureHandler is nowhere to be found. At first I though my NB was lagging behind in version so I download from smalltalk Hub and did ConfigurationOfNativeboost loadStable. it updated without errors but still that class is nowhere to be found. So my question is this, does it really worth it to struggle with NBOpengl or will it better to learn how Nativeboost works and use Opengl myself ? |
|
|
On 9 May 2013 00:04, kilon <[hidden email]> wrote:
> Ok so I tried to learn Opengl ES 2 (and opengl 4) during my eastern vacations > because I realised > > that I dont really need Athens or vector graphics for my GUI , since I will > be dealing mostly with 3d > graphics anyway. (My project "ephestos" will be an effort of creating a 3d > app for pharo, see also "blender") > well, Athens provides convenient API for 2d vector graphics, which not exists in opengl .. One day i want to begin implementing opengl backend for Athens. > So when I tried to run the demos i get an error with > > NBMacGLContextDriver>>supportsCurrentPlatform > "obviously, for Mac intel-32 only :)" > ^ NativeBoost platformId = NativeBoostConstants mac32PlaformId > > My mac is "obviously" not 32-bit but 64 bit, but I dont know if that matters > since pharo is only 32 bit anyway. > The bug is also obvious it should be mac32PlatformId and not mac32PlaformId. > > I correct and proceed and gives me a new error this time in > > NBMacGlApi>>glApiCall: fnSpec index: fnIndex attributes: attributes context: > contextToRetry > > ^[ > (NBCallFailureHandler for: contextToRetry) retryWith: [ :targetClass > :targetMethod | > (NBFFICallout > targetClass: targetClass targetMethod: targetMethod fnSpec: > fnSpec) > stdcall; > generate: [ :gen | self emitCall: fnIndex generator: gen ] > ] > ] on: NBNativeCodeError do: [:err :handler | > err errorCode = ErrorFnNotAvailable ifTrue: [ > "Native code is installed, but function pointer not loaded yet. > Try to load function and retry the call" > (self tryGetFunctionPointer: (self class glFunctions at: > fnIndex)) ifFalse: [ ^ err pass ]. > ^ handler retrySend > ]. > err pass > ] > > The problem here that NBCallFailureHandler is nowhere to be found. At first > I though my > NB was lagging behind in version so I download from smalltalk Hub and did > > ConfigurationOfNativeboost loadStable. > Neither my image has "NBCallFailureHandler". Looks like you loaded wrong version of NBOpenGL. How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load it should work out of the box. (and you don't need to load NativeBoost, because it is already in image). > it updated without errors but still that class is nowhere to be found. > > So my question is this, does it really worth it to struggle with NBOpengl or > will it better to learn how Nativeboost works and use Opengl myself ? > That what exactly NBOpenGL is. Its contents is bindings to OpenGL library (over 3000 functions) the rest is glue code , which mostly serves as an example how to create and initialize opengl context depending on platform you using. The subcategory "NBOpenGL-Display" contains root classes with that glue code. While NBOpenGL-Core is 99% is just plain opengl api. If you don't like this glue, you can just avoid using it.. but throwing away opengl core and making own.. makes little sense. I actually encouraged people to write better glue code for initializing context.. The main problem is that its highly platform specific.. and my knowledge doesn't covers deeply all 3 platforms. I did windows and mac parts.. and linux made by Javier. > > > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
|
|
On 14 May 2013 00:45, Igor Stasenko <[hidden email]> wrote:
> On 9 May 2013 00:04, kilon <[hidden email]> wrote: >> Ok so I tried to learn Opengl ES 2 (and opengl 4) during my eastern vacations >> because I realised >> >> that I dont really need Athens or vector graphics for my GUI , since I will >> be dealing mostly with 3d >> graphics anyway. (My project "ephestos" will be an effort of creating a 3d >> app for pharo, see also "blender") >> > well, Athens provides convenient API for 2d vector graphics, which not > exists in opengl .. > One day i want to begin implementing opengl backend for Athens. > >> So when I tried to run the demos i get an error with >> >> NBMacGLContextDriver>>supportsCurrentPlatform >> "obviously, for Mac intel-32 only :)" >> ^ NativeBoost platformId = NativeBoostConstants mac32PlaformId >> >> My mac is "obviously" not 32-bit but 64 bit, but I dont know if that matters >> since pharo is only 32 bit anyway. >> The bug is also obvious it should be mac32PlatformId and not mac32PlaformId. >> >> I correct and proceed and gives me a new error this time in >> >> NBMacGlApi>>glApiCall: fnSpec index: fnIndex attributes: attributes context: >> contextToRetry >> >> ^[ >> (NBCallFailureHandler for: contextToRetry) retryWith: [ :targetClass >> :targetMethod | >> (NBFFICallout >> targetClass: targetClass targetMethod: targetMethod fnSpec: >> fnSpec) >> stdcall; >> generate: [ :gen | self emitCall: fnIndex generator: gen ] >> ] >> ] on: NBNativeCodeError do: [:err :handler | >> err errorCode = ErrorFnNotAvailable ifTrue: [ >> "Native code is installed, but function pointer not loaded yet. >> Try to load function and retry the call" >> (self tryGetFunctionPointer: (self class glFunctions at: >> fnIndex)) ifFalse: [ ^ err pass ]. >> ^ handler retrySend >> ]. >> err pass >> ] >> >> The problem here that NBCallFailureHandler is nowhere to be found. At first >> I though my >> NB was lagging behind in version so I download from smalltalk Hub and did >> >> ConfigurationOfNativeboost loadStable. >> > > Neither my image has "NBCallFailureHandler". > Looks like you loaded wrong version of NBOpenGL. > How did you loaded NBOpenGL? > For 2.0/3.0 pharo image use > (ConfigurationOfNBOpenGL project version: '2.0') load > > it should work out of the box. > (and you don't need to load NativeBoost, because it is already in image). > >> it updated without errors but still that class is nowhere to be found. >> >> So my question is this, does it really worth it to struggle with NBOpengl or >> will it better to learn how Nativeboost works and use Opengl myself ? >> > > That what exactly NBOpenGL is. > Its contents is bindings to OpenGL library (over 3000 functions) > the rest is glue code , which mostly serves as an example how to > create and initialize > opengl context depending on platform you using. > > The subcategory "NBOpenGL-Display" contains root classes with that glue code. > While NBOpenGL-Core is 99% is just plain opengl api. > > If you don't like this glue, you can just avoid using it.. but throwing away > opengl core and making own.. makes little sense. > I actually encouraged people to write better glue code for > initializing context.. > The main problem is that its highly platform specific.. and my > knowledge doesn't covers > deeply all 3 platforms. > I did windows and mac parts.. and linux made by Javier. > to initialize context differently (different pixel format , different number of buffers etc).. you will need to override/rewrite context initialization part by youself. So, the existing context initialization code is more for demo purposes but not for serious use. Another thing, that i don't see how i can provide sufficient "generic" context creation part, because there's a lot of flags and options which sometimes need fine tuning (like selecting most matching pixel format), which would make code too clever, and therefore rigid.. and i know by myself that it is best to be left for developer to decide what he wants and how. >> >> >> -- >> View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Igor Stasenko
On May 14, 2013, at 12:45 AM, Igor Stasenko <[hidden email]> wrote: > How did you loaded NBOpenGL? > For 2.0/3.0 pharo image use > (ConfigurationOfNBOpenGL project version: '2.0') load I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make ConfigurationOfNBOpenGL load. work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. Esteban |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
I usually add a nice class comment in the configurationof...
On May 15, 2013, at 9:37 AM, Esteban Lorenzano <[hidden email]> wrote: > > On May 14, 2013, at 12:45 AM, Igor Stasenko <[hidden email]> wrote: > >> How did you loaded NBOpenGL? >> For 2.0/3.0 pharo image use >> (ConfigurationOfNBOpenGL project version: '2.0') load > > I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) > It would be a lot better to make > > ConfigurationOfNBOpenGL load. > > work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. > > Esteban |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by EstebanLM
On 15 May 2013 09:37, Esteban Lorenzano <[hidden email]> wrote:
> > On May 14, 2013, at 12:45 AM, Igor Stasenko <[hidden email]> wrote: > >> How did you loaded NBOpenGL? >> For 2.0/3.0 pharo image use >> (ConfigurationOfNBOpenGL project version: '2.0') load > > I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) > It would be a lot better to make > > ConfigurationOfNBOpenGL load. > unless you put a lot of complex logic behind that "load", it will never work. That's why i prefer to giving a version numbers. This version of config works with 2.0 image, and no pain, no surprises. Now, when people get used to do "ConfigurationOfNBOpenGL load" it is less pain, but just for the next major update of whatever infrastructural parts in Pharo. And second, for me, as developer , it is much more helpful to deal with problem reports like: "this version doesn't loads/works with this version of image" instead of "i tried and it doesn't works" :) > work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. > > Esteban -- Best regards, Igor Stasenko. |
|
|
On May 16, 2013, at 11:53 PM, Igor Stasenko <[hidden email]> wrote: > On 15 May 2013 09:37, Esteban Lorenzano <[hidden email]> wrote: >> >> On May 14, 2013, at 12:45 AM, Igor Stasenko <[hidden email]> wrote: >> >>> How did you loaded NBOpenGL? >>> For 2.0/3.0 pharo image use >>> (ConfigurationOfNBOpenGL project version: '2.0') load >> >> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >> It would be a lot better to make >> >> ConfigurationOfNBOpenGL load. >> > > unless you put a lot of complex logic behind that "load", > it will never work. Why? load should be ConfigurationOfNBOpenGL class>>#load ^ self project stableVersion load. and nothing else > That's why i prefer to giving a version numbers. This version of > config works with 2.0 image, > and no pain, no surprises. > Now, when people get used to do "ConfigurationOfNBOpenGL load" > it is less pain, but just for the next major update of whatever > infrastructural parts in Pharo. again... why? Because what happens now is that people try to do what is the convention for metacello. Also, that means that by not following the conventions, NBOpenGL will never be able to be loaded through configuration browser :( > > And second, for me, as developer , it is much more helpful to deal > with problem reports like: > "this version doesn't loads/works with this version of image" > instead of "i tried and it doesn't works" :) he, I'm sorry, I disagree... If you as a developer promote a version as a release by assigning a #stable symbolic version to configuration, you know exactly which version the guy is trying to load. And you will not have the problem "this version does not loads...", which is a consequence of not declaring a version as stable for a platform. Looks to me that the problem you try to avoid is in fact happening because the configuration is not adapted to the convention, not the opposite :) As proof... lot's of complex project follow the convention (seaside, for example), and nobody has the issue you say. Recently they prepared the configuration for 2.0, and that means that seaside now loads fine in 1.4 and 2.0.... cheers, Esteban > >> work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. >> >> Esteban > > > > -- > Best regards, > Igor Stasenko. > |
|
|
Thank you all for your replies. I have used the solution I get new errors now. Is there an example how to create a context with NBOpenGL because the examples NBOpenGL is coming with are confusing at best ?
|
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by EstebanLM
Update the jenkins job to be multi-platform (though only loading #last):
https://ci.inria.fr/pharo-contribution/job/NBOpenGL On 2013-05-17, at 09:10, Esteban Lorenzano <[hidden email]> wrote: > On May 16, 2013, at 11:53 PM, Igor Stasenko <[hidden email]> wrote: > >> On 15 May 2013 09:37, Esteban Lorenzano <[hidden email]> wrote: >>> >>> On May 14, 2013, at 12:45 AM, Igor Stasenko <[hidden email]> wrote: >>> >>>> How did you loaded NBOpenGL? >>>> For 2.0/3.0 pharo image use >>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>> >>> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>> It would be a lot better to make >>> >>> ConfigurationOfNBOpenGL load. >>> >> >> unless you put a lot of complex logic behind that "load", >> it will never work. > > Why? > load should be > > ConfigurationOfNBOpenGL class>>#load > ^ self project stableVersion load. > > and nothing else > >> That's why i prefer to giving a version numbers. This version of >> config works with 2.0 image, >> and no pain, no surprises. >> Now, when people get used to do "ConfigurationOfNBOpenGL load" >> it is less pain, but just for the next major update of whatever >> infrastructural parts in Pharo. > > again... why? > Because what happens now is that people try to do what is the convention for metacello. Also, that means that by not following the conventions, NBOpenGL will never be able to be loaded through configuration browser :( > >> >> And second, for me, as developer , it is much more helpful to deal >> with problem reports like: >> "this version doesn't loads/works with this version of image" >> instead of "i tried and it doesn't works" :) > > he, I'm sorry, I disagree... > If you as a developer promote a version as a release by assigning a #stable symbolic version to configuration, you know exactly which version the guy is trying to load. > And you will not have the problem "this version does not loads...", which is a consequence of not declaring a version as stable for a platform. Looks to me that the problem you try to avoid is in fact happening because the configuration is not adapted to the convention, not the opposite :) > As proof... lot's of complex project follow the convention (seaside, for example), and nobody has the issue you say. Recently they prepared the configuration for 2.0, and that means that seaside now loads fine in 1.4 and 2.0.... > > cheers, > Esteban > >> >>> work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. >>> >>> Esteban >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by kilon
On 17 May 2013 10:21, kilon <[hidden email]> wrote:
> Thank you all for your replies. I have used the solution I get new errors > now. Is there an example how to create a context with NBOpenGL because the > examples NBOpenGL is coming with are confusing at best ? > Pharo2.0 Latest update: #20590 (ConfigurationOfNBOpenGL project version: '2.0') load GLTTRenderingDemo new openInWorld (works well.. no errors whatsoever) See a superclass (GLViewportMorph). The context created using: display := NBGLDisplay extent: self extent. To get access to OpenGL API (a subinstance of NBOpenGL) just use: display gl. The actual class, responsible for creating OpenGL context is one of NBGLContextDriver subclasses, since it is highly platform-specific. driver := NBGLContextDriver createContext: 100@100. gl := driver gl. The display (NBGLDisplay) wraps around driver and has some initialization to set up defaults and resource management to make sure resources released when it garbage collected (the driver does not, and you must free it explicitly). To use GL API , just send #gl message to either display or driver: drawCube | gl | gl := display gl. gl translatef_x: -1.5 y: 0 z: -60. gl rotatef_angle: rotationAngle x: 0 y: 1 z: 0. gl begin: GL_TRIANGLES; ... end. Please note, that in NBGLContextDriver(s) i hardcoded many things like pixel format, and NBOffscreenDisplay rendering into offscreen buffer etc. That means, if you want to create own initializer, i would start from making own driver. Sorry but the stuff there is highly platform specific. Making a generic driver which would accept some initialization options (like pixel format, number of buffers etc) while freeing user from platform-specific horrors is something which could be done in future. But as i said before, the devil is always in details , and i would just leave this to application developer. P.S. If , by chance, you wanna make things less confusing and more obvious, feel free to contribute to the project, i can add you as developer. You can change/improve anything. I only asking to keep GLTTRenderingDemo working :) > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4688138.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by EstebanLM
On 17 May 2013 09:10, Esteban Lorenzano <[hidden email]> wrote:
> > On May 16, 2013, at 11:53 PM, Igor Stasenko <[hidden email]> wrote: > >> On 15 May 2013 09:37, Esteban Lorenzano <[hidden email]> wrote: >>> >>> On May 14, 2013, at 12:45 AM, Igor Stasenko <[hidden email]> wrote: >>> >>>> How did you loaded NBOpenGL? >>>> For 2.0/3.0 pharo image use >>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>> >>> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>> It would be a lot better to make >>> >>> ConfigurationOfNBOpenGL load. >>> >> >> unless you put a lot of complex logic behind that "load", >> it will never work. > > Why? > load should be > > ConfigurationOfNBOpenGL class>>#load > ^ self project stableVersion load. > > and nothing else the problem is that #stableVersion for 2.0 and #stableVersion for 1.4 may differ as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have it by default. > >> That's why i prefer to giving a version numbers. This version of >> config works with 2.0 image, >> and no pain, no surprises. >> Now, when people get used to do "ConfigurationOfNBOpenGL load" >> it is less pain, but just for the next major update of whatever >> infrastructural parts in Pharo. > > again... why? > Because what happens now is that people try to do what is the convention for metacello. Also, that means that by not following the conventions, NBOpenGL will never be able to be loaded through configuration browser :( > image use this version of library? >> >> And second, for me, as developer , it is much more helpful to deal >> with problem reports like: >> "this version doesn't loads/works with this version of image" >> instead of "i tried and it doesn't works" :) > > he, I'm sorry, I disagree... > If you as a developer promote a version as a release by assigning a #stable symbolic version to configuration, you know exactly which version the guy is trying to load. > And you will not have the problem "this version does not loads...", which is a consequence of not declaring a version as stable for a platform. Looks to me that the problem you try to avoid is in fact happening because the configuration is not adapted to the convention, not the opposite :) > As proof... lot's of complex project follow the convention (seaside, for example), and nobody has the issue you say. Recently they prepared the configuration for 2.0, and that means that seaside now loads fine in 1.4 and 2.0.... > Okay, then i will ask you to help making it working for 2.0 an 3.0 (we can ignore 1.4 i think). And here again, how you propose to deal with situation that i wanna discontinue support for 1.4 (so , if you do just #load, in 1.4 image it won't work, because latest #stable version does not supports that version of Pharo anymore).. Now if you specify exact version which still supports 1.4 you can load and use it. So, what is your recipe for this situation? Writing case statements? MyConfig>>stableVersion Smalltalk version = 1.4 ifTrue: [ ^ '0.4' ]. Smalltalk version = 2.0 ifTrue: [ ^ '0.8' ]. Smalltalk version = 3.0 ifTrue: [ ^ '1.8' ]. i can do that, if you insist.. but that IMO, defeats purpose of using Metacello. Because once you start with adding ugly if/case statements, they will tend to grow larger and larger over time.. and we end up with something like linux configure scripts.. > cheers, > Esteban > -- Best regards, Igor Stasenko. |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 2013-05-17, at 20:48, Igor Stasenko <[hidden email]> wrote: > On 17 May 2013 09:10, Esteban Lorenzano <[hidden email]> wrote: >> >> On May 16, 2013, at 11:53 PM, Igor Stasenko <[hidden email]> wrote: >> >>> On 15 May 2013 09:37, Esteban Lorenzano <[hidden email]> wrote: >>>> >>>> On May 14, 2013, at 12:45 AM, Igor Stasenko <[hidden email]> wrote: >>>> >>>>> How did you loaded NBOpenGL? >>>>> For 2.0/3.0 pharo image use >>>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>>> >>>> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>>> It would be a lot better to make >>>> >>>> ConfigurationOfNBOpenGL load. >>>> >>> >>> unless you put a lot of complex logic behind that "load", >>> it will never work. >> >> Why? >> load should be >> >> ConfigurationOfNBOpenGL class>>#load >> ^ self project stableVersion load. >> >> and nothing else > > the problem is that #stableVersion for 2.0 > and #stableVersion for 1.4 may differ > as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have > it by default. you can easily do that: stable: spec <symbolicVersion: #stable > spec for: #'pharo1.4' version: '100'. spec for: #'pharo2.0' version: '200'. spec for: #'pharo3.0' version: '300'. |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 17 May 2013 20:56, Camillo Bruni <[hidden email]> wrote:
> > On 2013-05-17, at 20:48, Igor Stasenko <[hidden email]> wrote: > >> On 17 May 2013 09:10, Esteban Lorenzano <[hidden email]> wrote: >>> >>> On May 16, 2013, at 11:53 PM, Igor Stasenko <[hidden email]> wrote: >>> >>>> On 15 May 2013 09:37, Esteban Lorenzano <[hidden email]> wrote: >>>>> >>>>> On May 14, 2013, at 12:45 AM, Igor Stasenko <[hidden email]> wrote: >>>>> >>>>>> How did you loaded NBOpenGL? >>>>>> For 2.0/3.0 pharo image use >>>>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>>>> >>>>> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>>>> It would be a lot better to make >>>>> >>>>> ConfigurationOfNBOpenGL load. >>>>> >>>> >>>> unless you put a lot of complex logic behind that "load", >>>> it will never work. >>> >>> Why? >>> load should be >>> >>> ConfigurationOfNBOpenGL class>>#load >>> ^ self project stableVersion load. >>> >>> and nothing else >> >> the problem is that #stableVersion for 2.0 >> and #stableVersion for 1.4 may differ >> as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have >> it by default. > > > you can easily do that: > > stable: spec > <symbolicVersion: #stable > > > spec for: #'pharo1.4' version: '100'. > spec for: #'pharo2.0' version: '200'. > spec for: #'pharo3.0' version: '300'. > (it is still a case statement, but not so ugly however ;) > > -- Best regards, Igor Stasenko. |
|
|
Hey Igor , yes I would love to contrinbute to NBOpenGL for a very long time.
I could at least fix those small errors like the one I reported and add documentation to methods and especially classes. I am using pharo 3.0 and GLTTRenderingDemo does not work. I get an error. Apparently it cannot find ShortPointArray which is initialised inside TTCountourConstruction>>asCompressedPoints I remember having same issues with pharo 2.0 too. I am also confused how to use NBGLCurveRenderer. Thank you for your detailed explanation I have tried GLViewportMorphic I see no errors , so its should work fine. I am new to opengl myself , and smalltalk and nativeboost so I try to understand as much I can before doing actual coding and I feel I am at that stage that I can do and I would love to contribute my work back to pharo because I plan to implement at least a basic 3d engine and very basic MoprhicGL GUI. |
|
|
I am looking at NBGLContextDriver and NBGLDisplay and I see none of that hard coded stuff.
I assume you mean the platform specific packages like NBMacGLContextDriver ,NBGLXContextDriver etc. where I see alot of platform specific code inside the methods of those classes . |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 22 May 2013 20:11, kilon <[hidden email]> wrote:
> I am looking at NBGLContextDriver and NBGLDisplay and I see none of that hard > coded stuff. > Look more carefully: there's a code to manage viewport and setting up buffers and other things, like blend more etc in those classes. It is not platform-specific (because it uses purely only opengl api), but it doesn't makes it less hardcoded. > I assume you mean the platform specific packages like NBMacGLContextDriver > ,NBGLXContextDriver etc. where I see alot of platform specific code inside > the methods of those classes . > Yes, it has to be platform-specific. But do not confuse "hardcoded" stuff with "platform-specific" code. Ideally, there should be no hardcoded one, but it is hard to achieve (for the reasons i mentioned before, and one of them is platform-specificness, of course). > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689211.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by kilon
On 22 May 2013 20:00, kilon <[hidden email]> wrote:
> Hey Igor , yes I would love to contrinbute to NBOpenGL for a very long time. > I could at least fix those small errors like the one I reported and add > documentation to methods and > especially classes. > > I am using pharo 3.0 and GLTTRenderingDemo does not work. I get an error. > > Apparently it cannot find ShortPointArray which is initialised inside > TTCountourConstruction>>asCompressedPoints > issue abound it)... I already saved some classes which was thrown out of Pharo image into separate package (like code to read and decypher .tff files). But changes keep going.. (what a surprise ;) and so require energy and time to keep things up to date. > I remember having same issues with pharo 2.0 too. > > I am also confused how to use NBGLCurveRenderer. > you don't. i made this class purely for my demo purposes. the code there is far-far from general use. :) > Thank you for your detailed explanation I have tried GLViewportMorphic I see > no errors , so its should work fine. > > I am new to opengl myself , and smalltalk and nativeboost so I try to > understand as much I can before doing actual coding and I feel I am at that > stage that I can do and I would love to contribute my work back to pharo > because I plan to implement at least a basic 3d engine and very basic > MoprhicGL GUI. > so, if you able to instantiate GLViewport and open it in window, try to render something (simple triangles etc..) and see if you get anything. > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689207.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
I added you as contributor to project. Feel free to contribute! :)
I would love to play more with OpenGL, but i am swamped with other stuff. -- Best regards, Igor Stasenko. |
|
|
ok i see, well I did not mean that we dont need platform specific code, of course we do.
thanks for adding me. I will first try to contribute some example classes that show how nbopengl can be used in practice. And see if I can fix any of the bugs I find. No problem if you dont have time, I do and will HOPEFULLY be the very area will focus from now , so I am here to stay unless I hit a dead end and cant use opengl properly for some reason. |
|
|
Ok new problem, NBOpengl seems to not work at all on my UBUNTU 12.10 machine. I was trying to do GLViewportMorph new openInWorld , which works fine on my iMac and it gave me error: function unavailable.
So I assumed it cannot find some dynamic library , so I checked around the code and found that in package NBXLib-Core NBXlibHandle>>nbLibraryNameOrHandle class method, it returns '/usr/lib/libX11.so'. However browsing through the directories its clear that the library is not located in there but rather is located as a symlink in a) /usr/lib/i386-linux-gnu b) /usr/lib/x86_64-linux-gnu. Both symlink point to libx11.so.6.3.0 libraries. So knowning that pharo is 32 bit I went for option (a) however still it gives me the same error. Any idea what it may be ? Another question I have is does it not NB check first to see if the library is available ? Because it looks weird that it complains about non existent functions but does not complain about non existent library. Here is the stack NBFFICallout(Object)>>error: NBFFICallout>>generateCall:module: NBGlxAPI>>call: in Block: [...] NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: in Block: [...] BlockClosure>>on:do: NBRecursionDetect class>>in:during: NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: NBGlxAPI>>call: NBGlxAPI>>queryExtension:errorBase:eventBase: NBGLXContextDriver>>createContext: NBGLContextDriver class>>createContext: NBGLDisplay class>>extent: GLViewportMorph>>initializeForNewSession GLViewportMorph>>initialize GLViewportMorph class(Behavior)>>new UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: SmalltalkEditor>>evaluateSelectionAndDo: SmalltalkEditor>>evaluateSelection PluggableTextMorph>>doIt in Block: [...] PluggableTextMorph>>handleEdit: in Block: [...] TextMorphForEditView(TextMorph)>>handleEdit: PluggableTextMorph>>handleEdit: PluggableTextMorph>>doIt Workspace(Object)>>perform:orSendTo: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [...] BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |