4 replies to this topic

[dannyjenn]

Why is the draw_getpixel() function so slow? I've done something similar in JavaScript (also an interpretted language) and it's not nearly as slow...
Is there any hope of it being improved in a later version of Game Maker? Custom colour swaps as well as other effects would be so much easier if I could use that function and not have it practically freeze the game while being run...

Edited by dannyjenn, 13 June 2012 - 03:09 PM.

[Dangerous_Dave]

What are you trying to do?

If you're swapping colours in sprites, do it *once*. Do it in a surface, and create a new sprite from it. That way it's not lagging your game, only a short loading period at the start.

[THE_GAME_EDITOR]

What are you trying to do?

If you're swapping colours in sprites, do it *once*. Do it in a surface, and create a new sprite from it. That way it's not lagging your game, only a short loading period at the start.

And what if i use the colour check for multiple lens flares. Would there be a way to only check once?
As draw_getpixel only check one position.

[GearGOD]

I can tell you why its slow, but I don't think I can suggest any ways around it.

1: Pulling data from the video card memory is slow. Video cards are designed to get data from the rest of the computer very quickly, not so much to push it in the opposite direction.
2: Pulling data stalls the pipeline. Both game maker (I hope) and the graphics driver batch drawing operations together because its cheaper. As soon as you ask for data to be pulled back, all pending drawing operations must happen immediately, then the data sent. While this is happening your code just sits and waits. This is where most of the speed cost is incurred.
3: The biggest problem: GM only allows you to fetch a pixel at a time. For every single pixel you ask, the pipeline is completely stalled. Lower level game engines allow you to request the entire backbuffer or a portion of it to be pulled to system memory in a single operation - only one pipeline flush per surface per frame.

Why was it faster with whatever javascript thing you were doing before? Because in all likelyhood it wasn't rendering over d3d/opengl and was storing raw pixels in system memory. Reading that obviously costs almost nothing.
What can you do about it? I'm afraid the only answer is don't do it.

[famous]

I have to share my view about the problem of draw_getpixel . If it doesn't find it within the first 7x7 or 9x9 rectangle, the program really starts to hang up. Is there any way to get the RGB of a pixel that's faster than CDC.GetPixel()? Thank you very much .

In my Extension "MOCAP" you can find a faster "get_pixel" Function. It's written in assembler but directly access the Window DC, so you can't use it on Surfaces or any area which isn't visible.

Edit: Forgot, this is Mac Forum. Only on Windows.

Edited by famous, 22 June 2012 - 12:36 PM.