Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  getRGB() on an image  (Read 427 times)
0 Members and 1 Guest are viewing this topic.
Offline herah

Senior Newbie





« Posted 2013-03-26 20:38:51 »

I am working on a game that uses an image I drew as the background. I want to be able to scan the image at the location of the player to determine whether I am standing in front of a door or not.

I am using this method to check the pixel color of my image, and it returns the same number no matter where I am standing, so I am obviously using it wrong.

1  
2  
3  
4  
5  
6  
   public boolean door(int playerX, int playerY){
      System.out.println("pixel color: " + imLd.getImage(ribImages[level-1]).getRGB(playerX, playerY));
      if(imLd.getImage(ribImages[level-1]).getRGB(playerX, playerY)== 573128);
      isOverDoor = true;
      return isOverDoor;
   }

this prints "pixel color: -12247529" always.
Here is the call to it in my update method:
1  
2  
3  
ribsMan.door(ninja.locx+ninja.width/2, ninja.locy-150);  
//This is just a point I am feeding in that I know is on the door with nothing blocking it.
//I will change it to be not hardcoded once I get it working.

Offline Gamerulf

Junior Member


Medals: 2



« Reply #1 - Posted 2013-03-26 20:43:30 »

Wouldn't it be easier to set coordinates for the door and see if you player stand within those coordinates with an if-statement?

- Gamerulf
Offline herah

Senior Newbie





« Reply #2 - Posted 2013-03-26 20:47:11 »

I don't know if that would be easier or not. I have 12 levels in a building and about 40 doors. Finding the exact coordinates of each door and storing them will be a pain, but can be done. I thought it made more sense to simply check the image itself so that further levels could be added with the same color scheme without needing to locate every door again through pixels.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Gamerulf

Junior Member


Medals: 2



« Reply #3 - Posted 2013-03-26 21:17:49 »

I looked around, you need to convert your integer pixel to an rgb value.

Try this..
1  
2  
3  
int pixelColor = imLd.getImage(ribImages[level-1]).getRGB(playerX, playerY);
Color c = new Color(pixelColor);
int rgb = c.getRGB


This returns the color in sRGB thought..

This seems inefficient since you have 40 doors.

EDIT: Sorry, I have misread your question.. The value is the same wherever you stand on the map. Didnt get that.

- Gamerulf
Offline Axeman

Senior Member


Medals: 7



« Reply #4 - Posted 2013-03-27 01:27:45 »

What values are playerX and playerY? Have you checked that the point playerX/playerY actually is in the area of the door?
Offline philfrei
« Reply #5 - Posted 2013-03-27 02:38:18 »

I think Gamerulf is onto the answer. The getRGB() is going to return a value in the default color model. So, chances are the alpha value will be included as well, and I'm not sure of the order, for example, if alpha is first or last. But you should be able to do a bit-shift operation to get just the RGB and lose the A, rather than go to the trouble of instantiating a new color.

What you are doing is an interesting idea, but rarely done. Part of the problem is that now this color is serving two purposes--visual appearance and collision detection. If for any reason you decide you want a different color, or to use the same color for anything else, then you are opening yourself up to collision detection bugs.

However, I think it's an interesting idea to have a second "screen" (memory array) that stores indexes to the object occupying that space (instead of pixels). The second screen can be smaller because you may only need a byte or at worst a short to track all your objects, and because blocks of 4 or 9 or 16 pixels (actually you can pick any shape) may accurately represent positions. (Important, a block of pixels can only hold one object at any time.)

(If you allow a block to hold more than one object, then you effectively are using the "bin" method of collision detection.)

Downside: when you move, you have to update this second screen as well as print your image. But it makes collision detection pretty much a linear rather than an exponentially expanding problem as you add more items to the check.

Anyway, most folks will say this idea is nuts and overkill, especially if you are only dealing with a few dozen objects, in which case brute force collision detection is a simple and adequate solution.

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (35 views)
2014-07-24 01:59:36

Riven (33 views)
2014-07-23 21:16:32

Riven (21 views)
2014-07-23 21:07:15

Riven (24 views)
2014-07-23 20:56:16

ctomni231 (55 views)
2014-07-18 06:55:21

Zero Volt (47 views)
2014-07-17 23:47:54

danieldean (38 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!