Slick-AE Development

[EgonOlsen]

They never will. Display lists are not supported by OpenGL ES. VBOs are the way to go instead.

[kevglass]

Yeah, but I might well emulate display lists with recorded in memory operation lists - or VBO backing or something.

Kev

[strategy]

The Fail: messages are just reminders to me. For instance, some things in slick are optimized using display lists - which don't work on this renderer (yet?).

Yeah, noted that the logging was rather insistent. 

Have to check how much work it is to create an app with a nice scrolling map in the background that can be zoomed. Any idea when this will be far enough advanced that one could prototype something like that? Everything I do ends up being a strategy game requiring the scrolling of some huge background map. Or would that sort of thing still be best to do straight in libgdx? I think I really need to do a game-independent implementation of this sometime and OS it - I never find any good examples/tutorials of this kind of thing.

No pressure, of course - but you know, if I don't ask, I certainly won't have an answer...

Games published by our own members! Check 'em out!

[kevglass]

LibGDX is a great library already. Seems like it'd be a good fit for what you want. If you do want to use Slick for the purpose as far as I can see most everything will work - just not been tested on android yet

Kev

[Nate]

Yeah, but I might well emulate display lists with recorded in memory operation lists - or VBO backing or something.

The libgdx SpriteCache class sort of does this. It uses a VBO and does the bookkeeping for binding various textures. It is good for any static geometry and is currently being used for tile maps (example here). Looks like this...

1   2   3   4   5   6   7   8   9   10

cache = new SpriteCache(); ... cache.beginCache(); cache.add(texture1, x, y, u, v, ...); cache.add(textureRegion1, x, y); cache.add(sprite); // etc int handle = cache.endCache(); ... cache.draw(handle);

You can call begin/endCache multiple times to define multiple "handles" in the same VBO. Handles can be redefined individually, or the entire cache can be cleared and redefined.

[kevglass]

Did Egon's fix get into libgdx?

Kev

[badlogicgames]

Not yet. Will include it this weekend. Life is busy

[badlogicgames]

Added your fix. Took some time, was busy with a lot of other stuff. If you happen to run it on a Samsung let me know what AndroidGraphics reports in LogCat. You'll either want to work from source or use the latest nightlies.

Thanks Egon for the hint!

[kevglass]

Thanks all. I'll update from nightlys asap!

Kev

[kevglass]

Slick-AE svn is updated with the new versions, thanks again guys. I'm going to write a new test game to try this stuff out in earnest:



Kev

Games published by our own members! Check 'em out!

[EgonOlsen]

Have you updated that Kitten-game too? Because if so, the fix doesn't fix it...it's still "powered" by Pixelflinger.

[kevglass]

Not updated yet. I'll get it tonight hopefully.

Kev

[kevglass]

Updated to new libgdx here: http://dl.dropbox.com/u/1668516/android/Slick-Android-Test.apk

Kev

[EgonOlsen]

Doesn't work any more. It's giving me an IllegalStateException saying that setRenderer has already been called for this Activity.

[kevglass]

Oh dear

Still works elsewhere.

Kev

[EgonOlsen]

Yes, most likely. However, the Samsung fix needs a fix...

[badlogicgames]

Haha, i suck. The IllegalStateException should be gone. Whether the config chooser snippet from EgonOlsen fixes the surface creation on the shitty samsung is a different story. Nightlies updated.