Mojo: GetPixel() since update 1.11

About Monkey 2 Forums Monkey 2 Programming Help Mojo: GetPixel() since update 1.11

This topic contains 10 replies, has 4 voices, and was last updated by  Abe _King_ 8 months, 1 week ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #14162

    dominique95
    Participant

    Hello,
    Since 1.11 update, is there any change in Mojo (2D) ?
    For me, GetPixel() and GetPixelARGB() return (0,0,0,0) and $0
    Maybe I do it wrong now.

    I’m on Windows 10 – 64 bits.
    Could you run this code on other configs with monkey 2 – 1.11  ?
    GetPixel() returns Color(0,0,0,0) since update.

     

    Also any changes in Keyboard events ?

    #14166

    Mark Sibly
    Keymaster

    Yes, the behaviour of textures has changed a little here – they were never supposed to modify the pixmap they were created with in the first place, and it was causing all sorts of issues with something else I was trying to do in 1.1.11, so I ‘fixed’ it so that the initial pixmap is copied to an internal one if necessary and is never used again (by the texture anyway).

    However, the old way is probably the most efficient way to do what you’re wanting so I think I’ll add some kind of new texture flag that preserves the old behaviour, not sure what I’ll call it yet. Should be in v1.1.12…

    Also any changes in Keyboard events ?

    There are always changes to everything! Could you be a little more specific?

    #14167

    Mark Sibly
    Keymaster

    Ok, I’m gonna revert this to pre 1.1.11 behaviour in the case of normal textures – my fixes were really only necessary for cubemap textures.

    #14168

    dominique95
    Participant

    Thanks Mark,
    Got it, i didn’t draw into the Pixmap.

    Now the question : How can i get the color of a pixel in the image ?

    For Keyboard events, i must experiment, (2900 lines of code in my prog), to see if my code is faulty.

    #14174

    Mark Sibly
    Keymaster

    Now the question : How can i get the color of a pixel in the image ?

    The way you were doing it pre 1.1.11 is probably the most efficient so once 1.1.12 is out I’d suggest going back to that which will fix this issue.

    But note that it’s still not all that efficient, because modern GPUs don’t like you ‘reading’ their memory. On PC’s, GPU’s generally have their own private graphics memory and moving data to/from graphics memory is relatively expensive.

    Also, the OpenGLES API (used by mobile/web targets) doesn’t even support copying data from textures to system memory, only copying data from the ‘render target’. Desktop OpenGL does, but it wont be anymore efficient than the pre-1.1.11 method.

    There is no easy way around this, it’s just something you’ve got to deal with if you want HW accelerated graphics. If anyone has any ideas here too please feel free to share.

    For Keyboard events, i must experiment, (2900 lines of code in my prog), to see if my code is faulty.

    Not even a hint?!?

    #14177

    dominique95
    Participant

    Ok,
    I see a little difference after monkey 1.06
    Keyboard.KeyPressed() , and Keyboard.KeyReleased() have a little buffer.
    Run this code, with monkey 1.06 and later. Follow the instructions on screen.
    It just moves a cursor, if the mouse is in a zone and a cursor keys is pressed.
    see  Method ProceedInput()

    #14178

    Mark Sibly
    Keymaster

    Yep, the behaviour of Keyboard.KeyPressed has changed since v1.1.06.

    Before v1.1.06 KeyPressed used use a ‘frame’ system, where KeyPressed returned true if a key was pressed in the current ‘frame’ (ie: the time between renders). However, this caused problems when people tried to use KeyPressed from within timers.

    It now returns true if a key has been pressed since the last call to KeyPressed (with the same key). This affects your code because you only call KeyPressed if mouse is in zone.

    The solution is to always check for KeyPressed, even if the mouse is not in any of the zones. I guess another possiblity would be to allow people to manually increment the ‘input frame’.

    Or, you could instead use a KeyEvent handler, like this:

    #14179

    Mark Sibly
    Keymaster

    What I think I’ll do here is resurrect b3d/bmx style Keyboard.FlushKeys() that can be called to ‘clear’ any keypresses that haven’t been checked for. Look out for it in v.1.12 in addition to the texture fix.

    #14183

    dominique95
    Participant

    Exactly what i needed.
    I will try to inject your KeyEvent handler in my project.
    Many thanks for explanations.

    #14193

    AdamStrange
    Participant

    So you broke both pixmaps and keyboard scanning – way to go Mark!

    I hear-by declare you a winner 🙂

    #14260

    Abe _King_
    Participant

    I am also now experiencing the exact same problem. I have no idea what it is I may be doing wrong but here is my code

    mx2cc version:
    Mx2cc version 1.1.12

    It might not work if I copied my code wrong, but this is pretty much it. I don’t think I saw your updated flag either @admin!

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

You must be logged in to reply to this topic.