Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 RegisterRegister   
 Whatdotcolour Conflict
Index -> Programming, Turing -> Turing Help
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic
Author Message
Flea




PostPosted: Tue Aug 02, 2005 7:22 pm   Post subject: Whatdotcolour Conflict

Hey everyone! I haven't posted in a while but I've still been around lurking and stuff, practicing my programming. Anyway i started making a new game, and I'm stuck.

The game uses whatdotcolour to find if there is a collision with a special object. So... whenever your character runs into a colour that is ~=7, you gain a point. These objects are multicoloured and use like every colour in the spectrum.
I also have this one object that is red and grey (12 and 31 or something). When your player hits these, you die.

Everything was going fine until a couple of my images contained these colours and instead of adding a point, you die.

If you guys want the code I can post or pm it but I'm kind of embarassed of it lol Confused (its nothing bad or anything)

Anyway is there any way in photoshop that i can get rid of colour 31 and 12 in my selected images? Or another way around this? (yes i know this is a turing forum, but I'm using turing so i figured it would be okay to put it here)

If you dont understand the problem just let me know.
Sponsor
Sponsor
Sponsor
sponsor
[Gandalf]




PostPosted: Tue Aug 02, 2005 7:39 pm   Post subject: (No subject)

For more colourful, complex kinds of games, whatdotcolour might not be enough.

There are many collision detections strategies - look them up in the tutorials section.

-tile based system
-text map files
-Math.Distance
-having two layers, one for collision detect and one for what is shown (then you can use wdc but it will run significantly slower).
Flea




PostPosted: Tue Aug 02, 2005 8:17 pm   Post subject: (No subject)

First, thanks for the quick reply. I'm thinking of switching to another type of collision detection, but if im remaking this part of my program, it's gonna be a big change and i want to make sure i make the best choice. I was hoping i could kill 2 birds with one stone... the game runs pretty slowly right now and that is because I have a 70x70 player with whatdotcolour collision in an array inside the main loop (ive reduced it as much as possible, liek for where its applicable i took collision on only the corners and centre) but what makes the program run slowly the most? Loaded pictures? the arrays within the loop? or is whatdotcolour slow?

My game is constant one-way side-scrolling. A tile system won't work at this stage. I've never used math.distance (i'm still on v4.0.4c, i guess i should pick up v.5)

By two layers do you mean having wtc for terrain and such and then having like tiles for the object? I don't think it would run that much more slowly, but we'll see. Going the lazy route (bad, yes but I'm in no rush to cram turing data into my skull as fast as i can, my goal is to finish this program (bad,yes)) i'd probably do the double-layer thingy. What do you reccomend for the second layer then?

Is there no other way around this problem? I'm sure i could get rid of it in PS but I just don't know how...

thanks for the help gandalf
Delos




PostPosted: Tue Aug 02, 2005 8:19 pm   Post subject: (No subject)

I would recommend against using wdc collision detection, even if you have primitive colours. Instead, work around the idea that you will be dealing with a series of objects, with a known x- and y- coord, as well as a known x-width and y-width. As Gandalf suggested, Math.Distance() could be used, especially for complex shapes.


You posted just as I did.

Math.Distance() is nothing amazing. It's just Pythagoras.
The dual layer Gandalf was referring to follows this idea:
- areas of a map can be one of several things: traversable, non-traversable, painful, etc
- one will draw an 'under screen' of the current map, but areas will be highlit based on their property. This means that if you had a ladder on the actual map, you'd have a solid bar of blue, indicating that that area of the map can be vertically scaled.
- one then finds all wdc collisions and restrictions, draws the over map and characters, then updates the screen.
It's quite effective, but can be slow as mentioned. I personally still prefer the mathematical approach since its far more applicable to other cases.
Cervantes




PostPosted: Wed Aug 03, 2005 7:45 pm   Post subject: (No subject)

Something other than wdc would probably be better, but you asked the question so here's the answer I give:
Use RGB.GetColour to get the colour of the colour number you are interested in. Then figure out whatever it tells you in terms of a scale from 0 to 255, which is what photoshop goes by. Now you know you're colour in terms of it's red, green, and blue components. Just make sure that when you change that colour, you change it enough to make Turing think it's a different colour (maybe instead of colour 31, it thinks it's colour 30). You may want to do a RGB.GetColour of the next shade to see how much you have to tweak it by.
[Gandalf]




PostPosted: Wed Aug 03, 2005 8:15 pm   Post subject: (No subject)

Well, I just made a simple program, and it doesn't seem to recognize any of the 255 colours as the same thing. It just gets confusing because of things like colour #31 being the same as #0 and #32 is the same as #9. Also, #248+ wdc thinks that everything is black (#7).
So, in conclusion, you might want to explore other options first Wink.

If you are going to use wdc for collision detection, just make sure that you don't use the name of the colour, like 'green' 'black', etc.
Cervantes




PostPosted: Wed Aug 03, 2005 8:46 pm   Post subject: (No subject)

Why not use the colour name?
code:

put green
put black

This returns low numbers, not the duplicates found later on that are never returned via whatdotcolour.

Also, what I'm saying is that Turing's whatdotcolour finds the closest match in its palette to what it sees on the screen. If you're using a standard palette, Turing will think that a colour {R = 100, G = 60, B = 150} is the same as another colour {R = 101, G = 60, B = 150}.
[Gandalf]




PostPosted: Wed Aug 03, 2005 9:40 pm   Post subject: (No subject)

Oh, yes, I am not talking about RGB colours, just the normal Turing colours.

Say, if you had a picture you imported, and you are using whatdotcolour(x,y,green) then that will not really be accurate if you are depending on it to take into consideration any green-ish colour.

This post may not make sense, I am tired...
Sponsor
Sponsor
Sponsor
sponsor
Flea




PostPosted: Thu Aug 04, 2005 4:38 pm   Post subject: (No subject)

The problem isn't finding out the rgb values (i dont even use RGB.GetColour, i just print screen and use the eye dropper in ps), the problem is removing that colour from my picture. Magic wand doesen't do the trick.

I think i should probably be asking this on a photoshop forum. I know i can get this to work, but in future programs I am definately going to use a different collision type. (Also, i sTILL dont have v4.0.5 (I'd get it from my teacher but i dont have turing class for a loooong time (and its summer))) But if you guys arent allowed to distribute the update thats totally fine with me.

I guess nobody would know the range of colours I'd have to remove to stop photoshop from recognizing one colour from the next. I'll just experiment and maybe post what I find. Who knows, it could be useful to someone else trying to do the same thing, although i really dont reccomend anyone wanting to try this, cause its a huge waste of time and screws your program over if you have fancycolour images lol. Laughing
Display posts from previous:   
   Index -> Programming, Turing -> Turing Help
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 1 of 1  [ 9 Posts ]
Jump to:   


Style:  
Search: