Gosu Forums - Extending Gosu

Recent Precompiled OSX Texplay Package?

jlnr — Fri, 30 Dec 2011 11:08:28 GMT

Don't worry, it gets exponentially more complicated if you need third-party binary gems and want to run on all architectures / OS X versions :)

Recent Precompiled OSX Texplay Package?

RavensKrag — Fri, 30 Dec 2011 06:38:29 GMT

Oh, thanks.

I somehow imagined the process of packing of the .app to be more complicated. I didn't realize that an .app was just a fancy directory.

Recent Precompiled OSX Texplay Package?

jlnr — Fri, 30 Dec 2011 04:55:44 GMT

MacRuby: No.

Texplay comes precompiled inside the wrapper .app bundle, in the download folder linked from the www.libgosu.org front page. It should be in RubyGosu.app/Contents/Resources/lib/texplay*.

Alternatively, you could just move your source in there and hand the whole .app over to your artist.

Recent Precompiled OSX Texplay Package?

RavensKrag — Fri, 30 Dec 2011 04:52:14 GMT

Can someone make a precompiled gem for OSX of texplay? I don't own a mac, and don't want to force the artists I'm working with to install xcode just to install this library.

I would greatly appreciate it.

Side question: would a precompiled package for use with C Ruby still work with MacRuby?

OS X packaging problem with Chingu

semaperepelitsa — Thu, 22 Dec 2011 13:00:53 GMT

Thanks, I've got further. Basic Chingu Window works but my game still doesn't :-(

LSOpenURLsWithRole() failed with error -10810 for the file /Users/sema/Code/am_i_alone/RubyGosu App.app.

Have you got any suggestions?

OS X packaging problem with Chingu

sukisan — Tue, 20 Dec 2011 18:34:59 GMT

I ran into the same issue, wrapping up our LD entry. The reason is that the Chingu version bundled with the wrapper requires a few more gems which are not bundled (Chingu formerly required sockets and now rest-client plus dependencies). I just uploaded the fixed wrapper for you. However, I had to remove an Encoding::UTF_7 somewhere in the uri/common.rb - nothing to worry about, as long as you don't want to use the online highscore, which is probably broken.

OS X packaging problem with Chingu

semaperepelitsa — Tue, 20 Dec 2011 18:16:37 GMT

I'm trying to package my Chingu-based game for OS X following your tutorial. I've downloaded the wrapper app. The example runs fine, but if I change require 'gosu' to require 'chingu' in Main.rb and open the application it closes itself. Executing this with my ruby works fine.

TexPlay: now working in 1.9.3

jlnr — Tue, 08 Nov 2011 12:32:55 GMT

Yay for Texplay progress. :)

If you want to fix Texplay completely, you could make it use Image#to_blob for retrieving image data, and Image#insert to update it back- that would give Texplay support for images >1022x1022. But I think Texplay works with floats and both methods use byte quartets. :(

TexPlay: now working in 1.9.3

Spooner — Tue, 08 Nov 2011 12:23:21 GMT

Sorry, I didn't compile it. I was just using the binary gem compiled for 1.9.2 and it worked fine (I think I might have needed 'Config = RbConfig' before the require; I did for most older gems). Using win7x64 and 1.9.3p0.

TexPlay: now working in 1.9.3

chrismdp — Tue, 08 Nov 2011 12:21:36 GMT

Interesting: I didn't use the gen_eval stuff either, but couldn't even install the gem under 1.9.3-p0 as it failed to compile. I got errors similar to this when including texplay in my Gemfile. How did you manage to compile against 1.9.3 ruby?

TexPlay: now working in 1.9.3

Spooner — Tue, 08 Nov 2011 12:13:48 GMT

I have to admit that I never used the gen_eval in Texplay since it was never very clear where the variables were coming from and going to (I actually use a pure-ruby "partial eval" in Fidgit for cases like this, but it isn't appropriate for Texplay since it is very slow - I use it for creating nested GUI elements which is only done once).

I've been able to use the existing TexPlay release for my own games in 1.9.3 because I don't use that particular feature. So, erm, no point me testing the patch then :)

Regarding the GC, I actually notice it working more in 1.9.3, but only because the performance is so much higher and my current game project has a relatively static display (so I can see the FPS dip every few seconds when I'm drawing exactly the same things - this won't be apparent when I have more going on in the background and my FPS isn't quite as artificially high). I have never seen the effect of the GC in my Gosu games (with 1.9.2), but I did in the game I made with Mon_Ouie's Ray library (I should try that with 1.9.3!).

TexPlay: now working in 1.9.3

chrismdp — Mon, 07 Nov 2011 23:49:14 GMT

Hi all,

Couldn't bear not to have the neat smoother GC in 1.9.3, which starts to deal with the final outstanding issue raised by this post: http://gafferongames.com/2009/01/11/ruby-is-not-at-all-suitable-for-game-development/

Unfortunately TexPlay wasn't 1.9.3 compatible. No longer! I've taken the liberty of patching it to support 1.9.3. I've put up a pull request, but in the meantime use my fork in your Gemfile:

gem "texplay", :git => "git://github.com/chrismdp/texplay.git"

Note: you can no longer refer to instance variables in the image blocks - I needed to head back to using instance_eval, rather than a custom extension, as 1.9.3 removed the API it relied upon.

Enjoy! Feedback on the patch welcome, especially on platforms that aren't OSX Lion.

Chris
http://pa.rsons.org
http://twitter.com/chrismdp

Ruby Gosu Lighting Library

Jwosty — Tue, 01 Nov 2011 23:10:29 GMT

Reminds me of Minecraft! :D

hard rendering

jlnr — Fri, 07 Oct 2011 14:43:22 GMT

The tileable thing can go into the bitmask as well. Seeing true and false in argument lists is really hard to understand compared to enum members.

I am just waiting for the next time I change Gosu's public interface until adding something like that, I think I can use your patch as a starting point, so thanks :)

hard rendering

oli.obk — Fri, 07 Oct 2011 13:35:56 GMT

i could modify my code to use a bitmask.
i just assumed there would be no other settings than smooth/hard.
still can't think of anything now

hard rendering

oli.obk — Fri, 07 Oct 2011 13:32:36 GMT

yes, i just wanted some images rendered pixelated.
so now its an image constructor argument, not a permanent switch.
both can coexist in my code

hard rendering

RavensKrag — Sat, 01 Oct 2011 23:49:50 GMT

Any chance that you could simply add all of these undocumented experimental features into a Gosu::Experimental module/namespace or something? That way they can be tested out, and found relatively easily, even if they are kludgy/undocumented/whatever.

hard rendering

jlnr — Fri, 30 Sep 2011 14:02:26 GMT

Yes, which is why I didn't add it in 0.7.x. The Image constructor does not yet accept an arguments hash (or a flags mask in C++).

hard rendering

Spooner — Fri, 30 Sep 2011 12:43:43 GMT

Well, maybe in 0.8 (or there will be a per-image retrofication system like the OP suggested)?

hard rendering

kaBOOM — Fri, 30 Sep 2011 12:38:53 GMT

Gosu::enabled_undocumented_retrofication needs so serious documentation. ;)

hard rendering

Spooner — Fri, 30 Sep 2011 12:16:49 GMT

Call Gosu::enabled_undocumented_retrofication, at the start of the game, to disable smoothing. I think it does it just as you have, but is a permanent switch for the game. Generally you want smoothing (high-res game) or not (retro-big pixels) so that is fine.

You can also use the tileable flag when loading images to stop tiles being a bit fuzzy at the edges (it copies the image into a texture with a 1-pixel wide border). This may be what you actually want to use, rather than retrofication, if you just want your tiles to tile properly and not to fuzzy up.

hard rendering

oli.obk — Fri, 30 Sep 2011 10:03:51 GMT

Hey everyone.

I am developing a cellular automata renderer/editor in c++.
I'm rendering the state of a grid of any size, by updating a Gosu::Bitmap from that grid and then updating a Gosu::Image from that Bitmap.
Every cell occupies exactly one pixel on the Image.
Now for editing purposes (or even viewing) it is often useful to zoom into the grid.
Doing that with Gosu causes really strong smoothing (cells end up being round and melting into each other).
This is (not always) a good thing here. For viewing it looks (to me) much better, but for editing it becomes very hard to know how to click an exact cell.
I extended the Image class to have another boolean parameter that allows "hard" rendering.
It is a quick way to implement this into the current gosu system without changing too much.
There might be better ways, if there are, please tell me :)
click me for diff file

/ker

Texplay: Editing large images

Trebor777 — Tue, 30 Aug 2011 11:46:48 GMT

I get a similar bug sometimes on my project with texplay on small generated pictures. Very random and rare, but it happens.

Texplay: Editing large images

RavensKrag — Mon, 29 Aug 2011 16:42:24 GMT

In a related error, it sometimes creates images which overlap, apparently. Like, the I'll draw a line in one image, and it'll appear in another one as well. I'm still in the process of trying to isolate the error, but it's a rather weird bug.

Texplay: Editing large images

Spooner — Mon, 29 Aug 2011 14:22:19 GMT

When Texplay creates images, it just creates a huge blob of data (string of null/0x00 characters) and passes that into _Gosu_ that creates the actual image (putting that on one or more textures). If Gosu puts that on more than one texture, then Texplay can't edit it.

Texplay: Editing large images

jlnr — Sun, 28 Aug 2011 19:12:57 GMT

Gosu supports an interface to read and write arbitrarily large images now. Image#to_blob retrieves the whole image even if it's super large, Image#update (or so) write a rectangular portion of it back. If Texplay were updated to use this interface instead of gl_tex_info then there would be no limit on the texture size.

I've been planning to fork Texplay and try and fix this, but plans are plenty :)

Texplay: Editing large images

RavensKrag — Sun, 28 Aug 2011 18:36:46 GMT

Is there any way to increase the size of Gosu::Image instances that can be used with texplay? I believe the limit for the size of a Gosu::Image that can be edited in texplay is 1022 x 1022, or something around there. However, TexPlay.create_blank_image can generate larger images. Is this a result of how Gosu::Image#gl_tex_info is implemented, or could this possibly be changed? I would like to be able to edit images that are as large as the ones I can create.

PostProcessing: A (fragment) shader framework

jlnr — Fri, 26 Aug 2011 02:40:53 GMT

The attachment is no longer available, but I think it was basically this header:

https://github.com/psde/GosuEx/blob/master/Shader/Shader.hpp

Plus example shaders for pixelation etc...

ruby-opengl gem for Windows

Atnas — Mon, 08 Aug 2011 21:17:42 GMT

Sorry for bumping something so old... But I have to say YES. It works. Thank you so much for doing this. : D I've been struggling to get this to work for myself for over a year, and here you go making it so simple!

ruby-opengl gem for Windows

Trebor777 — Mon, 18 Jul 2011 15:23:35 GMT

After seeing some people struggling with the build of the gem on Windows.
I manage to create a valid gem containing only the binaries. :)

Please test!
http://dl.dropbox.com/u/167380/ruby-opengl-0.60.1-x86-mingw32-ruby19.gem

ruby-opengl gem for Windows

Trebor777 — Sun, 17 Jul 2011 13:32:55 GMT

Ruby Gosu Lighting Library

chase4926 — Sun, 26 Jun 2011 17:47:37 GMT

This is a lighting library Ive been working on to give my new projects a special feel.
Features:
+Easy to implement system
+Support for infinite amount of static and dynamic lights
+Unique "blocky" look

Ive made a youtube demonstration of it here:
http://www.youtube.com/watch?v=3c6vDFIWxMI
Don't mind the crappy capturing software and awkward pauses :P

Anyway hope you enjoy it! :D

Updated- Jul 27, 2011

Ruby bindings for Chipmunk 5.3.4

Spooner — Mon, 13 Jun 2011 18:06:49 GMT

I am pretty sure that my problem is all about FFI and not chipmunk-ffi itself. I'll write up what I have though.

EDIT: Just so I don't mislead, the problem I used to have with FFI/Chipmunk is no longer apparent, so disregard my previous comments about it.

Ruby bindings for Chipmunk 5.3.4

shawn42 — Mon, 13 Jun 2011 17:53:48 GMT

Unfortunately the cost of FFI can be great. There is a lot of overhead for a few things like vec2() that can really slow performance if you are creating a lot of vectors. I think it's great that we have both versions of the chipmunk wrapper, let me know if there's anything missing or wrong in the FFI version that I can help with. Can you write up an issue for the windows problem https://github.com/shawn42/chipmunk-ffi/issues

Thanks.

ruby-opengl gem for Windows

Spooner — Thu, 09 Jun 2011 02:28:49 GMT

I shouted at the Ocra guy about ActiveRecord not being Ocrable and it was fixed within a week or so...

So give it a try :)

ruby-opengl gem for Windows

jlnr — Wed, 08 Jun 2011 23:00:56 GMT

You can still help the technical progress of the entire planet though and yell at the author of ocra :) (though by my experience with ruby-opengl, it might just be one of its quirks...)

ruby-opengl gem for Windows

lol_o2 — Wed, 08 Jun 2011 18:02:51 GMT

Sorry for the yelling. I just wanted to compile my game and I couldn't because of this gem. I thought you are going to do something with it (aren't you?).
But I compressed that directory to 2MB and now fixing Ocra doesn't really matter.

Ruby bindings for Chipmunk 5.3.4

Spooner — Wed, 08 Jun 2011 15:42:43 GMT

It is new to the binary chipmunk gem. I was aware that the ffi version was more modern, but I could not get ffi to work on Windows/1.9.2, so I ignored it :P If it worked properly for everyone and was being updated, I can't really see any reason to update this version of the bindings - we don't really need two sets. Although ffi is slower per-call, Chipmunk isn't called too often (that is, you just call its methods on creation of new shapes and a few steps a frame); most of the work is in processing and callbacks.

The use of arbitrary objects seems sensible, though it only really makes sense if that object is queried/callbacked about the collisions in some way too (otherwise, might as well just use symbols).

Ruby bindings for Chipmunk 5.3.4

erisdiscord — Wed, 08 Jun 2011 14:56:27 GMT

Oh, I didn't know it was new to the Ruby API. I think it was in chipmunk-ffi already?

I think I recall that chipmunk-ffi allows arbitrary objects for collision_type, which is potentially useful because you could have a set of standard collision_type objects that determine additional collision behavior. On the C side, the collision type is just set to the object's id. Doing the same for group might be useful in some cases, so why not make it possible?

ruby-opengl gem for Windows

RunnerPack — Wed, 08 Jun 2011 11:42:17 GMT

First of all, yelling at me will not make me want to answer you faster.

Secondly, you didn't really ask me anything, or even provide any new information I can use to help.

Finally, I've already explained I know next to nothing about Ocra. It might be time to ask the Ocra developers, or at least try a forum with a lot of Ocra users, since this has nothing to do with Gosu or the subject of this thread.

Ruby bindings for Chipmunk 5.3.4

Spooner — Wed, 08 Jun 2011 09:55:29 GMT

But there aren't existing programs in Chipmunk that use group, since group was added in this release. Since collision_type is a symbol, I assume that also is wrapped around an integer, but it could just be some sugar for the Ruby version.

Group would be nil or :symbol (which would, in C++, be translated to 0 or Symbol#to_hash respectively). No reason to allow numbers to be used. Alternatively, it could be :no_group instead of nil.

Regarding my issues with general usage, I ended up using twice as many physics steps, but also ensuring that they were all of consistent length, which didn't affect FPS significantly. Skew caused problems, since it seemed to move objects through other objects without collision.

Ruby bindings for Chipmunk 5.3.4

erisdiscord — Wed, 08 Jun 2011 03:37:38 GMT

I can't answer most of your questions with any authority, but I'd like to weigh in on one thing.

> I wasn't sure why #group wasn't also implemented as a symbol

From the Chipmunk docs:

> group: Shapes in the same non-zero group do not generate collisions. Useful when creating an object out of many shapes that you don't want to self collide. Defaults to 0;

The special treatment of 0 here would mean that the Ruby wrapper would need to do some behind-the-scenes conversion. Assuming you want nil to be the "normal" group, you'd either have to make 0 and nil both set the internal value to 0 (strange and unexpected behavior for Ruby, and lossy) or risk breaking compatibility with existing programs (0 might be set explicitly). I would lean towards the second as more-correct behavior, but~

Ruby bindings for Chipmunk 5.3.4

Spooner — Tue, 07 Jun 2011 18:20:15 GMT

I've finally got around to updating my game to use the latest Chipmunk. Particular new features I was able to use was layers and groups which I had sort of implemented in my collision call-backs, which saves me running that code in Ruby :). Also used convenience stuff like StaticBody, Shape#object and vec2() which weren't previously available. Not a huge amount of CPU saved (if any), but a bit less code to maintain!

Sensible that Shape#collision_type has been made into a Ruby symbol, but I wasn't sure why #group wasn't also implemented as a symbol (it is just an integer currently, as I assume #collision_type is in C++ Chipmunk).

You did suggest that you could provide more general answers to Chipmunk problems:

* In my game I managing velocity myself, outside of Chipmunk (chipmunk is there for collisions and sensors, not movement itself, which I want to feel like an old-fashioned computer game, rather than a bouncy physics simulation).Heavy damping is on (#damping = 0) and I #apply_force to each object, run 2 physics frames, then #reset_forces (this in each Gosu frame). This mostly works, but I'm not convinced it is the right way. Should I be using #slew or another method?

* I am struggling a bit with fast-moving objects passing outside my screen (it is wrapped with segments). I assume the only thing I can do to stop this is to limit the velocity of objects or run more physics frames per second? Changing the number of physics frames, however, changes the physics considerably, because of the way I'm applying forces (I think). It would also reduce my CPU time, which is not unlimited...

ruby-opengl gem for Windows

lol_o2 — Sun, 05 Jun 2011 19:50:55 GMT

Hey guy! Will you ever answer? I NEED THE SOLUTION.

BTW, I made something myself. I copied ruby-opengl's lib directory along with executable and changed a bit some files. It's an ugly idea and this directory has above 8MB, but it works.

Ruby bindings for Chipmunk 5.3.4

beoran — Wed, 01 Jun 2011 20:00:54 GMT

Unfortunately, the example code hasn't been ported from C yet, but you can check and run the specifications with rspec:

https://github.com/beoran/chipmunk/tree/master/spec

Also, please read the fine manual :)

http://beoran.github.com/chipmunk/

Suggestions on how to improve the manual are welcome.

Ruby bindings for Chipmunk 5.3.4

RunnerPack — Tue, 31 May 2011 10:16:31 GMT

Installs for me on Win XP. Is there any example code out there with which to test it?

Ruby bindings for Chipmunk 5.3.4

jlnr — Wed, 25 May 2011 01:20:03 GMT

Sure. Hope to catch Spooner for a new Wrath build soon :) After that I can precompile the new gem for OS X and include it in the .app wrapper.

Ruby bindings for Chipmunk 5.3.4

beoran — Tue, 24 May 2011 21:00:52 GMT

And you're welcome. Good to hear that it finally installs! Please do test it, as the devil's in the dark details. :p

Ruby bindings for Chipmunk 5.3.4

jlnr — Tue, 24 May 2011 18:19:57 GMT

Seems to work. Have not tested any games yet but the gem installation went smoothly. Big kudos for fixing this!

Ruby bindings for Chipmunk 5.3.4

beoran — Tue, 24 May 2011 17:59:17 GMT

Ok, I've pushed chipmunk-5.3.4.4 and also a new windows version. This time chipmunk is vendored in the old fashion "dirty" way again.
I hope this time it will work for all platforms.

As a result, it became impossible again to unvendor chipmunk. Ah, well, I guess it's good for performance
and easier for people who want to distribute a Ruby game. :o)