|
|
|
This thread is locked; no one can reply to it.
|
| Is there a fast way to copy memory to bitmap? |
|
kovarex
Member #14,203
April 2012
|
This relates to the map in the game. The map consists of 32X32 segments, each of them are updated and stored in an 32X32 array of four bytes (rgba). When any of the segment is changed or created, it needs to create it's video sprite and setup it's contents based on the array of data, so it can be actually drawn when the map is displayed. This tasks is quite slow, and the best improvement I have done (long time ago), was to find biggest set of squares and draw to the bitmap these instead of drawing pixel by pixel. I'm looking for a way, to directly copy the raw sprite data to the allegro structures, so they are updated in one operation, which would most probably fasten the process a lot. Thank you for any advice. www.factorio.com - a factory building game. |
|
Polybios
Member #12,293
October 2010
|
Don't know exactly what you're looking for, but I think bitmap locking and accessing data via ALLEGRO_LOCKED_REGION is the fastest way. Be sure to pass ALLEGRO_LOCK_WRITEONLY to al_lock_bitmap, so as to avoid reading texture data. |
|
jmasterx
Member #11,410
October 2009
|
The slow part is not copying from your structure to the Allegro structure, it is fetching the video bitmap from the graphics card and putting it into main memory for manipulation, then sending back your changes to the graphics card. This was not a problem in the old days of software rendering, but it is in hardware rendering. If it is possible, you will see significant speed increase from using a fragment shader to manipulate the bitmap. This avoids the travel cost. Agui GUI API -> https://github.com/jmasterx/Agui |
|
Chris Katko
Member #1,881
January 2002
 |
Assuming he's talking about Factorio: You have this game world, split into large chunks: {"name":"fr-minecraft_map_5YPD_file.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/1\/017db0d9af7e93645c1d2743b49661c6.jpg","w":900,"h":506,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/1\/017db0d9af7e93645c1d2743b49661c6"} You press the map button and it looks like this: {"name":"hcwwTzG.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/a\/bab9b49124b578073072e690d51f79e0.png","w":1600,"h":860,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/a\/bab9b49124b578073072e690d51f79e0"} Note the square edges. Those are chunks. But without seeing the rendering pipeline, I agree with the two answers provided. It's most likely an issue copying to system RAM. You should definitely try to avoid system bitmaps for live updates at all cost. Shaders are insanely fast. You'd want to look into tutorials regarding "Shader Rendering to Texture". Someone built "the Game of Life" into a texture (using every pixel!) and rendered it to a torus.  And that's about as per-pixel as you can get. One more possibility. Thinking about this from the time axis. Assuming you're talking about that map and scanning every piece on a chunk. How much of that map needs to be updated in real-time? Can a particular chuck update be "deferred" across multiple frames? I can't remember, does the map show live movement of "alien attacks"? If not, a "chunk parse" could certainly cross a few frames and still "appear" instant to a user if that one piece is dragging the FPS down. -----sig: |
|
|
