Enemy Moves Hard To See on Gray Tiles

Production of artwork for the game by regular contributors takes place here.

Moderators: Forum Moderators, Developers

Inuyasha
Posts: 15
Joined: November 15th, 2005, 6:22 am

Post by Inuyasha » December 10th, 2005, 11:00 pm

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!

freim
Retired Terrain Art Director
Posts: 1113
Joined: November 29th, 2003, 11:40 pm
Location: Norway

Post by freim » December 10th, 2005, 11:11 pm

Inuyasha, a fix has been commited to trunk.

ott
Inactive Developer
Posts: 838
Joined: September 28th, 2004, 10:20 am

Post by ott » December 12th, 2005, 7:49 am

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.
This quote is not attributable to Antoine de Saint-Exupéry.

User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar » December 12th, 2005, 1:45 pm

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.
I noticed the lag, but wasn't entirely sure that i hadn't just become hyper-sensitive.

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

anyeos
Posts: 27
Joined: May 12th, 2005, 7:17 pm
Location: Argentina
Contact:

Sorry, but...

Post by anyeos » December 12th, 2005, 6:19 pm

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.

Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Re: Sorry, but...

Post by Darth Fool » December 12th, 2005, 7:04 pm

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.
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
Posts: 27
Joined: May 12th, 2005, 7:17 pm
Location: Argentina
Contact:

I suggested some things

Post by anyeos » December 12th, 2005, 7:28 pm

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.

anyeos
Posts: 27
Joined: May 12th, 2005, 7:17 pm
Location: Argentina
Contact:

Re: Sorry, but...

Post by anyeos » December 12th, 2005, 7:33 pm

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.
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.


Bye.

User avatar
Noyga
Inactive Developer
Posts: 1790
Joined: September 26th, 2005, 5:56 pm
Location: France

Post by Noyga » December 12th, 2005, 11:53 pm

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.
The problem with "2' only is that the problem still remain on dark tiles like caves & dwarvish castle, particularly at night...

User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar » December 13th, 2005, 2:43 am

Noyga wrote:
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.
The problem with "2' only is that the problem still remain on dark tiles like caves & dwarvish castle, particularly at night...
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.

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

User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar » December 14th, 2005, 5:59 pm

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.
Attachments
Can't go there overlay2.jpg
Can't go there overlay2.jpg (125.56 KiB) Viewed 4371 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

Emmanovi
Posts: 266
Joined: October 21st, 2005, 4:24 pm
Location: In a galaxy, far, far away........

Post by Emmanovi » December 14th, 2005, 11:50 pm

I feel a little brighter. I often need to look at units while I have a unit selected... I would hate to have to deselect to see clearly.
If white was black and black was white, what would happen to zebra crossings?

User avatar
Ranger M
Art Contributor
Posts: 1965
Joined: December 8th, 2005, 9:13 pm
Location: England

Post by Ranger M » December 14th, 2005, 11:59 pm

I always thought It would be a good Idea to have option with both your units moves, and the enemy's best moves at the same time.

User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar » December 1st, 2006, 4:24 am

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.
Attachments
darken.jpg
darken.jpg (226.42 KiB) Viewed 4142 times
darken.png
darken.png (11.74 KiB) Viewed 4142 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

User avatar
Thrawn
Moderator Emeritus
Posts: 2047
Joined: June 2nd, 2005, 11:37 am
Location: bridge of SSD Chimera

Post by Thrawn » December 1st, 2006, 4:47 am

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
...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

Post Reply