Forum
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)
Wait, why do you call root.after(1000, step(window, root))? You need to pass the step as a proc/lambda, or it will be evaluated immediately.
(Why does after even accept two arguments? Mysteries of Ruby/Tk... :))
This works for me:
window = GameWindow.new
root = TkRoot.new { title "ex1" }
TkLabel.new(root) { text "hello world"; pack { padx 15; pady 15; side "left"; }; }
step = proc { window.tick; root.after(16, &step) }
step.call # start Gosu::Window#tick timer loop
root.mainloop
I think I'll leave Window#tick in the final Gosu 0.10.2, but mark it is experimental in the docs. Thanks for testing, and for nudging me to refactor Gosu a little more.
I ran into the same issue, and chatted about it with flgr. The trick is that again only works with the listen 1.x gem, not 2.x or 3.x. So you can either uninstall all versions of listen, and then gem install listen -v 1.3.1, or you can specify the version through your Gemfile:
gem 'again', require: false
gem 'listen', '= 1.3.1', require: false
I think it works now. If it doesn't pick up changes to your files, *I think* you can also force it to reload a file like so:
Again.instance.send(:reload, Again.instance.send(:resolve_library, "#{File.dirname __FILE__}/src/model/piece.rb"))
I guess that's a bit of a vague response, but last time I had to stop coding after the first "proof of concept" reload worked :/ (Ruby 2.0, OS X)
Ha, very creative use of Gosu :) (I've fixed the YouTube link in your post, it was probably garbled by the board software.)
You're welcome :) There's another Mac-only issue I have to fix, and then I'll probably release 0.10.2.
Can you please give Gosu 0.10.2.pre1 a try: gem install gosu --pre
It has fixed the issue for me.
I don't think there's an easy way around the perspective correction issue, either. Gosu does not use Z coordinates in its OpenGL code – the Z ordering happens in software. It's probably easier to use OpenGL and this flag:
GL.Hint(GL::GL_PERSPECTIVE_CORRECTION_HINT, GL::GL_NICEST)
I'm really enjoying this bit of code right now, and thought I'd share it. It uses terrible Ruby monkey-patching to reload all images when the user presses R. (I'm
require-ing this file after my
class Window < Gosu::Window has been defined, adjust the class name accordingly...)
https://github.com/jlnr/monstris/blob/master/src/debug/image_reloading.rbIt doesn't override
Image.load_tiles and is generally shaky, but isn't it fun what you can do in a few lines of evil Ruby :)
Ah, too bad. I'll take a look myself, but I'll put it on my lower-priority list if I can't figure it out quick enough.
It seems that using Tk's #update should be good enough for internal tools like level editors, though? That's actually good to know!
Oh, Tk has an .update method? I thought it only had the full .mainloop. Do we even need Window#tick then? I've just created a TkRoot in a Window constructor and called .update on it from Window#update, and then just called window.show. The result seems to be the same as in your gist - a tiny Tk window alongside a working Gosu::Window.
Cool. I've pushed a --pre version of Gosu that has Window#tick as described above. Seems to work fine from a quick test, but I haven't integrated it with any libraries, only called tick in a while loop. It is still possible that Gosu's tick eats OS events that Tk is waiting for, or the other way around.
w = Gosu::Window.new(...)
loop { break if not w.tick }
Note that everything related to Gosu has to be called from the main thread.
Looking forward to your results :)
I've looked into several Ruby GUI toolkits (Tk, wx, Fox...), and they all seemed to be pretty obscure or half-broken on most platforms, so I haven't spent time integrating any of them with Gosu. The state of GUI programming in Ruby is terrible :|
Anyway, the biggest problem is that both Gosu and Tk (or any of the other UI/eventing libraries) have their own mainloop. Gosu's is here:
https://github.com/gosu/gosu/blob/master/src/Window.cpp#L179-L219In theory I could unroll the
while (true) loop and introduce a new method
tick that handles a single step in the
while loop, so that
show becomes a simple
while tick; end.
Then in Tk, you could just never call
show, but keep the
Gosu::Window running by calling
tick regularly from Tk (a timer?). Do you feel like doing a little research work? I can push a beta gem.
I was thinking about it, but I don't think I am ready to give on multiple window support just yet :/ I'll keep it in mind - it's a bit annoying in my own code as well.
Yes and no. A client once ran into the same issue, and for a while there was an experimental
Image.async_new method that returned a 'placeholder' object. You could ask this object whether it was
ready? and then call
get to extract the Image on the main thread. (I'm not sure if it is a Future or a Promise in computer science terms…I always get them wrong.)
The problem with the
async_new interface was that I'd also have to add
Image.async_from_text,
Image.async_load_tiles,
Sample.async_new etc. to be consistent. My client ended up not using it anyway, so I've silently removed
async_new.
It would be pretty easy to just make most of Gosu's resource management thread-safe. Alas that wouldn't help, because Ruby is still not executing code from C extensions on separate threads (unless I've missed something in the changelog).
Anyway, that sounds like a cool project, and I'll see if I can bring
Image.async_new back as an experimental feature. I miss it as well. I've opened an issue on GitHub that you can subscribe to:
https://github.com/gosu/gosu/issues/294
It's also strange that Gosu cannot find the other libraries:
checking for TTF_RenderUTF8_Blended() in -lSDL2_ttf... no
Maybe I'll download an ISO image real quick and see if I can reproduce it. I've never seen Linux Mint in action, anyway!
Edit: I can't install the dependencies in the live CD because of package conflicts; libsndfile depends on libflac-dev, but libflac-dev depends on "libflac8 (= 1.3.0-2) but 1.3.0-2ubuntu0.14.04.1 is to be installed" etc etc... No idea, sorry.
I'll definitely add a link to the book as soon as it is finalised, I really like the fact that there's a puzzle game in there (they are underrepresented on this board :)).
Works as expected on OS X. I wonder if it doesn't work on Windows because I'm still using SDL 2.0.3 there. (Man, SDL 2.0.4 can't come fast enough :( Maybe I should compile an intermediate DLL myself?) Thanks for reporting this, and sorry for the lack of progress.
I've opened a GitHub issue here:
https://github.com/gosu/gosu/issues/293
Version 0.10.1.1 is out as well and only fixes an installation issue on Linux.
Does installing mesa-common-dev help? Can you see the GL/gl.h header somewhere in /usr/include?
A tiny bugfix release:
• Windows/Linux: Fix audio playback of stereo, non-Ogg-Vorbis files (
https://github.com/gosu/gosu/issues/237)
• Ruby: Fix
:retro parameter in
Image.load_tiles and
Image.from_text
Have you tried installing the packages from the wiki page that is linked in the error message? Since Linux Mint is based on Ubuntu (Wikipedia says so...), the package list for Ubuntu should do the trick.
If it does, feel free to edit the wiki page to clear things up for the next Linux Mint user :)
I've dug into it and Chingu by itself seems to work - no problem with any of Chingu's examples (at least, the five I've tried) and Gosu 0.10.0.
However, Ashton monkey-patches a lot of stuff in Gosu, and that might be the problem at hand. I know that everything in Ashton should actually be part of Gosu...but right now I don't have the resources to either implement it in Gosu or to fix the Ashton gem. Sorry :|
Loading tiles will copy the image data to a new texture, so you'd have to pass :retro when creating the individual tiles - that should work!
If you use retro_image.subimage(x,y,w,h), it should preserve the parent texture's retro-ness. The image data is shared in that case, which also makes subimage extremely cheap.
Then again, I'm not sure if subimage was really a good idea, or if Image.load_tiles should just take an array of rectangles to support texture atlas loading.
Confirmed, looking into it now.
Edit: Fixed, will be released as 0.10.1 ASAP. I've also fixed the :retro parameter in Image.from_text, for the sake of consistency.
Two more things:
First, I'm sorry for not looking into the Chingu bug yet! It's on my list.
Second, 33th Ludum Dare gamedev competition starts tomorrow! If you have no plans for the weekend, stock up on healthy snacks and write a game :)
http://ludumdare.com/compo/
Gosu 0.10.0 is out. It contains two things that I thought I had already released:
• Add new
ifRetro/
:retro parameter to image constructors
• Ruby: Fix mouse position getter/setter interaction
Sorry for the delay, I meant to release 0.9.3 months ago. The tl;dr is that you should start using
Image.new("filename.png", :retro => true) instead of using
Gosu::enable_undocumented_retrofication.
I've also replaced a few third-party libraries with easier-to-maintain public domain code.
(The version was bumped to 0.10.0 because some exotic image files might not work anymore — but at least they will consistently be broken across platforms now! No more surprises during porting.)
• Use stb_image(_write) for image I/O instead of GDI+, FreeImage,
UIImage/
NSImage etc.
• Use stb_vorbis for OGG decoding instead of libogg/libvorbis/libvorbisfile
This is also great news because libogg/libvorbis require written attribution in every game that uses the libraries (BSD license) - and readers of our games' README files honestly don't care about audio codecs. Less clutter for everyone.
The biggest changes in 0.10.0 are in the non-Ruby build scripts, though:
• Windows: Upgrade to Visual C++ 2015 (the free Express Desktop edition works). Microsoft has pulled all downloads for good old Visual C++ 2010, time to move on.
• Unix: Fix the CMake build files.
• Xcode: The
Gosu.podspec for OS X and iOS is now versioned, instead of being stuck at v0.0.1.
Precompiled libraries for Windows, and a source code tarball for UNIX systems can be found here:
https://libgosu.org/downloads/To keep the Gosu codebase somewhat manageable, I have also ripped out the Socket classes for C++ and moved them to
https://github.com/jlnr/Sockets.
Please try again, I've pushed fixes for the CMake files today :)
The strange thing is that Chingu does not alias any methods in Gosu::Image (monkey-patching). It seems to only use the public interface.
Since Gosu 0.9 is supposed to be backwards-compatible, it might be a bug in Gosu. (But testing with 0.8.7 is still worth a shot!)
I love my gamepads, and I agree that everything you mention should be possible - PLUS force feedback :) However, I'm afraid that redesigning/extending the gamepad interface will take a while. So my current roadmap is:
Gosu 0.9.10 - more cleanup
Gosu 1.0 - once SDL 2.0.4 is released, plus some interface fixes (Gosu::TextInput and <b>pseudo HTML tags</b> are an embarrassingly bad mix right now!)
Gosu 1.1 - input redesign
I'm a big fan of the SDL 2 Game Controller API, so I'll probably model the new input API after it, and I'll try to expose as much of it as possible (+ backward compatibility layer for the current Gosu API).
One more thing that I'd like to keep an eye on is serialisation/deserialisation of button IDs. (They're only semi-portable now.)
That all being said, if you have an idea of what the API could look like, feel free to post it here or open an issue on GitHub for discussion :)
No idea about Releasy - especially since it seems to be more of a libxml installation issue than issue with Releasy itself.
Ocra: I suspect that Ocra does actually include the images. However when the game runs, they are not necessarily accessible from the current directory, so you will not be able to load them using a relative path like
"resources/bg_01.png". One thing you can try is to add the
--chdir-first option to the
ocra call. (I'm not sure if that will set the current directory to the folder containing the EXE file, or to the temporary folder into which images are extracted, but it's worth a short.)
For further debugging you can log
Dir.getwd or
Dir['*'] to a file on the desktop to inspect what's going on, or pass
--debug-extract to
ocra and inspect which files are being included - see the README on GitHub:
https://github.com/larsch/ocraHope that helps.
Can you please post the rest of the output? Most of it is indeed unimportant but there's usually one line in there that isn't :)
The two most common pitfalls are: 1. since Gosu 0.8 you'll need to brew install sdl2 libogg libvorbis, and 2. you might be using RVM, which often breaks Gosu's compilation.
Great to hear that it works and thanks for the write-up! I've added a link to your posting to the Getting Started on Linux guide.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill