Runner Template for Gideros Mobile

H4ch1

Hi there (:
Template is out! You can get it there:

Here's the Runner Template latest video :
It runs smooth as butter, 60 fps, very impressed by Gideros Mobile (:
Here's the implementation of one of the classes that comes with it, the AnimationManager class.

--works with any type of Texture, not only TexturePack. local pack = TexturePack.new("runnerSheetData.txt", "runnerSheet.png"); local imgTab = { pack:getTextureRegion("stickfall1.png"), pack:getTextureRegion("stickfall2.png"), pack:getTextureRegion("stickfall3.png"), pack:getTextureRegion("stickjump1.png"), pack:getTextureRegion("stickjump2.png"), pack:getTextureRegion("stickjump3.png"), pack:getTextureRegion("stickrun1.png"), pack:getTextureRegion("stickrun2.png"), pack:getTextureRegion("stickrun3.png"), };   local runner = GCanimObj.new(imgTab); --gives back a Sprite   --we add some animation. --First parameter contains the name of the animation --The numbers in the table of the second parameter corresponds to the texture we put into imgTab earlier, -- and tell the class the frames that must be used for that particular animation --The third parameter is the enterFrame cycles it takes from one frame of the animation to the other. In this case, the whole animation "falling" will be played in 30 enterFrame cycles, meaning, at 60fps, half a second. --The last parameter tells how many times the animation should be played. If set to 0, the animation will play endlessly.   runner:addAnim("falling", {1, 2, 3}, 10, 1); runner:addAnim("jumping", {4, 5, 6}, 10, 1); runner:addAnim("running", {7, 8, 9}, 5, 0);   --Selecting an animation to play runner:prepare("running"); --Playing the animation runner:play(); --pausing the animation runner:pause(); --changing the frame displaying runner:changeFrame(2); --checking if an animation is playing print(runner.animating) --reports true if it is --checking which animation is playing print(runner.sequence) --reports the name of the animation playing

For any question, you can mail me at hachisoft[at]hotmail[dot]it (;
A big thank you at the guys at Gideros Mobile for making such a simple, powerful SDK (:

strancali

Excellent Cristian! You know you got one customer here already . I hope you continue to make more templates and just in time for the Gideros marketplace coming in a few months. As I mentioned, I may launch my site www.PL4YER.com as a general marketplace, app promotions/reviews and more so you're welcome to put these templates on there as well.

I think your price point is perfect (fair price for everyone). Let me know when you're done! =D>

Sid

H4ch1

Aaaand, here we go (:

The Runner Template for Gideros Mobile is done.
You can get it directly there, going through paypal (;

For any question, you can mail me at hachisoft[at]hotmail[dot].it, or directly here (:
Thank you,
Cristian

strancali

Excellent Cristian! Will buy right now

Sid

strancali

Just bought, will check it out tonight when I have time .

H4ch1

Thank you strancali (: Hope you will find it useful (;

atilim

video looks excellent. thank you.

adnaan

bought it. its good enough to be launched just after changing the art :P

adnaan

running at 50-53 fps on my Motorola Defy (android 2.2)

gorkem

@adnaan any visible hickups or sync issues with Defy?

Do you see the same fps with player itself? (while not running anything?)

H4ch1

Thanks to everyone that has got it! (:
@adnaan is that good enough on that device? Not much of an android guy there, so I don't know the specifics.
One other way to do it would be to move the player instead, fixing the level to it's X, like I've done in the Doodle Jump sample, then checking blocks global coordinate to create-remove. The parallax could do the same, while moving on the right at a lower speed than the scene.
I'll try that out and see how it goes (:

adnaan

@gorkem No visible hiccups or sync issues. I have to test more. And, yes the same fps without the player too. May I ask what opengl es extensions are you using to render the textures? The thing is for Android, different devices have different opengl es implementations. I know this because I work for an Android TABLET PC OEM (notionink.com).

I would recommend that for android you do the following as soon as possible(if you have not done it already). Please do not wait for users to complain because it is a major problem. This is not a huge task, only minor tweaks. Morever unlike iOS, there are no good 2D game development tools available for android right now:

1. PVRTC, DXT compression for OMAP and Tegra Devices respectively.(gives you upto 30-40 % performance improvement !!)
2. Use architecture specific GPU features for different class of devices. OEM's differentiate their hardware(which is mostly same) by providing their own api's to do some cool things.
3. Use RenderScript API to render. It has CUDA like parallel processing features. NO JNI CALLS!(10-20% performance improvement)

The third suggestion probably would be a big task for you. But, it can give you "that" edge.


@H4ch1 It is good enough for the device "now",there may be a performance hit when I upload textures with it. This device is pretty good and is able to run 3d games like "Wind-Up Knight" smoothly. I will test more and let you know. BTW great job with the template, I love it.

atilim

Hi @adnaan,

We directly stuck with OpenGL ES 1.1 and aren't using any extensions up to now.

1. To tell the truth, I don't like the results of PVRTC It mostly ruins the beauty of images. I guess PVRTC is %30-%40 faster because of cache utilization, right? But we will support 16-bit textures soon and they look as good as 32-bit textures with good dithering. (Maybe PVRTC support will come next.) Do you know if there is a standart between Android devices about PVRTC? For example, is there any Android devices that supports OpenGL but not PVRTC?

2. Do you know any documentation or web site about this? I would like to read.

3. I haven't heard about RenderScript before. On http://developer.android.com/guide/topics/renderscript/index.html, it says:
Renderscript provides similar performance to OpenGL with the NDK... We directly use OpenGL through NDK and only use JNI for platform specific features like accelerometer, gyro, http access, etc. I assume there won't be any change on performance if we move to RenderScript. What do you think?

Thank you for these great recommendations

cheers,

adnaan

@atilim

1. I should have been more clear. PVRTC has nothing do with Android. Its just a compression format supported by a large numger of Graphics Technology Vendors. The most important of them is Imgtec. Imgtec opengl drivers are mostly present in all kinds of devices(ios, android, others). The key is to use Imgtec core features and api, one of which is texture compression.

Any compression format(pvrtc, dxt) is faster because it divides up the textures into tiles(16x16 or32x32 or 64x64) and puts it in a format which is more readable by the GPU. Without compression there is an overhead for the GPU to first convert the textures into a more readable format. Texture compression has no effect on quality(its lossless). The "loss of beauty" you are talking about is due to incorrect compression for the particular platform(i.e OMAP, Tegra, SnapDragon, MIPS)

You have to categorize android devices by platform(i.e whether OMAP, or Tegra, or SnapDragon or MIPS). The main vendor providing opengl es drivers is IMGTEC.(except perhaps MIPS not sure). Each platform vendor choses to implement the imgtec opengl driver in their own way. Some add features and some remove them. If I had to build a game engine, I would support atleast OMAP and Tegra platforms because they have the lions share of the mobile market.

2. http://www.imgtec.com/developers.asp :: this is the most important link. read everything!
http://developer.nvidia.com/tegra-resources
The android mobile ecosystem is so bifurcated that there is no central documentation related to opengl. But that is what makes it awesome for small companies like yours. you can support features which no one else does and be more profitable.

3. RenderScript is LLVM (https://events.linuxfoundation.org/slides/2011/lfcs/lfcs2011_llvm_liao.pdf)

JNI overhead per call as you may noticed is about 100-140 ms. It is higher if you have to share larger data. Moreover to do multi-threading in JNI is a pain, since the DALVIK does not know anything about it and so you have to do your own GC. DALVIK has a set heap for each app and if your heap size increases the limit of 16mb, the app crashes. Renderscipt takes care of that since the threads are now managed by core android api.

Renderscript is JIT unlike JNI. If you use renderscript your app is bound to get faster by 10-20 % and for heavier games the efficiency can get upto 30 %!. I am guaranteeing it. There are a bunch of other benefits.

NDK now is only good for quick porting of your existing libraries.

One more thing: Renderscript stable version was released just 2 months ago with ICS, so there is no competition there right now. You will sell like hot cakes just on the buzz factor.!!

adnaan

3. The efficiency you get in Renderscript is mainly due to ease of development. You don't have to worry about glue code and can focus "more time" on the actual problem. To me as a developer "more free time" converts to direct code efficiency.

adnaan

3. Insider info: I can't give you sources but renderscript is the way forward for Google, TI and OMAP as I have heard. They are reducing focus on NDK as they go forward.

hyvas

Looks great! I have a Motorola Droid as a test device - it looks like the Defy has the same GPU and resolution. On the Droid in plain Java/OpenGL I find that as soon as I draw a full-screen quad, with no game logic running, FPS drops to 40 (although you can then do/draw plenty more without affecting FPS too much). So the performance here, given what's being drawn, sounds good.

KeepTrying

Hi H4ch1, we need to talk just send me a e-mail ]

Scouser

@adnaan: As far as I can remember, the Renderscript API changed a lot since it's introduction and is now only compatible with android 3.0+ (Honeycomb and ICS). Changing to Renderscript would mean a lot of devs could no longer test their software on their older hardware.

A lot of independent devs cannot necessarily afford the latest hardware so buy second-hand older models for test purposes and these are the devices that Renderscript no longer supports.

Unknown

i sent u email but no reply , kindly contact me at h24h(at)yahoo(dot)com

Scouser

@h24h: Who was that message meant for? I assume it must have beem for @KeepTrying but this is such an old thread I couldn't be sure.

[cynical mode]Or were you just bumping it so you can attract more custom for your template now that Gideros is a lot more popular? [/cynical mode]
)

KeepTrying

@Scouser I do not know exactly, who is that person, btw nice joke
Maybe he is the old @H4ch1 with a new nick Name
The New Adventures of Old @H4ch1 ?
@h24h feel free to check your e-mail box...

fxone

I think that @h24h sent email to @H4ch1

hgvyas123

ohhh h4ch1 and h24h reminds me the chemestry

)

Scouser

Doh!!! Must read posts properly before replying.

@KeepTrying: I read your post saying you sent @H4ch1 an email. Then @h24h necro's a nearly year old thread and my ancient brain decided they were the same person.

Move along now, nothing to see here

geekobjects

Are there any other endless runner examples out there?

ldavim

where can I get this? the tinypay link is not working...