Forum
Does anyone else have problems with requiring the Gosu gem from MacRuby?
normandy:Gosu benko$ irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'gosu'
LoadError: dlopen(/Users/benko/.rvm/gems/macruby-0.10/gems/gosu-0.7.9.1-universal-darwin/lib/gosu.bundle, 9): no suitable image found. Did find:
/Users/benko/.rvm/gems/macruby-0.10/gems/gosu-0.7.9.1-universal-darwin/lib/gosu.bundle: no matching architecture in universal wrapper - /Users/benko/.rvm/gems/macruby-0.10/gems/gosu-0.7.9.1-universal-darwin/lib/gosu.bundle
It's weird, because the version should be attached to the name of the bundle file...
Thanks
EDIT: OK, this is not something exclusive of MacRuby, it's happening to me on other implementations of Ruby too. I'm using RVM to manage different versions of Ruby in a new machine, and I cannot require gosu in any of them :( Other gems work properly, so I don't know what's wrong...
Thanks! I'll try to install macruby via rvm and see if gosu works well with some sample code I have.
Hi, is there a way to sign with one's dev certificates a game made with Ruby/Gosu, so it can be uploaded to the Mac App Store? I'm sorry if I'm asking something obvious, but I've only used Xcode for Objective C/C++ projects...
Thanks!
Besides the C versus C++/Ruby thing, I think Gosu is easier:
1) I find Gosu more 'high-level' and abstract
2) Gosu API is very reduced, compared to SDL.
I find the order of transformations pretty coherent: inner transforms are applied before outer transforms -> first, you rotate and then you translate the result. At least this is what I would expect from reading the posted code :)
Hi Julian, I have the screenshots, should I upload them again?
And about the final version, I couldn't finish it :( Been working the whole summer and now my studies are keeping me ultra-busy. I Guess I should stick to small projects from now on...
> I don't have a gap. Just goes to show that draw_line should not use GL_LINE but instead do it's own magic - GL_LINE is a mess I will never understand :(
:(
> Oh and as far as contributions go, does anyone have any idea how draw_line *should* work? I think it's fine that draw_quad excludes its bottom-right pixel, but I am not sure what to do about draw_line.
draw_quad excludes pixels? Why? If we tell draw_quad to draw a rectangle in the given coordinates, why does it exclude the last col & row of pixels? It's not intuitive (at least not for me).
This is weird. I'm trying to draw a rectangle with an 'outside' border, so I use draw_line with an Y coordinate 1 pixel less than the rectangle's. But the border is drawn with 1-pixel gap!
I don't understand why... If I draw two lines one with an Y of 100 and another one with Y value of 99, they should appear together... Am I right?
Related code:
http://gist.github.com/242335
In order to calculate the projectile's position each frame, you must decide how are you measuring time:
Option A) Frames: you have your speed units in pixels/frame and your aceleration in pixels/frame^2
Option B) Seconds: you can use Gosu::milliseconds to calculate the gap of time between this frame and the previous one. This gap is usually called "delta time". So you can have your speed units in pixels/second (speed) or pixels/second^2 (for acceleration)
Let's assume we chose option B. A simple projectile will have always the same speed horizontally, but it's vertical speed will change due to gravity. When you shoot the projectile, you set some initial variables to these speeds:
@speed_x = 20 # going to the right
@speed_y = -15 # it goes up
In each frame, we can calculate the projectile's position very easily:
# vertical speed changes due to gravity
@speed_y += Gravity * delta
# position
@x += @speed_x * delta
@y += @speed_y * delta
The PDF shows how you can calculate the initial speed (both horizontally and vertically) if you want to aim the projectile to some target. If you decide that all your projectiles will have the same speed 'modulus' (ie, you have an archer shooting arrows with the same 'strength' every time), you just need to calculate the angle of the shot in order to set your initial speeds. Just look at all the data you *do* know and solve the equations displayed in the PDF to get this angle.
I like 7 the most, but make sure you have the right/permission to use artwork you didn't create 100% yourself.
Do you really think that rendering 1000 sprites and getting 50 fps is an "issue"? O__o
Anyway, Ruby 1.9 is much faster than Ruby 1.8, you could try and see how many fps you get...
>I also have another question, for the game menu and that, I would like to get the code split in some files, like a C or a Java program, is this possible? Cause I can't find >anything about googling o_O
Yup. I posted a small game/tutorial which uses one file (actually one class) for each screen:
http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=509
>In either case, we have been discussing adding this feature natively on IRC a while ago. Let me know if you can come up with a good name for "scale by doing pixel
>repetition" as an alternative to :default and :tileable ;)
:retro ;)
Isn't its real name bilinear filter? What's wrong with :bilinear ?
> or I could allow the user to set it how they want,though how is this done in code?is there an easy way?
keys = {:left => Gosu::KbLeft, :right => Gosu::KbRight, :up => Gosu::KbUp, :down => Gosu::KbDown}
Now instead checking against a Gosu button constant, you would check against this Hash. You have to make this Hash accesible by the classes who need it.
I think that some kind of class which allows to render particles of the same particle pool at once (instead of calling hundreds of times Image.draw each frame) would be useful, since it would speed up particles systems.
Note that I'm not asking for a particle system class, but for some kind of Gosu::Image group that renders every element of that group in the same OpenGL call.
Yesterday I presented my project at university in front of a tribunal and this video was part of the presentation:
http://www.youtube.com/watch?v=mfTRZOhQQnECurrent goals are finishing 100% the engine and the small example adventure. I'll keep you up to date!
>The game will run at normal speed on my computer as long as the levels do not have too many objects (dogs, guards, lava, items, etc.) and as long as not too many tiles are on the screen at a given camera position. Thanks to the advanced tile update method I'm using, levels can be as big as they want to be tile-wise without slowing down.
I don't know if you're already doing this, but a trick to avoid the slow down when a level has many objects (items, enemies and such) is to "freeze" somehow these objects until they are close enough to the main character (usually a portion a bit larger than the screen), so you don't run the update method in them.
This is not related to Gosu itself, it's about the forum.
I don't know if this is only because of my browser (Safari) or because I haven't understood how the forums work yet. The forums display unread threads/subforums in yellow. The thing is that when I read a thread it doesn't get marked as read ---it does with time, though.
So, how is it? I've tryed to click on the subject of each message to mark it as read but it doesn't work neither :(
Another thing that I can't manage to do is to quote someone. I click on the quote button down someone's message but my reply doesn't appear with a quotation.
Am I missing something? Should I use another browser to access to these forums?
Shinobi, you're very enthusiastic, and that's nice but I think it is better to relax and think calmy before jumping to do lots of things. We have to take into account that Gosu community is small because the project it's young (although the lib is very usable, let's not forget that it still hasn't reached version 1.0).
Are we, as a community, ready to support a long-term competition? I don't think so. There are a lot of short games, but long games are rare. This is because developing (and not abandoning!) a game for 6 months or more requires dedication and that doesn't happen so often. I mean, let's suppose we have 10 development teams creating a game for 6 months each. From those 10 teams, the odds are that only 1 or 2 will reach their goal (finishing the game).
On the other hand, short compos usually have more entries. This is because it is easier to spend just one week (or weekend) to a project, than spending 6 months or a whole year. For a small community, short competitions are better IMHO.
But the thing is that there is one short competition, the Ludum Dare. If we decide to create another competition, we must think the reasons we want a new one instead of just joining Ludum Dare.
In my case, I've been wanting to participate in one Ludum Dare but for one reason or another, I've been busy on those weekends. I'll try to participate in the Ludum which is goint to be held in August, though.
So the questions might be:
- What things we don't like about Ludum Dare?
- What thins we can do better?
- Is it worth it?
Why don't you try it out on your computer and measure the performance? I think that is the best way to find out (and don't forget to share your results with others).
By the way, I haven't measured it yet, but I have noticed a impressive boost of performance by using ruby 1.9 instead of 1.8. I'd go with that and forget ruby 1.8 :)
It's 100% point & click. And no, the player does not have to click exactly on one node. The player clicks in an empty area (ie, not an item or character) and the engine calculates the closest node to that point and the character walks torwards that node. You cannot interrupt a movement (stop), but you can change the destination by just clicking in another empty area.
In addition to that, each item and NPC has a node assigned, so when you try to interact with them (use, talk to, pick up...), the character first walks to that node and then performs the action :)
I think there should be a function to get some kind of identifier (the scancode could do the job, I think) of the key pressed by the user. For example, if we want to include customizable controls in the game (to let the player choose which key/button wants to use to do some action). Maybe this could be done (getting the key pressed) with TextInput but maybe could cause troubles with compounds characters like é or ü or something like that.
Thanks! :)
Yes, the nodes are a movement path. Even more, each node can have its own size and Z, and that affects the character. So, you can make the main character bigger or smaller (for perspective effects) and change its Z coordinate to make him pass behind a streetlamp, for example.
Right now I'm looking for a video recording software to grab a short video showing this, but the ones I tried only record at a low fps rate :(
In order to get my Computer Engineering degree, I have to develop a project during the last year at university. I chose to develop a 2D graphic adventure, but in order to do so, I somehow created my own "parser".
So my project is a framework/engine/parser (whatever you want to call it) and a small adventure which uses this engine. The engine is called Grog, and the adventure has no working title yet.
I've used Ruby and Gosu to code this project. It's been great! If it weren't for Ruby and Gosu, I couldn't have finished it on time (and wouldn't have had so much fun). So, many thanks, Julian, you rock!
The engine, Grog, is pretty much finished, but the adventure is still on development, mainly because of graphic resources. A friend of mine,
Silvia Coleto is drawing the backgrounds and I have to draw the characters. I need to present this in front of a tribunal the 19th June, so I better finish the adventure soon :)
I plan to make the engine's code free software. However, since I was no Ruby expert when I started to program it (and I'm still not!), the code from the beginning is kind of ugly, compared to the most recent. However, I think it could be useful for some people... so I'll probably do a little bit of refactoring and release it under GPL or MIT.
AFAIK, Gosu is covered by the MIT license, which allows you to do pretty much whatever you want as long as you give proper credit.
I think the current logo is OK. Maybe it'd be great to have it in SVG format (or a large PNG) and in several colors, though.
@jlnr
You were right about both bugs. I totally forgot that the array "shifts" its elements when you do a delete and that messes the array.each loop. Now the code for updating the sprite lists looks like this:
# Updates all the sprites in the collection
def update
@sprites.each_value do |list|
list.each {|x| x.update}
list.reject!{|x| x.die?} # delete all doomed sprites
end
end
I think it should work now properly, since the sprites don't delete themselves from their own sprite lists until the full sprite list (ie array) has been looped. And now you cannot kill bad guys while you're dead ;)
PS: Thanks a lot for your hard work with Gosu, it's really an amazing lib!
Sorry for the delay in my reply, but these past weeks had been very intense in university. I tried what you suggested, but I have some missing frameworks so I cannot compile at all. Thanks anyway!
I will check Julian's bundle to see if it works.
Hi,
I'm trying to compile a Gosu bundle for OSX (Intel) which works with Ruby 1.9. Any tips on how to do that? In other thread Julian said that Gosu seems to work with Ruby 1.9 if built against correct libraries. Which ones?
I'm totally new to XCode, so I'm really lost with this. Any help would be greatly appreciated.
Thanks!
Thanks for your reply! Keep up the good work, you're doing a great job with Gosu :)
Hi, I was wondering how I could change the game resolution and switch between fullscreen / windowed mode while the user is playing the game. Since the only way to create a window is by the constructor of Gosu::Window, I'd have to destroy the current window and create a new one. Problem is, game resources such as images, fonts, etc are attached to a window (i.e, you pass a pointer to the current window when you call Gosu::Image constructor, for example). Because of this, I would have to reload all game resources again.
This approach could work in your typical options menu accesed by the start screen. But I don't think this is acceptable while the player is playing a level (for example, he presses Alt+Enter to switch between fullscreen and windowed).
Is there any workaround in Gosu's current version? And in future versions?
Thanks!
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill