Enemy Moves Hard To See on Gray Tiles
Moderator: Forum Moderators
I wasn't sure if my post would be taken seriously, but I'm really happy that so many people have been trying to come up with a solution. Hurrah for open source gaming
Anyway, I was wondering if anyone had thought using color inversion for the highlight. Basically the highlighted areas would look like a photo negative. Sorry I don't have Photoshop handy so I can't demonstrate. Granted, inverting the colors might not look that great, but you could also invert only one channel out of a RGB spectrum and see how that that looks.
And there's also the option of simply drawing a solid line where the edge of the highlight is. If you want to get fancy you could assign a different color to specific enemy units or unit types, i.e. melee, archer, magical, etc.
By the way, is there any chance of working on that best possible enemy moves option, e.g. highlighting your units or allied units that can be attacked by two or more enemy units in the next turn in a bright color? I'm not really a programmer, at least not yet, but I hope some of these ideas can help.
thanks!
Anyway, I was wondering if anyone had thought using color inversion for the highlight. Basically the highlighted areas would look like a photo negative. Sorry I don't have Photoshop handy so I can't demonstrate. Granted, inverting the colors might not look that great, but you could also invert only one channel out of a RGB spectrum and see how that that looks.
And there's also the option of simply drawing a solid line where the edge of the highlight is. If you want to get fancy you could assign a different color to specific enemy units or unit types, i.e. melee, archer, magical, etc.
By the way, is there any chance of working on that best possible enemy moves option, e.g. highlighting your units or allied units that can be attacked by two or more enemy units in the next turn in a bright color? I'm not really a programmer, at least not yet, but I hope some of these ideas can help.
thanks!
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
I noticed the lag, but wasn't entirely sure that i hadn't just become hyper-sensitive.ott wrote:Unfortunately the fix seems to cause huge slowdown, to the extent that we may have increased the minimum spec required for the game by a factor of 2 or so. Some optimization seems called for.
As i understand it, the patch does 3 color transformations.
1) greyscales the out-of-reach squares (the old way)
2) shift the RGB to darken the out-of-reach squares
3) the lightens all the reachable squares.
Apparenlty "1" was pretty fast. I don't think "2"+"3" are both neccesary because they both just increase the contrast between the 2 areas of hexes. I.E. a stronger change to either part would create the same distinction.
I believe the job will get done using only "2" i don't know if that will significantly speed things up or not. As it is, the color shifting part doesn't do much, besides darken (because the hexes have already been greyscaled) If shifting RGB together would be faster, that's also viable.
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
-> What i might be working on
Attempting Lucidity
Sorry, but...
Sorry, I don't study how the cache technique works. But, I guess that the caching image just do a work only one time (for speeding up the things). What I mean? I mean what the entire already loaded map will be cached. I mean the images that conform the visual in the map. Some images are dynamic but some others are static. Where you have static images then just cache it (it always will be the same). I don't understand really why it slow down the game. Really that happens? I was tested it (but note that I don't implement the cache portion still) in the code what I was put here and I don't see a slowdown in the game. Maybe the cache is working bad? Or the caching technique of this game is some different than I supposed?
I guess this:
First time the game creates the map just the caching process take place. Last, when a function is called (where you need to do a work already done in cache) it is not called, a call to a cache take place. I mean, the grayed areas already are stored in some variable (not?). When we call the function to make gray a place, it is not called directly, it just address to the variable. Do this work so? or Am I in mistake? If that is so, then, why a slowdown is noticed? if is the same thing (addressing some variable). The hard work is done one time per party, or not?
Bye.
I guess this:
First time the game creates the map just the caching process take place. Last, when a function is called (where you need to do a work already done in cache) it is not called, a call to a cache take place. I mean, the grayed areas already are stored in some variable (not?). When we call the function to make gray a place, it is not called directly, it just address to the variable. Do this work so? or Am I in mistake? If that is so, then, why a slowdown is noticed? if is the same thing (addressing some variable). The hard work is done one time per party, or not?
Bye.
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
Re: Sorry, but...
I haven't looked at the code patch yet, but my guess is that the slow down comes from the fact that greyed images are cached, and my guess is that the tinted ones aren't. It should be simple to fix by adding an extra field "tinted" similar to greyed for when the tinted versions are used.anyeos wrote:Sorry, I don't study how the cache technique works. But, I guess that the caching image just do a work only one time (for speeding up the things). What I mean? I mean what the entire already loaded map will be cached. I mean the images that conform the visual in the map. Some images are dynamic but some others are static. Where you have static images then just cache it (it always will be the same). I don't understand really why it slow down the game. Really that happens? I was tested it (but note that I don't implement the cache portion still) in the code what I was put here and I don't see a slowdown in the game. Maybe the cache is working bad? Or the caching technique of this game is some different than I supposed?
I guess this:
First time the game creates the map just the caching process take place. Last, when a function is called (where you need to do a work already done in cache) it is not called, a call to a cache take place. I mean, the grayed areas already are stored in some variable (not?). When we call the function to make gray a place, it is not called directly, it just address to the variable. Do this work so? or Am I in mistake? If that is so, then, why a slowdown is noticed? if is the same thing (addressing some variable). The hard work is done one time per party, or not?
Bye.
"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
I suggested some things
Sorry posting newly, but I was suggested some things. One of that was lowering the bright of the grayed areas. This appears to be good (you can see the pictures some posts above here). The other is coloring and changing the bright anyway. If you don't change the bright it result in a very bright image hard to understand.
The code for lowering the bright is easy:
const Uint16 darkness = 370;
const Uint8 avg = (Uint8)(( 77*(Uint16)red+150*(Uint16)green+29*(Uint16)blue ) / darkness);
Raising the value of darkness you get a darkest image. And lowering it you get a brigthen one.
Product and division are some slow process. We can reeplace it for a bit shifting.
I was study about converting to greyscale a image and the early solution for this is using this formule: (R + G + B) / 3. But If we want to dark the image then (R + G + B) / 4 maybe a desirable solution and we can use shifting. Using shifting will be: (red+green+blue)>>2.
So:
const Uint8 avg = (Uint8)((Uint16)(red+green+blue)>>2);
This result in a grayed image. To do things with colours you need to process each bit of the image (the R, the G and the B).
Greying it is the more faster process what I know.
The original code was a multiplication of diverses numbers coming from here: 0.30 * R + 0.59 * G + 0.11 * B
That result in a more realistic about how perceptive eye is to a given color. But in a game place that does not matter. If you compare the differences about the result with (R + G + B) / 3 and the 0.30 * R + 0.59 * G + 0.11 * B really is hard to be noticed. So, where the speed is important use the less complex formule.
I'm testing: const Uint8 avg = (Uint8)((Uint16)(red+green+blue)>>2);
and this work well but I see the grayed tiles some dark. That maybe acceptable for some people. Anyway we can still use (R + G + B) / 3.
You can see it in the attached image.
The code for lowering the bright is easy:
const Uint16 darkness = 370;
const Uint8 avg = (Uint8)(( 77*(Uint16)red+150*(Uint16)green+29*(Uint16)blue ) / darkness);
Raising the value of darkness you get a darkest image. And lowering it you get a brigthen one.
Product and division are some slow process. We can reeplace it for a bit shifting.
I was study about converting to greyscale a image and the early solution for this is using this formule: (R + G + B) / 3. But If we want to dark the image then (R + G + B) / 4 maybe a desirable solution and we can use shifting. Using shifting will be: (red+green+blue)>>2.
So:
const Uint8 avg = (Uint8)((Uint16)(red+green+blue)>>2);
This result in a grayed image. To do things with colours you need to process each bit of the image (the R, the G and the B).
Greying it is the more faster process what I know.
The original code was a multiplication of diverses numbers coming from here: 0.30 * R + 0.59 * G + 0.11 * B
That result in a more realistic about how perceptive eye is to a given color. But in a game place that does not matter. If you compare the differences about the result with (R + G + B) / 3 and the 0.30 * R + 0.59 * G + 0.11 * B really is hard to be noticed. So, where the speed is important use the less complex formule.
I'm testing: const Uint8 avg = (Uint8)((Uint16)(red+green+blue)>>2);
and this work well but I see the grayed tiles some dark. That maybe acceptable for some people. Anyway we can still use (R + G + B) / 3.
You can see it in the attached image.
Re: Sorry, but...
I see the source patch and it have an implementation of cache. That is why I'm asking if the cache is working or not. Maybe it must be called first when a party is created and this guy forget about that. I don't know really and now I don't have more time.Darth Fool wrote: I haven't looked at the code patch yet, but my guess is that the slow down comes from the fact that greyed images are cached, and my guess is that the tinted ones aren't. It should be simple to fix by adding an extra field "tinted" similar to greyed for when the tinted versions are used.
Bye.
The problem with "2' only is that the problem still remain on dark tiles like caves & dwarvish castle, particularly at night...Eleazar wrote:I believe the job will get done using only "2" i don't know if that will significantly speed things up or not. As it is, the color shifting part doesn't do much, besides darken (because the hexes have already been greyscaled) If shifting RGB together would be faster, that's also viable.
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
err, good point. i hadn't considered the "outdoor" caves which (ironically) get extra dark at night. My proposal doesn't work in that situation.Noyga wrote:The problem with "2' only is that the problem still remain on dark tiles like caves & dwarvish castle, particularly at night...Eleazar wrote:I believe the job will get done using only "2" i don't know if that will significantly speed things up or not. As it is, the color shifting part doesn't do much, besides darken (because the hexes have already been greyscaled) If shifting RGB together would be faster, that's also viable.
i'll try again...
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
-> What i might be working on
Attempting Lucidity
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
an RGB percentage decrease of R70% G40% B45%
should be visible against all terrain, at all times of day. See example.
I'm not sure of the speed ramifications of various proposals. But mine is more viable now.
As a PS i think it would be great if caves weren't effected by the day-night color tinting, but i don't think that would be a quick change.
should be visible against all terrain, at all times of day. See example.
I'm not sure of the speed ramifications of various proposals. But mine is more viable now.
As a PS i think it would be great if caves weren't effected by the day-night color tinting, but i don't think that would be a quick change.
- Attachments
-
- Can't go there overlay2.jpg (125.56 KiB) Viewed 6920 times
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
-> What i might be working on
Attempting Lucidity
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
Well, the trunk now used a semi-transparent tile rather than a color shift to mark can't-move-to hexes. I exparamented with some textures, and this was my favorite. As usually finding the ballance that works in all situations is tricky. I think there's room for refinement, but that will take time.
A basic staticy noise pattern was interesting too, but tended to make the underlying features too hard to see.
A basic staticy noise pattern was interesting too, but tended to make the underlying features too hard to see.
- Attachments
-
- darken.jpg (226.42 KiB) Viewed 6691 times
-
- darken.png (11.74 KiB) Viewed 6691 times
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
-> What i might be working on
Attempting Lucidity
- Thrawn
- Moderator Emeritus
- Posts: 2047
- Joined: June 2nd, 2005, 11:37 am
- Location: bridge of SSD Chimera
I like it, for all that is worth
no problem of telling where you can't move with this. The only problem I see is that it could look annoying if the entire screen, beyond the screenshot looked like this. Can't tell though, in a small dose it looks fine
no problem of telling where you can't move with this. The only problem I see is that it could look annoying if the entire screen, beyond the screenshot looked like this. Can't tell though, in a small dose it looks fine
...please remember that "IT'S" ALWAYS MEANS "IT IS" and "ITS" IS WHAT YOU USE TO INDICATE POSSESSION BY "IT".--scott
this goes for they're/their/there as well
this goes for they're/their/there as well