Forum
I would deffer to less technical terminology and call it something like "color blend," as from what I can tell, that's the intended use case. You want the image tinted a specific color, with a specific "magnitude" of that color being used to tint.
Or just call it "tint." That's probably better.
I'm almost positive the OP wants a function that can be used like a minuscule ruby photoshop. Just select an image, apply a tinge of color to the whole image, and then BAM. Done. This operation sounds similar to locking transparency and dragging a big semi-transparent brush over everything. No hassle for the coder, just easy results. I would find that sort of library highly desirable myself, although I can imagine the coding might get a bit intense for whoever had to implement the library.
> But then again, it's annoying LGPL :(
As opposed to GPL? I thought LGPL was less restrictive?
Hmm... interesting, I unfortunately have to say that I get the segfault instead.
> it would be interesting to have a thread like this to list testcases for the mentioned problems
Wouldn't it be better to use the google code issue tracker for that? Here's the webpage, in case you didn't know about it.
http://code.google.com/p/gosu/issues/list
Wow, this is much more simplistic than the way I was doing it, that's for sure. I was dividing by the exact number of milliseconds to get a FPS value as a floating point decimal instead of the way you're doing it which just basically assumes that the time elapsed is close enough to a second, and that an integer value is good enough.
Personally, although it lacks precision, I prefer your method. I assume it's faster, and it's certainly more elegant.
If the 'window' arguments are removed, will Gosu function in a manner similar to Chingu, with a global $window?
Agreed, now I could actually sell my game if I wanted to. Not that I see that happening any time soon, as I would first need a game to sell ^_^; but still, thanks for that.
The fact that as a result we now have the ability to alter the speed is pretty cool as well. Don't see an immediate use for that myself, but I know how good the audio is in Braid as a result of having effects like that. It should be cool to see what people do with it.
Looks pretty cool. The fps thing is pretty common, so I'm glad that's part of Gosu now. It was probably a lot slower doing the calculation in Ruby, at least the way I was doing it.
I have scoured the net looking for answers and have found none. Not even on the site for chipmunk-ffi itself on github, which I find rather strange...
Regardless, my question is how do I get chipmunk-ffi working with ruby? I see that it's looking for a file, but what file would that be? Some sort of chipmunk executable I would presume, but where is that stored?
I had been all about using the standard chipmunk gem which seems a lot more straightforward from my perspective until I learned that certain features are missing. So I though I'd at least take a look at the competition. Also, apparently the C extension version doesn't work on MacRuby, and I'm starting to think that is a better means of deploying my open-source game on OSX than having my users install the latest version of ruby through MacPorts.
I believe it would be the classic memory for speed trade off, but the amount of space would probably be negligible. Why don't you try it yourself and benchmark it, then let us know? I'd be interested in how that works out myself.
Ah, ok, well if you already have a graphics library, then I suppose it might be a bit of a pain to retool... err, I suppose that's more like refactoring? idk.
I'm still not so sure why you're so intent on preserving this interface. If you're worried about the efficiency at a low-level, wouldn't it be more efficient to cut the image into tiles, so that way you don't have to compute the coordinates of which image to use every frame?
Totally agree about slicing up the image. Though I would argue that if your tiles are not organized in a "sane way, keeping related tiles close to each other" that your tiles need to be rearranged. Though, if you're chopping the image up anyway, it shouldn't be that big of a deal.
Well, that's a bit of an oversimplification... ^_^; but still.
I was just about to mention this. Although, I have heard that ruby's gc is slow, it doesn't seem to matter (speaking anecdotally) unless you do it really frequently.
> What if that's not a good idea, because for example you want to load a huge image once (with 10,000 tiles)?
I believe it is documented that #load_tiles can take either a filename or a RMagick instance. However, I believe that in Gosu RMagick instances and Gosu::Image instances are interchangeable. Thus, you can load the whole spritesheet into memory first and then split it.
The code would be something like this.
spritesheet = Gosu::Image.new($window, path_to_file, false)
sprite_array = Gosu::Image::load_tiles($window, spritesheet, width, height, false)
I can confirm that this works, as it is how I am doing it. However, I'm only doing it this way because I need to composite multiple images into a single spritesheet, and divide the resultant image into tiles.
However, if you're loading that much into memory at once, I would say that you have a problem. I would suggest loading only what you need into memory, and thus storing the spritesheet in smaller chunks. However, reading from the disk is quite slow... so I guess it's more of a personal choice. I personally don't like it when apps take more memory than then need though. I imagine that 10,000 tiles would take up a good deal of memory, however.
Once you get used to the flow of Gosu I believe you will see that it is better (ie more intuitive) to chop up an image into sprites/tiles and draw those. I am assuming you're new to the engine as you are new to the forum. Please excuse me if I am mistaken.
> I wouldn't think that using ... would be a good idea
Yeah, I would advise against that as it looks unwieldy, and it is probably going to be slow. However, if you really want a similar feel, you could take the array generated from #load_tiles and parse the elements into a hash with the keys being related to the position of the tile in the overall spritesheet. Although honestly, like I said before, I really don't understand why you would want to do it that way. Feel free to explain it to me though, I am genuinely interested.
It caused some other issue before though. Unfortunately, the code that triggered that error was so horrendous I simply trashed it, so I couldn't tell you exactly what that problem was... The traceback put the blame somewhere in Gosu::Image#clone or #new, so it could be related to this.
I'm really just taking vaguely-educated stabs in the dark though.
Took me a while to understand how that would happen, but I get it now. Made sure to add that to the code. This has the added benefit of short-circuiting the check if the dimensions of the images are not the same.
Good point about using #is_a?, I'll change that right away. However, correct me if I'm wrong, but I believe as Texplay edits the Gosu::Image class itself, rather than creating a descendant class, this should not be a problem in this instance.
Ah, I had meant to do arg.==self, but I suppose it's really just better to return false. Will do.
I already checked to make sure both variables were instances of Gosu::Image. I simply did not include that in this snippet.
Thanks for the help, although these changes still do not fix the problem.
Yes, I do have texplay required.
On the topic of texplay, I noticed that texplay defines Gosu::Image#new instead of Gosu::Image#initialize, which I thought was weird, but I suppose that's a bit off topic... I just remembered I took a brief look at that part of the code, and thought it could be possibly related.
Actually, as a result of the way I have the Chipmunk integrating going in my game, finding the rectangles is fairly trivial.
Alright then, I'll just try to avoid this problem for now. Thanks for the help. I'll try to look into stencil buffers later on.
I'm getting a very odd bug here.
img = Gosu::Image.new($window, "./Sprites/Effects/Aero.png",false)
img2 = img.clone
assert_equal img.to_blob, img2.to_blob #This works fine
assert_equal img, img2 #This does not
I have defined Gosu::Image#== as follows
def ==(arg)
if arg.class == Gosu::Image
return self.to_blob == arg.to_blob
else
return self.== arg
end
end
Can anyone tell me why this does not work?
I had the exact same idea. The problem with this is that it starts to get weird when you have non-rectangular objects, doesn't it? For now I'm simply using pixel-perfect rectangles, but I wanted to be able to expand beyond that and have various sorts of buildings and such.
I think for some reason I thought that it would get to expensive to draw the shadow on the floor and then draw tho box on top of it. Perhaps I just don't know what I'm talking about ^.^;
Also, I had somehow thought that this would require some odd coding flow, but I suppose simply using the z-index would take care of ordering the drawing.
Am I just over thinking this? That does tend to happen every so often...
Ok, I suppose I should go into a bit more detail then.
I'm making a top-down game and thus am working with a psudo-3D environment. I need to constrain the drawing so that, for example, if the player was jumping over a box, the shadow would only appear on the top of the box. I would then draw another shadow on the ground. This is so that the shadow does not show up on the sides of the box, as that would be weird. Also, as the ground's surface is a different distance away from the player than the top surface of the box, the shadow size and opacity should be different.
Just imagine what it should look like, looking straight-down from the top and seeing a shadow resulting from light which comes straight down. This would appear as simply a circle. However, if you use a top-down perspective a-la the 2D Zelda games, then then just using a circle would be weird, as in this perspective you can view the top and sides of a building, box, or what-have-you in the same plane.
Hope that's clear enough and everything makes sense >.<
If you draw out a picture of what the scene should look like as seen from directly above, and then try to draw the same thing from the typical top-down psudo-3D perspective, I think you'll see what my problem is.
I know there is Gosu::Window#clip_to method which allows constraining drawing to a specific area. Is there a way to constrain the drawing to a instance of Gosu::Image instead?
I'm trying to draw shadows by overlaying a semi-transparent black circle over other images. As a result, I can't use texplay for this as it would be too slow to process this every frame. Feel free to correct me if I'm wrong though.
I assume that this is possible using OpenGL or something, but I was curious if it was already implemented somewhere and just was not documented, or if there was some code that someone else was working on that would point me in the right direction.
Works fine now, thanks ^_^
Did you add any extra dependencies? I seem unable to get the gem to build.
Here's the error I got, posted to pastebin.
http://pastebin.com/511uwsz3
Regaurding the ruby-opengl gem, on Ubuntu (and I assume thus, on Debian) there is a package in the repository which should be used instead of the gem. libopengl-ruby1.8 or libopengl-ruby1.9.1, depending on which version of ruby you are using. Strangely, the 1.9.1 version is the one for 1.9.1. Additionally, ruby1.9.1 likewise installs 1.9.2, at least on Ubuntu 10.10.
Touche XD
However, I don't play much anymore. Got pretty into mulitplayer, but my friends haven't played in a while so... yeah.
I've heard that the multi-window implementation of GIMP is useful if you have a multi-monitor setup. Also, I personally think it's less of a hassle if you use OSX or Linux and have multiple virtual desktops. I normally have one virtual desktop on Ubuntu dedicated to GIMP if and when I have it open.
Still, personally I don't really see how I would use this in a game, although I am generally bad at thinking up ideas for interfaces anyway.
Allowing one window to be resized would be quite nice. I never noticed how cool that feature is until I played minecraft, which is the first game I had played which allowed setting the resolution in that manner. Much more flexible than using a list of pre-determined values for window width and height.
Ah, I hadn't thought of any of those problems at all... Though I was just kinda asking this out of curiosity, as it's not really something I'm interested in implementing. Although I was a bit surprised before that I've never seen a game with a multi-window setup like GIMP before. Perhaps this is why...
Well, thanks for putting an end to my curiosity at least ^_^
Though as for that corner case, you could have Gosu::mouse_x return the position of the mouse relative to the currently active Gosu::Window. If the currently active window is none of those windows then you could return nil. Of course, I can think of a couple other ways to implement that myself, so I'm sure you've though of that one as well as many others. Might as well just stop myself right there then.
I believe this was being discussed in another thread, but I can't seem to find that and it was a bit off topic where it was so...
On the topic of multiple windows with Gosu, I personally feel like the core of Gosu should manage the state of the game, and as many windows as one wants can be created to display output. Thus, #update, #button_up, #button_down, etc would move to something like a Gosu::Game class, with Gosu::Window basically just having #draw. You could still have #draw in Gosu::Game I suppose, but it would basically just call #draw for every window. Thus, the programmer would only ever want to override Gosu::Window#draw, as is the current style.
I wanted to bring this up because thought that the core of the engine being a class called Window was a little odd. This approach might seem more complex to some people, but to me it just makes more sense. Would this be possible down the road or would this simply be out of the intended scope of Gosu?
I'll just mention this issue here instead of on GitHub as I see you already closed this issue, and I'm just looking for clarification.
Did you implement Gosu::Image#== or some similar method? I tried to call it, and it did not work. The method simply uses the default implementation (defined in object I believe) which is the same as #equal?. It's simple enough to just monkey-patch it in, but I just wanted to make sure this was not a bug.
Side note: Oddly enough, the first time I ran a test for this, the address for the clone had the letters "bad" in it. Just thought that was funny.
Oh yeah, totally agree that the gems should be separate, just thought Gosu could install TexPlay as well. But I guess some people might not want that, so it'd be better just to let them install the gems separately? I don't know ^_^;
While on the topic of advancements to TexPlay I'd like to have the ability to draw ellipses and the ability to get some anti-aliasing on curved shapes. (this is why I use both TexPlay and RMagick in fact).
Also, I agree, having TexPlay be included with Gosu as some sort of dependency or something would be pretty cool.
I have to admit, the animation stuff it looks interesting, but I don't completely understand it. Perhaps if I look at it a bit more I'll get it ^_^;
I've got some stuff in place in my code already to provide an interface layer on the Chipmunk stuff, so when I get the time (dang finals...) it shouldn't be that hard. Well, in theory anyway. Though, I question the wisdom of essentially putting a wrapper on a wrapper, it is convenient. However, I suppose if I wanted sheer speed I'd be using C/C++...
Though as a general note, I'd be happy to submit patches, as I can see a few areas already where the code could be cleaned up.
Seems like Chingu is just getting better and better. I would switch, but I think the time it would take to retool would not be so good. Plus, I'd have to reimplement a lot of stuff for the rather eccentric way that I'm handling sprites. I might just copy some things like the state manager, timer, and edit state ^_^;
If I have the time though, I'll try to whip up some Chipmunk integration stuff. No reason for more people to go through that than necessary...
I don't see why not ^_^ If the implementation in unclear, let me know and I'll put some documentation in there, or whip up a quick example.
Bump: Code has been updated with new Combo input type.
EDIT:
The original gist has been removed. If you still want tho code, do not worry, as I have simply moved it into my regular github repository. The link will follow.
https://github.com/RavensKrag/eternity/blob/master/Utilities/InputHandler.rbChad Godsey uploaded a class called InputHandler a while back, but the Ruby version was a bit unruly for my tastes. Thus, I have rewritten it, using more object-oriented programming instead of the nested hashes found in the original code. I think my version is much easier to understand and extend, but that could just be me.
I'm currently working on an additional input type called Combo, which will detect button presses that are a certain amount of time apart. This spacing can even be different between button presses. I'll try to remember to post that up as well once that's done.
Thanks again to Chad Godsey for the original code.
FOR LINK SEE ABOVE
I had a hunch that this error had something to do with filenames, so that makes sense to me. The hunch comes from file names/paths screwing up my code as well.
I believe there is a C backtrace included in the segfault message I posted earlier. Will that not do?
Just to be certain the error is the same, here is the latest error message.
http://pastebin.com/udsz8hwb
Nope, no change whatsoever.
Also, note to lol_o2, your code is quite obfuscated, from what I've looked at o_O; Particularly specjal.rb. It looks more like C than Ruby. I like one-liners as much as the next guy, but I really think you should space out some of that stuff. I have a feeling some of that stuff is to deal with collision detection, but man... I can't make heads or tails of it. Wouldn't it be better to get some abstraction in there? Idk, that's just my opinion. I'm using Chipmunk just so I don't have to deal with collision detection ^_^;
I'm using the latest version of Gosu, on Ubuntu 10.04, 64-bit. My ruby version is ruby 1.9.1p378 (2010-01-10 revision 26273) [x86_64-linux], as stated by ruby -v. The segfault happens immediately upon starting this particular application.
I am writing a game of my own using TexPlay, and it does not have this problem. Normally when TexPlay crashes for me, I get some sort of useful error about how I made the image too big or something. Though, occasionally TexPlay just eats through my memory and crashes my computer without any useful error. But that's a topic for another thread ^_^;
Ah yes, so I think my solution will work for you as well. Here's my algorithm.
Make a circle of a moderate size in TexPlay. ("moderate" depends on the size of your other sprites)
Compute the scale needed to generate the shadow needed (or in your case, light)
Draw the circle using Gosu::Image#draw and passing the appropriate scale factors for x and y.
This way, you only need to create one circle. However, I think there might be a problem if you scale the image too much, as the edges might get too choppy. Haven't gotten to dealing with that problem yet. Just thought of this solution the other day myself, and haven't had time to extensively test it, but from what I've seen it should be considerably faster, and perhaps use less memory.
Oh... actually, the game seems to generate a segfault in TexPlay on my machine. Here's a link to the error message. I put it up on pastebin as it's a bit long.
http://pastebin.com/WLFZq2LB
I was merely saying that I didn't have time to look into your code at that moment. But I didn't think you were distributing source for some reason. I apologize for my incorrect assumption. I knew you were using ruby, but thought you were using the rubinius implementation to compile the code, thus eliminating the need to distribute source. This seems to be fairly popular decision, and thus my assumption.
However, I have actually downloaded the code now, so I suppose I'll take a look.
Hmm... are the circles the same size each frame but in different places? Then you could just draw them as separate Gosu::Image instances instead of compositing them into one image. However, I assume you would have already though of that. If the circles are of different sizes, you could scale the Gosu::Image used to hold the circle to the correct size when calling #draw. I am currently using this latter method to draw simple shadows in my game.
Any idea what's causing the slowdown? From what I've seen using Gosu, this seems to happen when making a lot instances of of Gosu::Image. If this is your problem, perhaps you could refine the code somehow? This sometimes happens to me when I use TexPlay. Can't really say anything more specific without looking at the code though ^_^;
Is there any chance of getting a 64 bit gem built? It doesn't really bother me, as I suppose I can just tell people to install the devkit when they install ruby. However, just though I'd ask.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill