Era-Dorta / gosu-android

A Gosu implementation for Android devices, undergraduate project
MIT License
31 stars 2 forks source link

Image Appears Garbled #2

Closed ashes999 closed 11 years ago

ashes999 commented 11 years ago

I have a simple game that draws an image on screen.

class GameWindow < Gosu::Window
    def initialize
        @done = true
        super 640, 480, false
        self.caption = "Gosu Tutorial Game"
        @background_image = Gosu::Image.new(self, Ruboto::R::drawable::background, true)                    
        @x = @y = 0
    end

    def draw    
        puts "Coordinates are #{@x}, #{@y}; done is #{@done}"
        raise "LOL WUT" if @background_mage.nil?
        @background_image.draw(@x, @y, 0)
    end
end

I get a black screen. logcat gives me this interesting result:

Coordinates are , ; done is true LOL WUT (RuntimeError LOL WUT ["..."]

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.

Era-Dorta commented 11 years ago

I've just push several commits to master, could you recreate your project and see if the error still happens?

ashes999 commented 11 years ago

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.

ashes999 commented 11 years ago

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:

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)

earth

Era-Dorta commented 11 years ago

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?

ashes999 commented 11 years ago

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).

ashes999 commented 11 years ago

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.

Era-Dorta commented 11 years ago

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.

ashes999 commented 11 years ago

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.

Era-Dorta commented 11 years ago

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.

ashes999 commented 11 years ago

@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

ashes999 commented 11 years ago

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).

Era-Dorta commented 11 years ago

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.

donv commented 11 years ago

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.

ashes999 commented 11 years ago

@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.

donv commented 11 years ago

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.

donv commented 11 years ago

Maybe this is an Android 2.3 issue?

Era-Dorta commented 11 years ago

@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.

donv commented 11 years ago

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.

donv commented 11 years ago

I have gotten the Arkanoid example working by adding one with_large_stack block, but all graphics are shown as white squares.

ashes999 commented 11 years ago

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.

donv commented 11 years ago

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.

donv commented 11 years ago

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.

donv commented 11 years ago

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.

ashes999 commented 11 years ago

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.

donv commented 11 years ago

@neochuky Could you look at the pull request and merge if you like it?

donv commented 11 years ago

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.

ashes999 commented 11 years ago

I'll try to verify this on my env tonight.

donv commented 11 years ago

Excellent! Thank you!

ashes999 commented 11 years ago

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.

donv commented 11 years ago

@ashes999 did you try gosu pull request #8 ?

ashes999 commented 11 years ago

Nope, I forgot about that. I thought only a Ruboto-side change was necessary.

I'll report back shortly.

Era-Dorta commented 11 years ago

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.

Era-Dorta commented 11 years ago

It works on BlueStacks!! Thanks again @donv

ashes999 commented 11 years ago

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.

Era-Dorta commented 11 years ago

I am a genius, I updated the gem, but I did not update the master on github. I'll do it right now.

ashes999 commented 11 years ago

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.

donv commented 11 years ago

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.

donv commented 11 years ago

If you want to use the gosu_android generator, be sure to install it with

gem install --pre gosu_android
ashes999 commented 11 years ago

I created a new app, and everything seems to be working with the 0.0.3-dev gem.

Great work, guys!

ashes999 commented 11 years ago

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:

image

And on Android:

image

(Don't mind the Ruboto logo, I don't know why that's there.)

Era-Dorta commented 11 years ago

On bluestacks with ball.png I get a normal transparent image. Can you upload the images your are testing with?

ashes999 commented 11 years ago

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).

ashes999 commented 11 years ago

This is bizarre. I didn't change anything (just restarted my PC) and I see scrambled images with the same code that worked..

ashes999 commented 11 years ago

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?

ashes999 commented 11 years ago

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.