| 17 Apr 2022 | |||
| japhb | But yes, only drawing the changed bricks is a key optimization. | 01:09 | |
| 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 | ||
| 26 Apr 2022 | |||
| jjatria | Ah, I'm only now seeing this. I temporarily lost access to IRC | 22:29 | |
| japhb | D'oh! | 22:30 | |
| jjatria | Top notch problems for top notch folks | ||
| I'll see if I can take a look. I haven't hacked on Pop for a while, but I've been meaning to get back to it. This might be just the thing I need | 22:32 | ||
| Can't tonight, but I'll try to later this week | 22:33 | ||
| japhb | jjatria++ | 23:01 | |
| 2 May 2022 | |||
| hythm | rewrote the above code `github.com/hythm7/Zippy` using `ecs` in `ecs` branch, and turns out its slower than the OO version. anyway since this is a learning project, I'm writing it now with raw SDL, to understand the basics, like surfaces, textures and so on, once grasp the idea I will rewrite using `Pop` | 00:48 | |
| currently I'm using dirty rectangles technique, so I dont have to draw tthe screen many times. (although online search says that one should not need to use dirty recatngles anymore, because using texture and make use of GPU is faster, but my experience is that using dirty rectangle gives much better performance, may be I'm missing something) | 00:50 | ||
| anyway rewriting using dirty rectangles, comes with other issues, ( e.g unintendedf parts of the screen gets redraw, for example when the ball is moving diagonally), which I'm learning to solve | 00:54 | ||
| japhb | hythm: Partly the performance depends on whether you are drawing to the front buffer (immediately visible on screen) or back buffer (off screen, and needs a "buffer swap" or "surface flip" or similar operation to be visible). | 00:56 | |
| There's also the question of what you actually mean by "faster" -- more frames displayed per second, less tearing within frames, lower CPU spent drawing, less visible redraw lag, etc. | 00:57 | ||
| hythm | japhb, Thanks, I will need to search back buffer and swap, that might be what I need to know first | 00:58 | |
| I mean by faster, i get more frames displayed per second with OO than ECS version, with the same number of bricks and draws | 00:59 | ||
| japhb | For example, yesterday I got rid of annoying redraw lag (where different parts of the screen appeared to draw at different times over 2-4 frames) by changing one of my little toy projects to collect all updates together as they are computed, and then send them all at once in one big burst, rather than compute/draw/compute/draw/etc. | ||
| hythm | I think I understand what you mean. also if you have any code show drawing to back buffer and swap that would be great | 01:05 | |
| for updating/redraw , do all the updates in `update` method, and all rendering in `render` method, and call `update` once then call `render` once per iteration | 01:08 | ||
| japhb | hythm: Since for APIs like SDL and OpenGL the Raku wrappers aren't terribly "thick", you actually ought to be able to find piles of sample code online in Perl or Python or Ruby or Node.js or what have you. Heck, you could probably follow along with examples written in pure C. | 01:09 | |
| hythm: Sure, but render can break down into "create list of draw commands" followed by "execute all draw commands" (which helps when you're sending to the front buffer). Alternately render can break down into "render individual pieces to back buffer" followed by "swap buffers". | 01:11 | ||
| hythm | thanks, will be looking for examples (ffor back buffer and swap) and will report the performance difference | 01:12 | |
| japhb | (And if needed with your API, after swapping buffers, clear new back buffer to prepare for new rendering) | 01:13 | |
| Good luck! | |||
| hythm | thanks | ||
| jjatria | hythm: I finally got some time to take a look at your code (before the rewrite using raw SDL) and I didn't get the impression it was running slowly (although I don't think checking out the initial commit I had 1200 rectangles) | 19:54 | |
| One thing I did notice is that the ball speed is tied to rendering speed, so with more FPS it will move faster. One way to avoid this is by changing `Pop.update: { ... }` into `Pop.update: -> $delta { ... }` and pass that delta down to `Zippy::Ball.move`, where you can do `$!xy -= $!speed * $delta` | 19:56 | ||
| hythm | jjatria: you are correct its not slow in Initial commit, but once I add more brick rows as I mentioned above "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" it start getting slow | 21:12 | |
| for not tying the ball speed to rendering speed, I think thats much better approach, will be looking to do that, I found this article which sounds a good start: gafferongames.com/post/fix_your_timestep/ | 21:14 | ||
| 10 Jun 2023 | |||
| airpods69 | Heyy | 22:57 | |
| SmokeMachine | o/ | 23:45 | |
| 3 Oct 2023 | |||
| Soepx | www.youtube.com/watch?v=sqSA-SY5Hro | 00:55 | |
| I wish politicians would look out for miners | |||
| And not just minors on an island somewhere | |||
| Lord, we got folks in the street, ain’t got nothin’ to eat | |||
| And the obese milkin’ welfare | |||
| irc.supernets.org #superbowl TRUMP 2024 NIGGER | |||
| Soepx lizmat jjatria japhb GreaseMonkey Util RakuIRCLogger SmokeMachine | |||
| jjatria | Delightful | 08:34 | |
| japhb | jjatria: Yeah, it's happening in other channels I'm in too. :-( | 16:10 | |
| 3 Mar 2024 | |||
| MUGS 0.1.4 released! :-) | 21:11 | ||