Forum
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.
And another idea: Does gem install opengl
work?
Phew - not sure why it can't find this library?
Gosu is using a tool called pkg-config
to find OpenGL, what is the output of pkg-config --libs gl
on your machine?
Oh, that sounds like a different error altogether :) The important part is "cannot find -lGL
" (=OpenGL)
Can you please check if there is a libGL.so in /usr/lib/x86_64-linux-gnu, or maybe /usr/lib?
Ruby 2.1 is a fine version :) Every version from 1.8.7 to 2.2.x should work with Gosu.
It sounds as if Ruby wasn't the problem: "The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first."
Have you installed a C++ compiler (usually g++
on the command line)? It should have been part of the build-essential
package mentioned in the Getting Started on Linux wiki page.
This has been on my internal To Do list already, I've promoted it to a GitHub issue:
https://github.com/gosu/gosu/issues/287I don't think a boolean callback works here because you might want to show an in-game dialog box, and delay the decision by many frames.
I am a little confused why SDL_GL_CreateContext would return 1 – but anything that's not 0 is good, I guess!
There's been a GitHub issue about the Pi just this week:
https://github.com/gosu/gosu/issues/285...so I guess Gosu does *theoretically* work on Raspbian, but at this point I can only say that the Pi is terrible platform for SDL 2/OpenGL (ES), and that I don't know how to support it properly. :(
Sorry, but that doesn't look like a Gosu-related issue. I have never seen these messages on a fresh installation of Ubuntu 14.10, so something must have gone wrong before you even started installing Gosu's dependencies.
Nope, this was an error on my side - will be fixed in Gosu 0.9.3 (ASAP), no need to wait for an SDL update.
Gosu is not in apt-get
(yet ;) ). Please try gem install gosu
instead.
Has the error message changed after sudo apt-get install libx11-dev
(from StackOverflow)?
Re:
@data = Array.new(width, Array.new(height, default_value))
When you pass a second argument to Array#initialize
, it will be evaluated once (like all method arguments) and used as the initial value in the array. If you pass a block, however, that block will be evaluated once to generate the initial value for each cell:
@data = Array.new(width) { Array.new(height, default_value) }
Pretty amazing how small the actual tiles are, and how big they feel in the 3D world :)
Yay, another user!
If you ever feel the need to finish something, there are enough game dev competitions around to present you with a hard deadline ;)
Right, the examples live in the
gosu-examples
gem now:
https://github.com/gosu/gosu-examples (a recent and not very well documented move)
Can you please try calling
SDL_GL_CreateContext(window)
after creating the window and see what it returns?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill