Forum
Nope, not without additional OpenGL hackery. Or you can use Gosu::clip_to to render the background again, clipped to the window/door rectangle on a tile, but that's only efficient if the background is very simple (a static image, for example).
It should be easy to generate each tile/cutout combination using RMagick.
The issue has been fixed in RubyGems 2.5.1. You can keep the installed 0.10.5.pre2 gem until I release 0.10.5 (hopefully before 2016), and then just gem update gosu to install the normal version.
RubyGems has fixed the issue now :)
Are you using plain Gosu to render? Then it should be as easy as Gosu::scale(1, -1, 0, window.height / 2) { ...draw everything... }
Are you rendering to an OpenGL texture? If so, can you simply invert the matrix while you are rendering, so that the image data won't be inverted to begin with?
Hey, thanks for reporting this issue...and for diving into the hell that is Macro.cpp :)
Gosu originally used "reading order" for coordinates everywhere: top left, top right, bottom left, bottom right. (I think this was a Direct3D thing, but I'm not sure.)
But everyone except me seems to prefer clockwise coordinates, so while Gosu uses "reading order" internally, it now accepts arguments in both(!) orders.
And here comes the bug: I forgot to translate clockwise coordinates into "reading order" in Macro::draw. I've pushed a commit and will release a new version of Gosu once I've verified that Rubygems 2.5.1 does not break my pre-compiled Windows gem anymore. In the meantime, you can just swap the parameters to Image#draw_as_quad and everything should work.
I don't understand the advantage of launching Gosu from a Rails project. If you are not running a web server, then why use Rails? If you just need all the niceties that ActiveSupport brings to Ruby's standard library, you can also require them in a plain Ruby/Gosu project:
require 'active_support'
require 'active_support/core_ext'
This is usually the symptom of a computer that does not run Gosu with hardware acceleration, caused by outdated graphics drivers. You could try to find other games/demos that use OpenGL for rendering (not Direct3D) and compare.
Oh, you'll still need to draw things up to 5 times, depending on the camera position. I just wanted to say that the math for this is simple, since you've mentioned trigonometry - but I see below that you're already using a very simple formula :)
I've used fake 3D boxes in a few games and was quite happy with the results. Usually, what I've done is just to calculate the x/y delta of each vertex to the screen centre, then multiplied it by 1.1 or some other value > 1.0. Then I use
draw_quad to connect the original vertices and the offset vertices, drawing up to five images per box.
So if part of your problem is that your math has become tricky, you can maybe simplify it like that :)
Very simple fake 3D in action ->
http://ludumdare.com/compo/2009/04/19/starferret-48h-final/
I don't know if any good tools for this task exist. But if I had to do this, I'd write a plain Ruby/Gosu tool that lets me drag rectangles on the graphic and cuts up the image, rearranging it into a grid of sprites where each image has the same measurements. Then you can either load it with Image.load_tiles (easy), or as a several 1024x1024 images with Image.new and use .subimage() to load specific sprites (that'll be a little faster).
I would also suggest using @lower_case for variables and instance variables. UpperCase is only used for constants in Ruby.
Is it just this test script that is broken? Have you tried the OpenGL example in gosu-examples (gem install gosu-examples, then run gosu-examples)?
I can't get this particular test to run either, but that's probably because I have no Glut on my system.
Does it work if you first install Gosu (with --pre, as before, not with --platform) and then install Texplay?
I don't think there will be a Texplay update anytime soon, and the current gem is only precompiled for 32-bit Ruby on Windows, anyway. In the Rubygems issue thread above, it seems that 32-bit Ruby might be unaffected by the issue altogether.
Does downgrading to a 32-bit Ruby fix everything for you (for now)?
The issue is caused by this bug in Rubygems 2.5.0:
https://github.com/rubygems/rubygems/issues/1369To work around the issue, I've pushed a Gosu 0.10.5.pre2 gem that is ONLY available for Windows. So if you run
gem install gosu --pre now,
gem has no chance but to install the Windows version.
Ah, I see. Updating Rubygems itself has broken Gosu here too. =( I hope all I have to do to fix this is to release a new gem. Hope to try that tomorrow.
Thanks for analysing the issues with
gl_tex_info. I am a complete idiot when it comes to OpenGL, so I'm glad that the feature even works as well as it apparently does!
Fixing the first issue would be relatively easy by introducing a
:single_texture => true flag in the
Image constructor. (This would also fix the second issue.) I don't have the time to release a new Gosu version in the next days, though :(
As for the second issue, you are right that Gosu uses inverted Y coordinates - but at least it does so consistently (y=0 is always the top). Here are the calculations for
gl_tex_info:
https://github.com/gosu/gosu/blob/master/src/Graphics/TexChunk.cpp#L11-L14If you want to translate the coordinates to a bottom-to-top coordinate system, you can use
1 - tex_info.top and
1 - tex_info.bottom.
I guess you could even add a few helper methods on
Image or
GLTexInfo to wrap away all these calculations.
Can you please try upgrading Rubygems itself (gem update --system)? gem install should install the right architecture (pre-compiled) even without the --platform parameter, but every few years there is a bug that breaks this logic. Sigh :(
Yes, try this: "Hello <c=ff00ff>World!</c>"
I'm afraid the syntax is VERY poorly documented, but for now this should do the trick :)
Yes, that was usually necessary because the Player class wanted to load images, and Image.new required a window reference. That is not the case in Gosu 0.9+.
In any case, the easiest workaround was to use a global variable called $window throughout your app, and set it in YourWindowClass#initialize (right after the super call). You could also use the Singleton module from the Ruby standard library, but I am not sure if it has any practical advantage over a global variable.
Did you perhaps copy the wrong link there?
I think you are referring to the interface changes in Gosu 0.9+. Previously, you had to pass a
Window reference to
Gosu::Image.new etc. (for 10 years!) - that has changed in Gosu 0.9, half a year ago.
The old overloads are documented in Gosu's rdoc, and are not likely to go away anytime soon:
https://www.libgosu.org/rdoc/Gosu/Image.html#initialize-instance_methodI would guess that at least 95% of all Gosu code ever written still uses the old interface.
If you see a tutorial that uses the old interface, maybe you can help the author migrate it to the new one? I've been meaning to to ping the authors of the various Gosu Tutorial translations, but I haven't found the time yet.
Imagine that the implementation of Window#show looks like this (pseudocode):
def show
show_OS_window_on_screen()
while not self.closed?
self.button_down(x) for each x that the OS reports
self.update()
self.draw()
sleep(16ms)
end
hide_OS_window()
end
When you create a second window and call .show on it from within button_down, you will have two nested while loops, one for each window, and the outer loop will be stuck until the inner while loop completes. So the first window never has a chance to clean up and hide itself.
The only way around this is to wait for the first call to Window#show to return (doesn't matter if you've manually called close or if the user clicks the X), and only then show the second window. So, more like:
Launcher.new.show
puts "the first window has been closed now"
GameWindow.new.show
The global variable was just an example for you could pass data between both windows. I don't know what your launcher actually does, so please ignore that bit.
This also happens when the user closes their laptop and opens it up on the next day. I think limiting dt is the way to go, but to be honest I haven't ever built a dt based game.
button_down is called in the main loop that Launcher#show starts. So basically the launcher window will be stuck forever in its loop, waiting for the whole main Window#show loop to finish. The call stack will be (among others) main > Launcher#show > Launcher#button_down > Window.show.
You'll have to store the launcher settings into some sort of global variables, then let the launcher close itself, and then create the new window. Something like:
Launcher.new.show # stores settings in global $settings_from_launcher
# .show returns at some point because .close was called
Window.new($settings_from_launcher).show
(Assuming that the point of the launcher is to decide on settings)
Hope that helps (and works-haven't tested it)!
Which version of Gosu do you use? Closing and opening windows should work fine in the current version, the only limitation being that you can only .show one window at a time.
Wow, the indoor screenshot looks awesome, and the transition to battle even more so!
Also liked this rotation demo in the forum thread:
http://img107.xooimage.com/files/6/9/8/maison-45ee599.gifLet me know if you encounter any problems in Gosu! Great work. (And I'm a little jealous at how busy the RPG Maker forums are :P)
Awesome! Thanks for reporting.
That's strange, which was the last version of Gosu on which it worked? 0.10.2, 0.10.3 or 0.10.4? Can you provide a minimal example? (Probably just an empty window with one call to Gosu.draw_rect?)
Yep, but it was still a bug in Gosu because LOTS of code still uses the old interface, and I'll probably have to support it forever :) Anyway, great to know that it works now.
Another release with only a single bugfix:
• Ruby: Fix compatibility with Gosu 0.8 interface (Gosu::Image#initialize; GitHub issue #360)
Oh man, in retrospect that was a really silly oversight on my part. Anyway, should be fixed in Gosu 0.10.4.
Oops, I can actually reproduce it now.
Creating subimages is probably cheap enough that you can do it in every tick. Images are not much more than a refcount to the texture, plus u/v values.
Doubled is not possible right now, though :(
Hey everyone,
I didn't really plan on releasing another version of Gosu so quickly, but this issue came up several times on this forum:
• Fix black/white empty window before Gosu::Window#show is called (issue #280)
Let me know if the fix works, and whether it has broken anything else.
I guess it's time to add features again, instead of squishing bugs! Nice :)
I've created a new GitHub issue here:
https://github.com/gosu/gosu/issues/300But here's a workaround you can try in the meantime:
If you load the image using
Image.new, then use
image.subimage(x,y,w,h) to create a
Gosu::Image representing a portion of the image, and then call
gl_tex_info on the new (sub-)image, you should get the correct u/v values (0.0 to 1.0) in
.left/
.right/
.top/
.bottom.
You only need to take care not to create an image >1022x1022px with
Image.new, because when an image is split up across several textures,
subimage and
gl_tex_info won't work.
I'd suggest lazily generating these images during development, and then at some point you write them all out to PNG files. That way your players don't need to have ImageMagick installed on their machines.
Which OS and which version of Gosu do you use? And which keyboard (US, French, ...)?
I've opened a new issue for text input bugs on OS X, maybe I can fix some more bugs at the same time:
https://github.com/gosu/gosu/issues/299
Oh, I didn't know that about TexPlay. =/
Hi and welcome :)
1. Instead of rewriting methods on Gosu::Window with class_eval, you can just add a setter to your own Window subclass:
class MyWindow < Gosu::Window
...
attr_accessor :cursor
def initialize(...)
...
# Neither default cursor, nor a custom cursor image - I think this makes for nicer code than ""
@cursor = false
end
def needs_cursor?
@cursor.nil?
end
def draw
...
if @cursor then
# This is a bit of a hack - it's probably better to cache cursors indefinitely in a Hash
@cursor_image ||= Gosu::Image.new(@cursor)
@cursor_image.draw mouse_x, mouse_y, 1000000
end
end
end
2. No, Magick::Image is a bitmap in memory, Gosu::Image is an OpenGL texture, or something similar. But you can convert RMagick images to Gosu using Gosu::Image.new(rmagick_image).
(And I feel I have to point out that releasing games that depend on RMagick is going to be complicated =/ Deploying Texplay is a lot easier.)
3. Gosu::screen_width and Gosu::screen_height are your friend.
Thanks for the feedback! I'll try to look at the asynchronous image loading soon-ish, as well.
Nice work, the sun looks great!
Ah, too bad. I think I know how to fix it, though.
For those of you who experienced white flickering on startup with Gosu 0.9.x+ (Windows) - has the SDL update fixed this?
Another boring maintenance release :)
• All: Fix many common text rendering artefacts
• Mac: Fix compilation error on OS X 10.11 El Capitan
• Windows: Update to SDL 2.0.4 RC 2
• All: Add experimental Window#tick method to potential integration with GUI toolkits (see Tk thread in Gosu Exchange)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
