Hi Jonathan,
yes i discovered that yesterday too.
Changing all of the "i" s to "I"s was not too hard - i do not know if this is a
change in Pointer types or whatever.
The bigger issue is that this call:
data = CGBitmapContextGetData(context)
no longer seems to return the correct data type (type "C" rather than type "v")
- perhaps this is a BridgeSupport issue - I do not know, however the fix and
the reason why i think its a bug, is that you can get all working (once the
first fix with "i" s are done) by replacing the following code in the
GLView.load_texture method from:
context = Tools.sendTexture(imageRef)
data = CGBitmapContextGetData(context)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_STORAGE_HINT_APPLE,
GL_STORAGE_SHARED_APPLE)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE )
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE )
gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, width, height, GL_BGRA,
GL_UNSIGNED_INT_8_8_8_8, data)
to
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_STORAGE_HINT_APPLE,
GL_STORAGE_SHARED_APPLE)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE )
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE )
Tools.sendTexture(imageRef)
and add to the objc class, in class method sendTexture, before the return
(which is now superfluous, but i did not change through laziness):
CGContextRelease(context);
gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, width, height, GL_BGRA,
GL_UNSIGNED_INT_8_8_8_8, data);
the release is there because i know now that CoreGraphics is not garbage
collected.
So the very same opengl mipmap call (with same datatype) works fine now, and so
does the game (IcePhage - and its the same code in CarNage).
Of course you could move most of those opengl calls into the objC method - but
that might defeat the purpose of limiting the objc code to the minimum.
Cheers,
J
On Jan 23, 2010, at 3:19 PM, Jonathan Waddilove wrote:
> John,
>
> I've just started to look at your IcPhage9 and CarNage8. Neither runs 'out of
> the box' under MacRuby Beta.5(2). There are various problems with the Pointer
> support having evolved (I think), e.g.: errors like "Pointer of type `i', got
> `l'" - I'm working to correct these and see if I can make the code function
> again.
>
> It would be great if we could assemble a web page that documents some of the
> required knowledge on MAcRuby Pointers for OpenGL.
>
> regards, Jonathan
>
>
> On 22 Jan 2010, at 16:06, John Shea wrote:
>
>>
>>
>> Thank you again for offering the additional resources. It would be great if
>> you wanted to add them to your idisc.
>> sure.
>>
>>
>>
>> I did find a copy of your excellent presentation "Building Games with
>> MacRuby and OpenGL", I must work through the slides again. Did you consider
>> sharing your game tools? The presentation would make a very useful basis for
>> a web tutorial on the MacRuby/openGL topic.
>> As far as tools are concerned the only one that ended up being useful in the
>> end was canning particle effects, so you run the explosion, fireworks or
>> whatever and then record a series of images, which you can use for animation
>> later. With IcePhage however it was all on the fly particle effects - canned
>> animation was not necessary - it could do with some optimisation (both in
>> look and efficiency) - and macruby speed increases have probably have
>> improved performance.
>>
>> Is that what you meant by tools?
>>
>> The only other software (sans MacRuby) I used was XCode, TextMate and for 3D
>> experiments Cheetah 3D, some Illustrator & Ria for drawing, graphic
>> converter to clean up the PNGs.
>>
>> Let me know if you meant something else regarding tools.
>>
>> Cheers,
>>
>> J
>>
>>
>>
>>
>>
>>
>>
>> Like you, I'm new to both openGL and MacRuby - my interest is in
>> visualisations rather than games. Right now I'm just greatfull that folks
>> like you are willing to share their hard earned skills.
>>
>> Best wishes, Jonathan
>>
>> jonathan 'at' waddilove.net
>>
>>
>> On 22 Jan 2010, at 09:28, John Shea wrote:
>>
>>> Jonathan,
>>>
>>> I made some games in opengl this time last year (which now seem quite
>>> naive, as i did not know opengl or cocoa, so they could do with a good
>>> refactor).
>>>
>>> I do not know if they work with the current version of macruby but they are
>>> on my idisk:
>>>
>>> www.johnmacshea.org
>>>
>>> navigate thru MacRuby / Game Related / Mine
>>>
>>> Two 2D games CarNage8 and IcePhage9 are there.
>>>
>>> They do screen setup, texture loading, writing text to opengl scenes (two
>>> different ways), canned explosions sometimes and particle effects for other
>>> explosions.
>>>
>>> They do not use VAs or VBOs - but I do have some test projects which use
>>> VAs and VBOs, and a 3D test (which uses an exported c header file (from
>>> Cheetah 3D) holding vertex arrays).
>>>
>>> Let me know if you are interested and I will dig them up and send them to
>>> you (only tested on MacRuby 0.4 however).
>>>
>>> In that game related folder you will also see translations from other
>>> people's opengl work (also only tested on 0.4)
>>>
>>> Cheers,
>>> J
>>>
>>>
>>> On Fri, 22 Jan 2010 09:32:57 +0100, Jonathan Waddilove
>>> <jonat...@waddilove.net> wrote:
>>>
>>>> John,
>>>>
>>>> Thank you for the response. GLUT won't be my first choice but I'm trying
>>>> to follow the examples in the SuperBible.
>>>>
>>>> I'm wondering what the plan is to support all the 'standard' frameworks in
>>>> MacRuby is? Should I be able to process the GLUT.framework with
>>>> gen_bridge_metadata?
>>>>
>>>> Meanwhile I will look at providing my own wrapper class as you suggest. As
>>>> you say this provides a flexible way of handling any framework that lacks
>>>> bridge support.
>>>>
>>>> Many thank, Jonathan
>>>>
>>>> On 21 Jan 2010, at 20:56, John Shea wrote:
>>>>
>>>>> Yes as far as I know bridge support does not support GLUT.
>>>>>
>>>>> So you (obviously) have two other options other than gen_bridge_metadata
>>>>> (which I gave up on after a few tries) :
>>>>>
>>>>> - don't use GLUT - use the equivalent (set of) non GLUT openGL calls
>>>>> - place the GLUT calls in an ObjC class - and call out to that class from
>>>>> MacRuby
>>>>>
>>>>> you might find that the second option is quite quick - i found that for
>>>>> some openGL calls (but not all) that dispatching to my own bridge class
>>>>> which then called opengl functions was quicker than going through
>>>>> BridgeSupport.
>>>>>
>>>>> There are other good reasons to have your own bridge class anyway - i
>>>>> imagine that BridgeSupport is always going to be lagging Cocoa a bit (eg
>>>>> Core Animation constants), and it might just be easier allocating OpenGL
>>>>> texture memory in ObjC (well I still use objC for that)
>>>>>
>>>>> HTH,
>>>>> J
>>>>>
>>>>>
>>>>> On Jan 20, 2010, at 8:14 PM, Jonathan Waddilove wrote:
>>>>>
>>>>>> Hi, I'm back to using MacRuby again and I'm confused about Bridge
>>>>>> Support.
>>>>>>
>>>>>> I have been using the excellent sojaster port of the Cocoa OpenGL
>>>>>> example to help develop an OpenGL playpen. However, when I started using
>>>>>> glut calls (glutBitmapCharacter, glutStrokeString, etc) I started to get
>>>>>> problems.
>>>>>>
>>>>>> It seems that the OpenGL glut.framework (10.6.2) doesn't include bridge
>>>>>> support. I've tried using gen_bridge_metadata to add bridge support but
>>>>>> without success.
>>>>>>
>>>>>> Should glut work in MacRuby? How does one add BridgeSupport to the Apple
>>>>>> shipped frameworks?
>>>>>>
>>>>>> Sorry if I have missed some very obvious step.
>>>>>>
>>>>>> regards and thanks, Jonathan
>>>>>>
>>>>>> _______________________________________________
>>>>>> MacRuby-devel mailing list
>>>>>> MacRuby-devel@lists.macosforge.org
>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>>>
>>>>> _______________________________________________
>>>>> MacRuby-devel mailing list
>>>>> MacRuby-devel@lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>>
>>>> _______________________________________________
>>>> MacRuby-devel mailing list
>>>> MacRuby-devel@lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel@lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>>
>> regards, Jonathan
>>
>> Jonathan T Waddilove
>> email: jonat...@waddilove.net
>> web: jonathan.waddilove.net
>>
>>
>>
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel@lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
