Show Posts
2911
Lix Main / Re: D/A5 port: Current status, 2016-01-18
« on: January 20, 2016, 02:00:54 AM »
Rubix: Thanks! :-)
ccx/geoo: I've beefed up the implementation with bitmap holding. (Make hardware queue drawings instead of draw right away, queue many blits onto the same target bitmap, unhold => hardware can draw faster.) This brought down measurements for the per-pixel drawing from 7 ms to 1.2 ms. I can't tell whether this is accurate, or whether gfx-work differs from this code's execution time. From watching the FPS, these numbers are in the correct ballpark.
Current implementation: There is a separate matrix for physics in RAM. Updating physics changes the matrix, and checks whether the blit can be done later in one go, or if it must happen per-pixel. Later, when updating graphics, I hold bitmap drawing, draw all masks either in-one-go or per-pixel, then unhold.
The newest versions of Allegro 5.1 don't compile on my old Debian 6 anymore. >_> A5.1 comes with hardware shaders, those look like they could simplify and speed up (drawing only on transparent pixels of the target area). The A5 folks have suggested shaders for per-pixel before, when I asked in 2011. So, that's where expert knowledge of my domain points to.
Saving the steel at start of level: That would help for terrain removers, but terrain adders still have to draw behind the terrain. Since steel-saving incurs an extra cost at start of level, but doesn't solve all questions, I haven't tried it yet. Maybe steel-saving for terrain removers, and shaders for terrain adders, would be most interesting.
However, I believe the current implementation is OK, performance-wise. If someone sends in a patch to improve it, I'd happily merge it in. :-) As a single developer, because I'm content for now, I'd like to focus on other parts of the program.
In particular, I'd like feedback from other people about bugs and performance. That's why I encourage geoo to build for Windows in the upcoming days.
-- Simon
ccx/geoo: I've beefed up the implementation with bitmap holding. (Make hardware queue drawings instead of draw right away, queue many blits onto the same target bitmap, unhold => hardware can draw faster.) This brought down measurements for the per-pixel drawing from 7 ms to 1.2 ms. I can't tell whether this is accurate, or whether gfx-work differs from this code's execution time. From watching the FPS, these numbers are in the correct ballpark.
Current implementation: There is a separate matrix for physics in RAM. Updating physics changes the matrix, and checks whether the blit can be done later in one go, or if it must happen per-pixel. Later, when updating graphics, I hold bitmap drawing, draw all masks either in-one-go or per-pixel, then unhold.
The newest versions of Allegro 5.1 don't compile on my old Debian 6 anymore. >_> A5.1 comes with hardware shaders, those look like they could simplify and speed up (drawing only on transparent pixels of the target area). The A5 folks have suggested shaders for per-pixel before, when I asked in 2011. So, that's where expert knowledge of my domain points to.
Saving the steel at start of level: That would help for terrain removers, but terrain adders still have to draw behind the terrain. Since steel-saving incurs an extra cost at start of level, but doesn't solve all questions, I haven't tried it yet. Maybe steel-saving for terrain removers, and shaders for terrain adders, would be most interesting.
However, I believe the current implementation is OK, performance-wise. If someone sends in a patch to improve it, I'd happily merge it in. :-) As a single developer, because I'm content for now, I'd like to focus on other parts of the program.
In particular, I'd like feedback from other people about bugs and performance. That's why I encourage geoo to build for Windows in the upcoming days.
-- Simon
Could omit the minus sign, and, after winninng, draw this winner's cup instead of the flag.