Enemy Moves Hard To See on Gray Tiles
Moderator: Forum Moderators
I have a possible solution
I must test it and verify but I have a possible solution.
Just when you have highlighted the tiles the other tiles are in black and white. The highlighted ones are in colour. Just the castle, what color is? gray, gray is not a color. Then if you give the castle some color the problem will be solved.
Of course the other solution is just giving an uniform color to the tiles where you cannot move. But if someone creates an tile with the same color as used for highlight the problem will reapears.
I suggest: Give some color (or brightness or contrast) to the castle image tile.
Bye.
Just when you have highlighted the tiles the other tiles are in black and white. The highlighted ones are in colour. Just the castle, what color is? gray, gray is not a color. Then if you give the castle some color the problem will be solved.
Of course the other solution is just giving an uniform color to the tiles where you cannot move. But if someone creates an tile with the same color as used for highlight the problem will reapears.
I suggest: Give some color (or brightness or contrast) to the castle image tile.
Bye.
Done
I was done that and is acceptable, see the pictures:
1 - In day
2 - In dusk
3 - In night
1 - In day
2 - In dusk
3 - In night
- Attachments
-
- Castle in day
- castle-in-day.png (156.58 KiB) Viewed 6574 times
-
- Castle in dusk
- castle-in-dusk.png (201.91 KiB) Viewed 6562 times
-
- Castle in night
- castle-in-night.png (189.8 KiB) Viewed 6575 times
The castle tile what I was used
And here the castle tile.
PD: I posted it separated because the forum system don't let me attach more files in the last post.
PD: I posted it separated because the forum system don't let me attach more files in the last post.
- Attachments
-
- The castle modified tile.
- castle.png (1.86 KiB) Viewed 6554 times
-
- Retired Terrain Art Director
- Posts: 1113
- Joined: November 29th, 2003, 11:40 pm
- Location: Norway
Re: The castle tile what I was used
Hianyeos wrote:And here the castle tile.
PD: I posted it separated because the forum system don't let me attach more files in the last post.
I appreciate your effort, but I believe this is the wrong approach.
Terrain/building art should not be limited by a sub-optimal movement highlighting. Basicly, art should not be changed because, mov. highlight sucks atm, the highlight itself should be changed instead
I think eleazars proposal sounds good.
What is the problem?
You are art developer, you can do that in a best way than me. I think: what is the problem?
If you make your art in a not suitable form for the player, that is not good for the player. Do you play the game?
If you just plan to make very bad castles? Must the coders modify the source for just change that of your art and make it suitable for the game?? Or Must just you modify the art to be suitable too? I guess that two sides must be in accordance. If your accordance is not modify art but code, ok, that will be.
I'm art developer, music composer, and coder. I have other works to do. I know some about that. I always use the most effective metods, don't go around. Modifing the code for that purpose is so hard and only a castle tile is affected. Why modify all for only a castle tile?? Is not so easy just modify only the castle tile? (Almost for now) I don't understand you. If you want to be perfect in a art design then you must take too much things (for example the monitor heat). You know what you can discriminate some colours because the human eye cannot distingish that. You can implement techniques to colorize an image or to contrast it or something what you want to do with your art. I think that is not hard modify the castle tiles. Anyway we must to modify something. If you make code for implement a filter in a colour you will be modifying the art anyway or the resulting art from the game. What is the difference modifying it from the file or modifying it from code??? The difference is in the second the file stays unmodified and in the first the file is modified and the code stays unmodified.
Bye.
If you make your art in a not suitable form for the player, that is not good for the player. Do you play the game?
If you just plan to make very bad castles? Must the coders modify the source for just change that of your art and make it suitable for the game?? Or Must just you modify the art to be suitable too? I guess that two sides must be in accordance. If your accordance is not modify art but code, ok, that will be.
I'm art developer, music composer, and coder. I have other works to do. I know some about that. I always use the most effective metods, don't go around. Modifing the code for that purpose is so hard and only a castle tile is affected. Why modify all for only a castle tile?? Is not so easy just modify only the castle tile? (Almost for now) I don't understand you. If you want to be perfect in a art design then you must take too much things (for example the monitor heat). You know what you can discriminate some colours because the human eye cannot distingish that. You can implement techniques to colorize an image or to contrast it or something what you want to do with your art. I think that is not hard modify the castle tiles. Anyway we must to modify something. If you make code for implement a filter in a colour you will be modifying the art anyway or the resulting art from the game. What is the difference modifying it from the file or modifying it from code??? The difference is in the second the file stays unmodified and in the first the file is modified and the code stays unmodified.
Bye.
-
- Retired Terrain Art Director
- Posts: 1113
- Joined: November 29th, 2003, 11:40 pm
- Location: Norway
Re: What is the problem?
The art is not the problem here. The highlight is, and thus that should be fixed. I also believe the fix is rather easy to implement.anyeos wrote:You are art developer, you can do that in a best way than me. I think: what is the problem?
If you make your art in a not suitable form for the player, that is not good for the player. Do you play the game?
If you just plan to make very bad castles? Must the coders modify the source for just change that of your art and make it suitable for the game?? Or Must just you modify the art to be suitable too? I guess that two sides must be in accordance. If your accordance is not modify art but code, ok, that will be.
I don't believe the castle to be bad because the highlight don't worl as well as it should. This is not a terrain problem, and has never been. Changing the art is a poor work-around, not a proper solution.
Don't forget that not only the castle is problematic. Other terrains like snow and ice are affected, too. In general ALL terrains that are very "bright" are effected. And it can not be the target to "fix" ALL these terrains where it would be rather simple to either change the color of the movement highlighting, or put a thick outline around the area you can move to.
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
Elezear: this should not be hard to implement in code. Of course, I am following behind on getting all the things done that I say should be easy to do. Hopefully, I can start catching up in a few weeks.
"you can already do that with WML"
Fight Creeeping Biggerism!
http://www.wesnoth.org/forum/viewtopic. ... 760#131760
http://www.wesnoth.org/forum/viewtopic. ... 1358#11358
Yes, you have reason.
Yes, I'm in accordance what not only the tile castle is the affected terrain and in that situation don't must modify ALL terrain. In that way is more easy modify the code.
Sorry I was some mind closed. I mistake in the last solution. That not was the solution for all, that only solved some about castle tile.
Sorry I was some mind closed. I mistake in the last solution. That not was the solution for all, that only solved some about castle tile.
Lowering the brightness?
What about lowering the brightness?
First attachment is a decent lowered brightness in the grayed areas.
The second is a very lowest brightness for have an idea how it see (near black).
And the third still near black but not at all.
The selected character is always the ancient mage.
First attachment is a decent lowered brightness in the grayed areas.
The second is a very lowest brightness for have an idea how it see (near black).
And the third still near black but not at all.
The selected character is always the ancient mage.
Last edited by anyeos on December 5th, 2005, 10:36 am, edited 1 time in total.
About colored
Now, what about coloring?
Coloring only is not the best solution as we can see.
But combining colored and bright lowered seem best.
This is not an modified image, it is a real screenshot. I'm testing with real code.
Personally I liked the last obtained (colored with lowest bright).
What do you prefer?
I was made a function called "colored_image" copying the body from "greyscale_image" and modifying it to fit the needs. It is in the file "sdl_utils.cpp".
And I was modified too the file "image.cpp" in the function "get_greyed".
Here the function in the file "sdl_utils.cpp":
surface colored_image(surface const &surf, const Uint8 cred, const Uint8 cgreen, const Uint8 cblue, const Uint8 brightness)
{
if(surf == NULL)
return NULL;
surface nsurf(make_neutral_surface(surf));
if(nsurf == NULL) {
std::cerr << "failed to make neutral surface\n";
return NULL;
}
{
surface_lock lock(nsurf);
Uint32* beg = lock.pixels();
Uint32* end = beg + nsurf->w*surf->h;
while(beg != end) {
Uint8 red, green, blue, alpha;
SDL_GetRGBA(*beg,nsurf->format,&red,&green,&blue,&alpha);
Uint8 avg_red =(Uint16)(red+cred)*brightness/100 > 255 ? 255 : (Uint8)((red+cred)*brightness/100);
Uint8 avg_green =(Uint16)(green+cgreen)*brightness/100 > 255 ? 255 : (Uint8)((green+cgreen)*brightness/100);
Uint8 avg_blue =(Uint16)(blue+cblue)*brightness/100 > 255 ? 255 : (Uint8)((blue+cblue)*brightness/100);
*beg = SDL_MapRGBA(nsurf->format,avg_red,avg_green,avg_blue,alpha);
++beg;
}
}
return create_optimized_surface(nsurf);
}
And here the modified "get_greyed" in the file "image.cpp":
surface get_greyed(const locator i_locator, COLOUR_ADJUSTMENT adj)
{
surface image(get_image(i_locator, SCALED, adj));
return surface(colored_image(image, 60, 0, 60, 60));
}
Sorry about posting code here but I don't have the wesnoth 1.0.2 source code now and I cannot generate a bad path.
Coloring only is not the best solution as we can see.
But combining colored and bright lowered seem best.
This is not an modified image, it is a real screenshot. I'm testing with real code.
Personally I liked the last obtained (colored with lowest bright).
What do you prefer?
I was made a function called "colored_image" copying the body from "greyscale_image" and modifying it to fit the needs. It is in the file "sdl_utils.cpp".
And I was modified too the file "image.cpp" in the function "get_greyed".
Here the function in the file "sdl_utils.cpp":
surface colored_image(surface const &surf, const Uint8 cred, const Uint8 cgreen, const Uint8 cblue, const Uint8 brightness)
{
if(surf == NULL)
return NULL;
surface nsurf(make_neutral_surface(surf));
if(nsurf == NULL) {
std::cerr << "failed to make neutral surface\n";
return NULL;
}
{
surface_lock lock(nsurf);
Uint32* beg = lock.pixels();
Uint32* end = beg + nsurf->w*surf->h;
while(beg != end) {
Uint8 red, green, blue, alpha;
SDL_GetRGBA(*beg,nsurf->format,&red,&green,&blue,&alpha);
Uint8 avg_red =(Uint16)(red+cred)*brightness/100 > 255 ? 255 : (Uint8)((red+cred)*brightness/100);
Uint8 avg_green =(Uint16)(green+cgreen)*brightness/100 > 255 ? 255 : (Uint8)((green+cgreen)*brightness/100);
Uint8 avg_blue =(Uint16)(blue+cblue)*brightness/100 > 255 ? 255 : (Uint8)((blue+cblue)*brightness/100);
*beg = SDL_MapRGBA(nsurf->format,avg_red,avg_green,avg_blue,alpha);
++beg;
}
}
return create_optimized_surface(nsurf);
}
And here the modified "get_greyed" in the file "image.cpp":
surface get_greyed(const locator i_locator, COLOUR_ADJUSTMENT adj)
{
surface image(get_image(i_locator, SCALED, adj));
return surface(colored_image(image, 60, 0, 60, 60));
}
Sorry about posting code here but I don't have the wesnoth 1.0.2 source code now and I cannot generate a bad path.
I've made a quick patch (against SVN trunk) that tints the tiles out of the path like Elezear suggested (77%,67%,72%).
I also brightened a little the path since it was hard to see on dark tiles (on caves or dwarvish castle at night for example).
I previously tested with a color offset but this seemed ugly and unnatural to me.
I also brightened a little the path since it was hard to see on dark tiles (on caves or dwarvish castle at night for example).
I previously tested with a color offset but this seemed ugly and unnatural to me.
Yes
Yes, that is well done. Let that so.
In this time I was learned some about image filtering and manipulation in code
It was a nice experience for me.
My code just only colorize an image, don't gray it first and later colorize as your code do.
I prefer greying it first and later colorizing as you did, but colorizing it only does not seem bad.
Bye
In this time I was learned some about image filtering and manipulation in code
It was a nice experience for me.
My code just only colorize an image, don't gray it first and later colorize as your code do.
I prefer greying it first and later colorizing as you did, but colorizing it only does not seem bad.
Bye