I want to make a game like Spout.
My current solution is: I have a rendertarget twice so high, and scroll down.
To scroll down a line, I only have to redraw two lines.
My last question a week ago was answered, to draw a pixel I should use "renderTarget:clear( color, 1, x, y, 1, 1 )"
It works on PC very well. But unfortunately on Android, it is realy slow.
My testprogram says 0.25sec on PC, and 7,5sec on Android)
Does anyone have a tip on how to write such apps?
Is that even possible in Gideros?
I can't find any games in this direction.
Comments
https://wiki.giderosmobile.com/index.php/Particles:addParticles
Fragmenter - animated loop machine and IKONOMIKON - the memory game
I wouldn't go the Gideros particle route myself as particles have no ability to collide, which is one of the main mechanics of this game.
Without knowing just how your own mechanics work it is very hard to suggest any way to improve your CPU use on devices, as opposed to the simulator.
If I was going to make this game using Gideros I'd use the bump collision library and every pixel would be a bump rectangle. I'd recommend scaling the actual bump objects up because bump fails terribly with 1x1 sized rectangles.
You would add the boxes offscreen on the top with a "isDrawn" flag of false.
Using the bump QueryRect() function check the top of the screen and draw any boxes with isDrawn=false, and then set their isDrawn=true so they are only rendered once.
At the bottom of the screen use QueryRect() again for boxes that have gone off the bottom if the display and recycle those.
Looking at the game display I would recommend using 2 layers, one for the static background, and one for the moving pixels. Whenever a pixel collides with the background you just erase a pixel in the background, and then create a new moving pixel in the front layer.
Maybe that helps you?
Likes: MoKaLux
Fragmenter - animated loop machine and IKONOMIKON - the memory game
When it comes to Android, I don't know about the viability of making every single pixel interactable. With a 320x480 display that's 153,600 pixels! I've never been able to process that many in Gideros, even in the desktop player
It's worth a look I suppose but personally I think that only pixels that need to move should move and be drawn every frame. If a pixel is just dormant, then it should do nothing... until it has been collided with and made active.
antix:
I wanted to recognize collisions myself. Are just individual pixels. I have an extra array in LUA for this.
I'm already doing something similar for drawing. With a twice as high rendering target bitmap. So that as few pixels as possible have to be set.
There is no CPU bitmap library from which you can simply create a texture?
Because I think that would be the fastest solution. That would also be useful for other things.
I will experiment a little with your tips and then report to you. Thank you!
Unfortunately, string editing in LUA is very limited.
Setting many individual pixels in an RGB string is intern a copy orgy.
I just can't see how processing every pixel is ever going to be fast on a mobile device. Looking forward to seeing it in action however
Likes: MoKaLux
https://njw.me.uk/spout/
at least one port uses texture manipulation as you wanted originally:
https://gitlab.com/EXL/Spout
Fragmenter - animated loop machine and IKONOMIKON - the memory game
I'll take a look
Really a shame that there is no memory bitmap. That would be the easiest solution
Likes: MoKaLux
There are some good videos on this website!
But I can't see how quadtrees could help.
My current solution consists of a rendertarget in which the fixed pixels are saved. And the moving pixels are represented as particles.
I have to look for my old cell phone to see how quickly it runs on it.