Closed ashes999 closed 11 years ago
I've just push several commits to master, could you recreate your project and see if the error still happens?
I still get this with the same log messages and behaviour.
My gut feeling is that, like the previous bug, this is not gosu-specific -- because @x
and @y
are also nil. Let me see what I can figure out.
I worked through several issues to reach this point. Memory management is hard. I'm keeping a note of my changes and intend to provide a pull request once I get this working.
I'm at the point where I can load and display a (very small) image. The problem is that it appears garbled:
The only thing I can find in my logs that might be relevant is call to OpenGL ES API with no current context (logged once per thread
appears twice.
Any ideas?. (Here's how it looks in gosu for Windows)
I've been trying to reproduce your problem. So I went to my unused windows partition and I installed everything. Right now I am in the the Stack Level Too Deep Crash
, but when I add the with_large_stack
the logcat says undefined method with_large_stack' for main:Object
. Could you give me more information about how you set up everything?
I'd love to. It's a standard ruboto 0.10.2 with the latest JRuby etc. as per the Ruboto environment setup page. For gosu, I included it as per the latest readme instructions you added (gosu.jar and lib
in src
with the .jar file in libs
).
There's a chopped-up version of my actual app here: https://github.com/ruboto/ruboto/issues/377 (I removed some FPS-counting and some other stuff).
Also interesting: if I change bitmap.rb
to return Gosu::Bitmap.new(64, 32)
or Gosu::Bitmap.new(64, 32, Gosu::Color.new(0xFF, 0xFF, 0x88, 0x44))
I still see the same garbled image drawn. Odd.
This also appears if I try and draw fonts. I tried all the sample code, with no success yet.
Finally I managed to reproduce the issue on the bluestacks emulator. But I didn't see any obvious errors, then I decided to use the with_large_stack
on my real device and suddenly all the images were white squares. So it looks like the memory I get from with_large_stack
gets lost somewhere. So I'll keep investigating towards that issue.
Just to reiterate what I said before:
I didn't realize that variables created inside with_large_stack
go out of scope. Still, there's an easy enough work-around for that (declare the variable outside the block).
I thought this was a general memory problem, but sound seems to be working, so it seems like this problem is specific to graphics.
Let me know what you need. I can happily enlist my phone for testing.
So the problem then is the variables going out of scope. Actually it might not be so easy to solve, because of the way OpenGL ES is implemented in Android it uses two threads. So the images are created in one thread but they are used in the other. Without the with_large_stack ruby solved all by itself. But now I don't really now how to solve it. Anyway I'll keep testing.
@neochuky thanks for taking so much time to look into it.
I created an issue already in Ruboto to address this. Please add your feedback: https://github.com/ruboto/ruboto/issues/377
Do you have a full, working sample without with_large_stack
that can load images? I would like to try that. None of the samples in github seem to work for me (image loading issue).
All the samples I use for testing are the ones on github. Also your sample code is the simplest way to load and show an image.
I'd like to help with this, especially if it is a Ruboto problem. However, everything I have tested works. A concrete sample project that fails would be necessary for me to help, preferably in a GitHub repository.
@donv repro steps are pretty simple:
You will also need to comment out some of the input keys (gamepad ones), because they don't exist in BlueStacks.
I did already try this with the regular emulator and a Galaxy S3, and it worked fine. Since this seems BlueStacks or Galaxy Discover specific, I don't see how I can help.
Maybe this is an Android 2.3 issue?
@donv, Did you try loading the image with with_large_stack { @background_image = Gosu::Image.new(self, Ruboto::R::drawable::background, true) }
? After some more testing, the variable @background_image
still holds a reference to a <Gosu::Image>
object but the colours of the pixels get lost somewhere.
I have tried the examples using a regular Android 2.3.3 emulator, and I do get errors as described in several issues here and in the Ruboto tracker (woohoo!). I'll report if I get anything working.
I have gotten the Arkanoid example working by adding one with_large_stack block, but all graphics are shown as white squares.
Great, I'm not the only one :) so we have three people who can repro it on different combinations of emulators/software and hardware/phones. That's a great start.
I have gotten the Arkanoid example to work by using less stack. Mainly, I have inlined some method calls to get fewer nested method calls. Then it works. This may or may not be a viable solution for other apps targeting Android 2.3 and older.
I will investigate a bit more and try to find what methods are broken by using with_large_stack.
Have any of you gotten anywhere? Any results from your investigations would be great.
I have identified two method calls that fail when encapsulated in with_large_stack:
I have no idea why these methods are sensitive to what thread they are called on.
I have a solution for the stack problem! We can use our own class GosuGLSurfaceView extends SurfaceView
that starts the render thread with larger stack. I have a working example that uses the Android 4.2.2 GLSurfaceView with modifications. I'll see if I can make a smaller example.
I'm not looking at this anymore. I switched to a pure OpenGL-based approach, which doesn't seem to have these problems. (Based primarily on the Java Lunar Lander sample that ships with the SDK.)
Gosu is not bad (albeit Android is alpha-ish), so I may switch back later -- I don't know yet -- once this ticket gets closed.
@neochuky Could you look at the pull request and merge if you like it?
Hi @neochuky !
Have you had any time to look at this? I'd like to mention Gosu support in the next Ruboto release which is this week.
I'll try to verify this on my env tonight.
Excellent! Thank you!
I'm still seeing this problem with the latest code snapshot as of today on BlueStacks. I built the 0.11 ruboto gem, uninstalled the old Ruboto gem (just to be sure), and rebuilt my app.
@ashes999 did you try gosu pull request #8 ?
Nope, I forgot about that. I thought only a Ruboto-side change was necessary.
I'll report back shortly.
Hi, I've just merged the request and push gosu_android.0.0.3.dev to rubygems. Sorry it took me so long to do it.
It works on BlueStacks!! Thanks again @donv
I'm getting a runtime error with require gosu_android
: uninitialized constant Gem::Specification
. This is with the latest versions of both code-bases. I installed gosu by dropping the lib
directory into my project.
I am a genius, I updated the gem, but I did not update the master on github. I'll do it right now.
I still see this error with the latest gem, and the latest code. I tried both now, and with the same result. (Gem was before; source is now with the updated JAR.)
When I install the gem, it shows the version as 0.0.2
, not 0.0.3
, which is odd.
Since the version of the latest gosu_android gem is 0.0.3.dev, you need to specify it exactly or specify that you want "prerelease" versions. I just tried it again with the following Gemfile.apk:
source 'https://rubygems.org/'
gem 'gosu_android', '~>0.0.3.dev'
The gosu_android 0.0.3.dev gem depends on ruboto, so it will install a bunch of unnecessary gems, but it should still work. Using the Gemfile.apk is instead of using the gosh_android -a
generator command, and you will need to add the resources if you don't already have them.
If you want to use the gosu_android generator, be sure to install it with
gem install --pre gosu_android
I created a new app, and everything seems to be working with the 0.0.3-dev gem.
Great work, guys!
Sorry to reopen this.
Transparent PNGs are now appearing garbled, although normal images (non-transparent PNGs, and JPEGs) appear to be fine.
Here's how it looks in Windows:
And on Android:
(Don't mind the Ruboto logo, I don't know why that's there.)
On bluestacks with ball.png
I get a normal transparent image. Can you upload the images your are testing with?
Sure. Here are the links I found my images from:
Using the "latest" 0.0.3 gem with Ruboto 0.11 (both built from source).
This is bizarre. I didn't change anything (just restarted my PC) and I see scrambled images with the same code that worked..
Okay, I'm really confused. My old code that worked yesterday doesn't work anymore, and I can't get gosu-android to generate images that are not scrambled.
Here we go again :(
@donv @neochuky can one of you upload a simple sample (.zip? .apk?) that works?
Sorry to bother you guys. It seems (mysteriously) fixed; there was probably an issue with my code. I have an image that causes a crash, though, so I will open another issue for that.
I have a simple game that draws an image on screen.
I get a black screen. logcat gives me this interesting result:
In other words,
@done
persists, while@x
,@y
, and@background_image
become nil. It's strange. If I add a.nil?
check/throw after assigning a value to@background_image
, it passes; so it seems like the image gets created, very temporarily, and then it vanishes.This is the same on both BlueStacks and my Galaxy Discover.