Understanding NBOpenGL
Locked
1234
1234
 
|
you can have outdated documentation as you can have buggy code and even outdated code. And yes I would not trust a coder to write proper documentation as much I would trust someone who writes documentation to code or fix a bug. Why ? because its all about motivation, thats why.
But you know what , its easy to pick , just ask your users what they want. If they dont want me to contribute to wikibooks and instead contribute to tests, comment classes and methods sure ok I will do it. |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by kilon
On 2 July 2013 16:27, kilon <[hidden email]> wrote:
> Igor got you will try to avoid using #sizeOf: , even for a readability I can > replace it with a simple method returning the same thing depending in > platform. > > Now because I am confused lets clarify how the whole things works because I > see many errors in my code and clearly I don't understand how Nativeboost > works. Note I am a C noob , so excuse me if I say anything stupid here. > > As far as functions call are concerned I see 3 possible scenariors > > a ) function(int var). Here the C function expects a simple variable of some > type (int in this case) according to what you told me to make such variable > I will do > > var := Nativeboost allocate:( NBExternalType typeof:'int') > > if I want to pass a value in that variable then I will do > > var nbInt32AtOffset: 0 put: 6 > > will call that function with > > Object function: var > if your function is 'function(int var)' you call it directly: someobject function: 5 x := 10. someobject function: x etc.. > b) function(int* var) > > how I create the variable (pointer) ? > > how I put value in the variable (pointer) ? > pointer = address on memory which holding some value. every time you see '*', it means that function expects pointer. And of course, since that function will write or read from that memory location, it is your responsibility to provide a pointer to valid data, with enough size etc. So, the way how you did for first case, is actually applicable for this case. But it is not necessary to use externally allocated memory. Sometimes you can safely use object memory, e.g.: buffer := ByteArray new: 4. someobject function: buffer. > c) function( &var) > did you meant 'int &var'? because otherwise it is not correct declaration. > Now I assume I will create a var variable same way as (a) > > var := Nativeboost allocate:( NBExternalType typeof:'int') > > but how I pass the address of var to the function ? > this is reference (more from C++).. which in fact just a syntactic sugar, function still expecting pointer (so consider this to be same as *var) > > I read the pdf of nativeboost but It did not clarify those things or simply > I did not understand. > > Thanks on the instructions about NBExternalArray. So the reason of using > this object is for convenience ? > Of course. It is more convenient to deal with array of typed elements (of type you need), than manually deal with bunch of raw bytes. > > Igor Stasenko wrote >> On 1 July 2013 20:40, kilon < > >> thekilon@.co > >> > wrote: >>> Thanks Igor , yes I was aware of String Cr because I have done some >>> googling >>> around and it did find information on the subject. Apparently it failed >>> because I had an error in my source. >>> >>> So for our next challenge is learning how to fetch data that a pointer >>> points to. >>> >>> in this case I have an array that contains my vertex positions , called >>> vertexPositions >>> >>> vertexPositions >>> "the positions of vertices to be passed to opengl" >>> >>> ^ #( 0.75 0.75 0.0 1.0 >>> 0.75 -0.75 0.0 1.0 >>> -0.75 -0.75 0.0 1.0 ) >>> >>> so far so good >>> >>> so I create a pointer for that array >>> >>> vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size. >>> >>> and then take that pointer and insert in each position the individual >>> values >>> from vertexPositions >>> >>> vertexPositions withIndexDo: [:each :i | >>> "using nbUInt32AtOffset because we know pointer is 4 bytes :) >>> " >>> vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: >>> 'float') put: >>> each value. >>> Transcript show: ' I am putting to vpos in index: '; show: i-1; >>> show:' >>> value: '; show: each value; cr. >>> ]. >>> >>> so far so good. >>> >> >> just one small advice: do not use #sizeOf: sparingly.. it parsing the >> type >> and doing full type resolution when you do that. >> you can remember the size of the type you need at boot/startup time, >> there is no chance >> it can change within same session :) >> >> but of course for demonstration purposes and readability it good. >> >>> now the tricky part is that I have a function that expects that Array , >>> not >>> the smalltalk version but the C version we just created >>> >>> gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... >>> usage: >>> GL_STATIC_DRAW. >>> >>> where you see the dots is where I should pass the data, in this case the >>> C >>> array >>> >>> I could do a vpo nbFloat32AtOffset: but that will return me only the >>> individual value at the specific point (index) of the array, while I want >>> to >>> pass the entire array. >>> >>> So how I do that ? >>> >>> I explored NBExternalAdress and I cant find something that would return >>> an >>> array. Am I missing something obvious here ? >>> >> >> just pass NBExternalAdress instance as argument and you done. >> >>> NBExternalAdress value , returns the number of the address and not that >>> data >>> contained in that address. >>> >>> I also see a NBExternalArray but I am not sure if it is what I should be >>> using . >>> >> >> arrayClass := NBExternalArray ofType: 'float'. >> array := arrayClass new: 5. "or externalNew:5 , if you want to >> allocate it in external memory" >> >> array at: 1 put: 10.1 "use just like normal Array" >> >> to pass it to function use: >> >> self soemFunction: array address. >> >>> Igor Stasenko wrote >>>> On 30 June 2013 21:11, kilon < >>> >>>> thekilon@.co >>> >>>> > wrote: >>>>> I am not going to post my code here cause it has become too big , you >>>>> can >>>>> find it here >>>>> >>>>> http://www.smalltalkhub.com/#!/~kilon/GLTutorial >>>>> <http://www.smalltalkhub.com/#!/~kilon/GLTutorial> >>>>> >>>>> I tried adding newlines with String cr to my shaders strings, but >>>>> apparently >>>>> opengl is not convinced. It looks like smalltalk cr is not converted to >>>>> C >>>>> "\n" newlines. So how I do that ? >>>>> >>>> >>>> simply replace all occurences of >>>> Character cr >>>> with >>>> Character lf >>>> (or crlf, if it wants that) >>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html >>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>> Nabble.com. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > > > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696858.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
|
|
Thank you Igor for the clarifications, the reason why I prefer using the nativeboost methods is because :
a) I was not sure if smalltalk types map correctly to C types and which Smalltalk types correspond to which C types b) many opengl functions ask for the address of the value and the value itself. And I have no clue how to obtain memory addresses of smalltalk types. c) I was not sure whether Pharo VM or garbage collector would move my data making my pointers invalid. But if you say its ok, I trust you. When exactly is ok to use smalltalk types ? |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 2 July 2013 23:04, kilon <[hidden email]> wrote:
> Thank you Igor for the clarifications, the reason why I prefer using the > nativeboost methods is because : > > a) I was not sure if smalltalk types map correctly to C types and which > Smalltalk types correspond to which C types well, there's no such thing as 'types' in smalltalk :) > > b) many opengl functions ask for the address of the value and the value > itself. And I have no clue how to obtain memory addresses of smalltalk > types. > you don't. The value can have a type, but address don't. Address is just a location in memory, where the value(s) (could be) stored. For any function which takes a pointer, you can pass an instance of ByteArray, or instance of NBExternalAddress to it. In first case, a pointer to first byte of bytearray will be passed to function, in second one , the value of address. So, you either allocate buffer in object memory, or external memory.. fill it with whatever it needs and pass to function. Does that sounds simple enough? > c) I was not sure whether Pharo VM or garbage collector would move my data > making my pointers invalid. > > But if you say its ok, I trust you. When exactly is ok to use smalltalk > types ? > if you pass a pointer to something in object memory into function, make sure GC cannot move the object while function uses/accessing its contents. and it is only for pointers. For arguments which is passed by value (ints/floats), you don't have to care. > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696955.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
|
|
yeah I know there is no such thing as types in smalltalk , since everything is an object and the language is dynamic. I was referring to how those objects map to C types.
But you are correct it is simpler than I was assuming. The more I think about it the more it makes sense.
|
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by Igor Stasenko
How? |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
I'm just guessing, but if a function receives a pointer, it does not store the pointer anywhere but works with the contents, and finally returns while VM is blocked, voilá :). On Wed, Jul 3, 2013 at 10:13 PM, Stéphane Ducasse <[hidden email]> wrote:
|
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 3 July 2013 22:36, Guillermo Polito <[hidden email]> wrote:
> I'm just guessing, but if a function receives a pointer, it does not store > the pointer anywhere but works with the contents, and finally returns while > VM is blocked, voilá :). > Yes. > > On Wed, Jul 3, 2013 at 10:13 PM, Stéphane Ducasse > <[hidden email]> wrote: >> >> >> >> if you pass a pointer to something in object memory into function, >> make sure GC cannot move the object while function uses/accessing its >> contents. >> >> >> How? >> >> > -- Best regards, Igor Stasenko. |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by Guillermo Polito
ok we should write that in the NB chapter.
On Jul 3, 2013, at 10:36 PM, Guillermo Polito <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |