|
00:42
hythm joined
|
|||
| 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 | ||
|
01:56
hythm left
04:25
Altreus left,
Altreus joined
|
|||
| 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 | ||
|
21:05
hythm joined
|
|||
| 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 | ||
|
22:49
hythm left
23:17
TempIRCLogger left
|
|||