On 14 May 2013 00:45, Igor Stasenko <siguc...@gmail.com> wrote:
> On 9 May 2013 00:04, kilon <theki...@yahoo.co.uk> 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.
>
Oh, and i should also mention, since depending on application you may want
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.

Reply via email to