Problem with GetColor...

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
Kisra
Prole
Posts: 1
Joined: Wed Dec 06, 2017 12:27 am

Problem with GetColor...

Post by Kisra » Wed Dec 06, 2017 12:38 am

Hi,

I am new to game development and am trying to make a game which does a simple task: a player touches an object and receives a point. I am using GetColor for collision detection (please do not recommend a different method). Example of my code:

if love.keyboard.isDown("s") then
p1y=p1y + 1
r, g, b = love.graphics.getColor(p1x, p1y+(1))
end
if r==0 and b==0 and g==0 then
score=score+1
leftpupy=love.math.random(40, HEIGHT)
leftpupx=love.math.random(0, MID_WIDTH)
rightpupy=love.math.random(40, HEIGHT)
rightpupx=love.math.random(MID_WIDTH, WIDTH)
end

So as you can see, the purpose is to check the next pixel in the direction the player sprite is moving to see if that pixel is the color of the object sprite, and if it is the score goes up by 1 and new objects are spawned. However, no matter what I do, the getColor methods ONLY return white (255, 255, 255). Doesn't matter what color the background is set to, or what color the sprite is, or how many pixels ahead the getColor checks. I am truly stumped.

WetDesertRock
Citizen
Posts: 65
Joined: Fri Mar 07, 2014 8:16 pm

Re: Problem with GetColor...

Post by WetDesertRock » Wed Dec 06, 2017 6:27 am

getColor doesn't take any arguments (as the wiki indicates). The only thing getColor does is gets you the color of the last "setColor" call.

This appears to do what you want: https://love2d.org/wiki/Canvas:getPixel

User avatar
Sasha264
Prole
Posts: 10
Joined: Mon Sep 08, 2014 7:57 am

Re: Problem with GetColor...

Post by Sasha264 » Thu Dec 07, 2017 6:31 am

Kisra, welcome! :awesome:

love.graphics.getColor() is not that you are looking for. It just returns your "paint brush" color, not screen pixel color.
If you want to get the color of the pixel on screen you can replace this:

Code: Select all

r, g, b = love.graphics.getColor(p1x, p1y+(1))
to this:

Code: Select all

local screenshot = love.graphics.newScreenshot()
local r, g, b, a = screenshot:getPixel(p1x, p1y+1)
collectgarbage() -- if you will take screenshots every frame without this - you highly probable will have some memory problems
But this is very (VERY) slow solution, because your program needs to copy all screen pixels from gpu-memory to main-memory.
Here is another (slightly better) options using canvases, but this one is simplest you can try.

The best option is never try to get screen pixels. Except some rare situations. Collision detection is not that one :3

User avatar
zorg
Party member
Posts: 1911
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Problem with GetColor...

Post by zorg » Thu Dec 07, 2017 10:39 am

Kisra wrote:
Wed Dec 06, 2017 12:38 am
I am new to game development...
...I am using GetColor for collision detection...
...(please do not recommend a different method)...
Allow me to be nice and just point out a few things with the above 3 things.
The first is a totally normal thing, we all started out somewhere!
The second is a bit of a complex thing, because 1. i understand that you want to use the on-screen pixel color to detect collisions, but 2. love.graphics.getColor doesn't do what you want it to, as others have already explained.
The third thing shows a bit of a childish attitude, but even then, people don't want you to change your mind, they just want to offer alternative, more often than not, better solutions;

Now, even if you don't query the screen or a canvas itself for pixel color information, you can still do pixel (or other region)-color-based collisions; Your best bet would be to have a separate array (i'm guessing you're not too familiar with luaJIT's FFI, so let's stick with plain old lua tables), fill that up with data about your world, and whenever you need to test against a pixel on screen, just check that table;
Pros include it being fast, reliable, doesn't unnecessarily move data between the main RAM and the memory on your graphics card, and probably some more that i've forgot to mention. Any cons that there might be are outnumbered by the pros.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

User avatar
erasio
Citizen
Posts: 91
Joined: Wed Mar 15, 2017 8:52 am
Location: Germany

Re: Problem with GetColor...

Post by erasio » Thu Dec 07, 2017 7:57 pm

I absolutely have to agree with zorg here.

The only con is that you have to take care of the data yourself.

But that's not hard at all!

Here's a short version how you could get exactly the behavior you want with just three small helper functions:

Code: Select all

map = {}

function addObject(x, y, r, g, b)
  if not map[x] then
    map[x] = {}
  end
  
  map[x][y] = {r, g, b}
end

function removeObject(x, y)
  if map[x] then
    map[x][y] = nil
  end
end

function getMapColor(x, y)
  if map[x] then
    if map[x][y] then
      return unpack(map[x][y])
    end
  end
  
  return 0, 0, 0
end
x, y being the coordinates.

r, g, b being the color values as you've been using.

If you add your objects to the map (with "addObject") ontop of drawing them you have all you need!

Edit: 0, 0, 0 are default returns. You can replace this with whatever you want to get in return if it's not your object!

grump
Party member
Posts: 200
Joined: Sat Jul 22, 2017 7:43 pm

Re: Problem with GetColor...

Post by grump » Thu Dec 07, 2017 10:22 pm

NB: These simple methods and examples work best for worlds that are made of static, axis aligned bitmaps or solid rectangles that are neither scaled nor rotated, and ideally are 1x1 pixels in size. If your world is more complex than that, you gonna need a tiny bit more effort to make things work.

User avatar
erasio
Citizen
Posts: 91
Joined: Wed Mar 15, 2017 8:52 am
Location: Germany

Re: Problem with GetColor...

Post by erasio » Fri Dec 08, 2017 11:56 pm

Very fair points. I got ahead of myself.

We would need a more specific use case and the reason for not wanting another way of doing this to properly suggest a good solution.

Post Reply

Who is online

Users browsing this forum: Yahoo [Bot] and 10 guests