Here is a demo I’m working on for the competition.
I felt like the images on corona geek weren’t doing it justice, so I’m publishing the link for the android build for now, so you guys can have a play and see what sort of things you can come up with.
As always… Unbelievably Cool !
Note to self: I really need to read up on 2.5D programming. Graphics 2.0 is capable of amazing things…
Very cool!
Nice work! Thanks for sharing.
FYI, on a Nook HD+ it runs at about 10 fps. I know it’s not the highest end Android tablet but I get pretty good performance out of it with graphics 1.0 apps. Seems like anything I run on it that uses graphics 2.0 is very slow. For example, with your retro racer V2 project I get about 20 fps with X1 objects, and about 5 fps with 4x objects.
That’s not so good, I wonder where the bottle neck is. It could be the double snapshots, it wouldn’t surprise me that something like the Nook isn’t really optimised for this. Also, resolution plays a reasonable part in this. Note that in the retro racer case it might help if you up the pixelate values, as that will cut down power a power of 2 each time the pixels it has to draw, apart from the final stretching of the snapshot to fill the screen.
The book app uses snapshots extensively (in the room scene there are 5 snapshots in total), but there isn’t really a way of cutting down on this directly. Does it still run like a dog when up close to the book and turning pages?
Nice work 
Yeah, upping the pixelation values does help quite a bit in retro racer. In fact, I was able to get what looked like 30-60 fps even with 4x objects by upping the pixelation to maximum.
The book app runs about 10 fps even up close. The framerate seems pretty consistent throughout the demo. Keep in mind, these fps are ballpark estimates.
My impression reading over some other threads was that graphics 2.0 has not yet been optimized, especially on Android devices, so hopefully there are performance improvements to look forward to.
Does look like fill rate is the suspect then, as changing the scale doesn’t change any calculations or anything. Means we might not be able to do much for that device, it likely has very slow GPU. On the other hand, pixelation = FTW. I could try a version for you without using snapshots just to see if that is what has such a terrible performance although from what you tell me, I doubt it. But it never hurts to take a look.
As always… Unbelievably Cool !
Note to self: I really need to read up on 2.5D programming. Graphics 2.0 is capable of amazing things…
Very cool!
Nice work! Thanks for sharing.
FYI, on a Nook HD+ it runs at about 10 fps. I know it’s not the highest end Android tablet but I get pretty good performance out of it with graphics 1.0 apps. Seems like anything I run on it that uses graphics 2.0 is very slow. For example, with your retro racer V2 project I get about 20 fps with X1 objects, and about 5 fps with 4x objects.
That’s not so good, I wonder where the bottle neck is. It could be the double snapshots, it wouldn’t surprise me that something like the Nook isn’t really optimised for this. Also, resolution plays a reasonable part in this. Note that in the retro racer case it might help if you up the pixelate values, as that will cut down power a power of 2 each time the pixels it has to draw, apart from the final stretching of the snapshot to fill the screen.
The book app uses snapshots extensively (in the room scene there are 5 snapshots in total), but there isn’t really a way of cutting down on this directly. Does it still run like a dog when up close to the book and turning pages?
Nice work
Yeah, upping the pixelation values does help quite a bit in retro racer. In fact, I was able to get what looked like 30-60 fps even with 4x objects by upping the pixelation to maximum.
The book app runs about 10 fps even up close. The framerate seems pretty consistent throughout the demo. Keep in mind, these fps are ballpark estimates.
My impression reading over some other threads was that graphics 2.0 has not yet been optimized, especially on Android devices, so hopefully there are performance improvements to look forward to.
Does look like fill rate is the suspect then, as changing the scale doesn’t change any calculations or anything. Means we might not be able to do much for that device, it likely has very slow GPU. On the other hand, pixelation = FTW. I could try a version for you without using snapshots just to see if that is what has such a terrible performance although from what you tell me, I doubt it. But it never hurts to take a look.