|
00:04
hythm joined
|
|||
| hythm | Hello, I'm learning `SDL` and starting writing a small `Arkanoid` like game using `Pop`, github.com/hythm7/Zippy | 00:08 | |
| the problem is I find it very slow, when I increase the number of bricks in the game, in this line github.com/hythm7/Zippy/blob/dev/l...akumod#L33 from `for ^60 X ^1 -> ( \i, \j ) {` to `for ^60 X ^20 -> ( \i, \j ) {` for example | 00:10 | ||
| my question is what do I need to do to make it fast with many bricks | 00:12 | ||
| I'm asking if I'm doing something wrong, or if there is some SDL optimizations needed for this simple games to make it fast | 00:15 | ||
| japhb | hythm: It can help to pre-cache the coordinate set: my @coords = ^60 X ^20; for @coords -> ($x, $y) { | 00:45 | |
| But of course the inside of the loop matters too. :-) | 00:46 | ||
| If you have Comma you can run your game under profiling and get a look at what's using the time | |||
| (You can do this without Comma, but then because games produce SO MUCH PROFILE DATA, you are generally needing to spelunk the SQL data set yourself.) | 00:47 | ||
| hythm | Thanks japhb, will try this | 00:48 | |
| `$!level.brick.map( -> $brick { Pop::Graphics.rectangle: $brick.xy, $brick.xy + $brick.wh, $brick.color, fill => $brick.fill } );`, this line is what is taking most time since it runs every frame and need to loop through `@!brick` to draw them, with increasing number of bricks it takes more time. I've seen similar games have many number of bricks | 01:04 | ||
| up to thousands bricks, and run smooth. so wondering if they do some kind of optimization, like draw only the changed bricks, not all bricks every frame | |||
| japhb | Does Pop::Graphics.rectangle immediately draw the rectangle, or does it create an object to be drawn later? | 01:08 | |
| (Because if it's the latter, create all those objects at the start of each level, and then you can iterate over the draw. | 01:09 | ||
| But yes, only drawing the changed bricks is a key optimization. | |||
| Also, if you're doing collision tests, using a data structure that allows you to only test the bricks near to the ball helps as well. | 01:10 | ||
| hythm | the bricks objects are created at the start of every level, then `Pop::Graphics.rectangle` draws them using their position points. | 01:23 | |
| japhb | hythm: Yeah, that's going to be a lot of drawing calls. | ||
| hythm | for drawing the changed bricks only, this requires no calling `Pop::Graphics.clear;` every frame as well, I think | 01:25 | |
| japhb | nodnod | ||
| OOC, what is your current frame rate with 1200 bricks? | 01:26 | ||
| hythm | 30 | ||
| japhb | For that type of game, that's not brutal. I was afraid you were getting like 2 FPS or something? | 01:27 | |
| hythm | oh I did not underestand your question correctly, I meant I set the frame rate to 30 ( Pop.run: :30fps ) | 01:28 | |
| I dont know how to tell the current frmae rate I get during tunning the game | |||
| running* | 01:29 | ||
| but its really slow, so I see the ball moves like 2 or three times per second with 1200 bricks. so I'd say it's around 2 FPS | 01:31 | ||
| japhb | jjatria: Around? hythm has Pop questions .... | 01:33 | |
| They might be out of timezone right now. Also, it's a holiday weekend for some folks. | 01:34 | ||