Faster way to read in pixels?

About Monkey 2 Forums Monkey 2 Programming Help Faster way to read in pixels?

This topic contains 11 replies, has 5 voices, and was last updated by  therevills 1 year, 4 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #12329

    therevills
    Participant

    Currently I’m doing the following:

    The tileset is an array of images (16×16), just 32 of them at the moment and I can see the delay already… is there a better / faster way?

    Cheers,
    Steve

    #12330

    abakobo
    Participant

    I would start to try with someting like that (not tested) (might create problems with lighnting and image shaders..?):

    But I would also try to work with pixmaps until the last moment and as few canvas work as possible (using PastePixmap at the end can be usefull sometimes). I think it is generally faster but i’m not shure about that (and what about lighnint and shaders integrity). Not faster for drawing plain bitmaps/inmages to the target render/mojocanvas I guess…

    If you can, try to use an array of Pixmaps instead of array of Images and then use pointer to read/write directly in the memory (like in the example) without using methods (even functions ?) when you are in an intensive loop spot. Reading/Writing pix per pix can be intense.
    There’s also a shader approach as an option (more technical but might use GPU’s parallel computing ability, with pure mx2 you have no (parallel)multi-threading).

    #12341

    nerobot
    Participant

    Note: GetPixel() and GetPixelARGB() look at format of pixmap to return correct value.

    #12346

    scurty
    Participant

    Not sure why you’re creating a canvas and then copying the viewport pixmap of it.
    You can just reference the tile in the sprite sheet. Copying a pixmap in a loop is a bit taxing.
    Idk. xD

    #12347

    impixi
    Participant

    I’d probably do it like this:

    * Load the sprite sheet/atlas into a pixmap.
    * Create the masks in one hit and store them in a single I8 pixmap.
    * Utilize the Pixmap Data pointers for performance reasons.
    * Hope that Mark doesn’t say it is “unsafe” to do it like that. 🙂

    Example (provide your own suitable PNG file):

    Okay, I’m back to “retirement”…

    .

    #12348

    therevills
    Participant

    Thanks guys! I’ll run some bench marking to see what is faster, I was considering of doing it “offline” too by creating a simple app which reads in the pixel data and spit it out to a JSON file.

    @scurty

    Not sure why you’re creating a canvas and then copying the viewport pixmap of it.

    To allow me to read the pixel data from an Image, do you know another way?

    #12355

    therevills
    Participant

    Okay bench marking is done 🙂

    Debug Timing

    Release Timing

    And here is the full code:

    #12357

    abakobo
    Participant

    OriginalVersion = 20ms
    OriginalVersion = 20000μs
    AbakoboVersion = 18ms
    AbakoboVersion = 18022μs

    Mmm! Direct pointer usage was not a great gain (but still a gain ? or just cache work? ;). It was the key to speed in a Julia set fractal generator..
    Not using Canvas operation was the major key for shure!

    Note that Image and Pixmap (extends Ressource) are not GCed so you you have to .Discard() them before replacing/loosing them or you’ll leak memory. But as the are not GCed Mark won’t tell it’s not safe to point to them!?

    #12358

    abakobo
    Participant

    Some small pimping..

    now debug:

    Release:

    For the “new” Tileset class I loaded a Padded png (545*18)

    Tileset2 is the original “NewVersion”
    Tileset3 is just moving color declaration outise of the loop. sometimes it has no/bad effect depending on how the loop is looped (100 times a list of each one or a list of 100 times each one)
    Tileset4 uses Pointer to read into memory (sometimes returns 0 microsec (or 500 or 501!?) not shure it work ok but looks like.

    #12369

    therevills
    Participant

    Thanks Abakobo!

    Note that Image and Pixmap (extends Ressource) are not GCed so you you have to .Discard() them before replacing/loosing them or you’ll leak memory. But as the are not GCed Mark won’t tell it’s not safe to point to them!?

    Hmmm, I thought I read Mark had changed the GC…

    Edit:
    On Mark’s Blog:

    This means it’s not strictly necessary to use Discard to cleanup resources any more, GC will eventually do it for you. GCCollect() is still slow so Discard is recommended in realtime situations, but on the whole it should be possible to write apps without worrying about using Discard at all now.

    #12371

    abakobo
    Participant

    Hmmm, I thought I read Mark had changed the GC…

    Oops my bad, was not aware of that! Might be unsafe to play with pointers then. Using a very local pointer should do the trick though.

    #12383

    therevills
    Participant

    No worries! Sometimes its hard to keep up with all the changes – thanks for helping! 🙂

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.