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.
Problem with GetColor...
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
-
- Citizen
- Posts: 67
- Joined: Fri Mar 07, 2014 8:16 pm
Re: Problem with GetColor...
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
This appears to do what you want: https://love2d.org/wiki/Canvas:getPixel
Re: Problem with GetColor...
Kisra, welcome!
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:
to this:
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
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))
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
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
- zorg
- Party member
- Posts: 3465
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Problem with GetColor...
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 True 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.
Re: Problem with GetColor...
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:
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!
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
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!
Re: Problem with GetColor...
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.
Re: Problem with GetColor...
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.
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.
Who is online
Users browsing this forum: Semrush [Bot] and 2 guests