Cursor and Tool Tip Display

Matrix Games Forums

Forums Register Login Photo Gallery Member List Search Calendars FAQ

My Profile Inbox Address Book My Subscription My Forums Log Out

Cursor and Tool Tip Display

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [New Releases from Matrix Games] >> War in the Pacific: Admiral's Edition >> Tech Support >> Cursor and Tool Tip Display

Page: [1]

Message

<< Older Topic Newer Topic >>

Cursor and Tool Tip Display - 7/30/2013 7:32:17 PM

DHRedge

Posts: 191
Joined: 1/18/2010
Status: offline

There is an interesting action that occurs.

As designed when you move the cursor to an icon, a tooltip opens, then when it leaves the pixel of the icon the tooltip turns off. (if any mouse move message is a pixel not on that icon, tooltip closes)

Unless you are on the home island of Japan, then the tooltip does not turn off till the cursor leaves a hex on the home island or goes over a ground or naval unit tooltip, or an anchor, airfield, or flag icon in another hex.

This is a different effect then the rest of the map, it only occurs on the home island. I suspect there is some code added to the tooltip pop and close mechanism that does not allow the tooltip to close on the home island unless another tool tip is hovered over, or cursor leaves a homeisland hex.

Most likely there was some bug with the amount of icons on the home island popping and unpopping tooltips, and the speed of computers in the original code from early 2000s so that was a hack to stop some issue of qued tooltips runninig behind the cursor.

However if you move the cursor from Navy yard to flag icon or airbase icon, their is no opening of the tooltip for that item, until you move cursor off a home island hex or onto a unit or ships icon. That is a loss of functionality.

To reproduce the bug, or as designed workaround for slower computers and some tooltip issue, move the cursor over a flag icon on a hex of the home island of Japan, then move the cursor around the map while staying on the home island. Instead of the tooltip closing when it moves to a non icon pixel, it stays open. If you then move to an anchor or airbase in the same hex as the flag, it does not change to that icon's tooltip. The behavior only happens on the home island where there are many icons.

I suspect in the tooltip close code the area of code to look at is
if cursor xy is some pixel that is not an icon close toolbar window
then there is some code that says, 'unless pixel is in hex' then some list of home island hexes.

It is not a bounding box, it is actual hexes that have the different functionality, so it could be that the code is in a function where the code checks the hex on a mousemove message, then checks the data in the icon hovered over in the hex, or closes if not over an icon.

The issue is if you are looking at the navy tooltip, and want to look at the airbase tooltip, you have to move your mouse off the home island, or to a ship or ground unit first then back to the airbase you want to inspect with by seeing the tooltip.

Note, this functionality must have been added in intentionally. Debugging mouse messages are a pain since they post so often. (A tip to help debug mouse moves, create a function that posts messages to the window as a user message that then calls the same mouse move sub functions, and turn off mouse messages calling those functions, then script test the code in that section of code, so you can emulate functionality in debugger without having to mouse over GUI. Although not needed to fix this issue)

I suspect it is to try to stop some bug from appearing on slower systems that were popping many tooltips while moving over home island, so if that code fix is removed to make the behavior more consistent, and to have tooltips close when cursor moves to land or other icon on homeisland, check the functionality on a slower computer. Or emumutate a slower computer by turning off hardware rendering support or video memory usage or something like that, to make sure it was not added to correct some other issue.

Although if it was added to fix some other issue (stacked qued tooltips lagging and popping behind the cursor, for example), peeking the message fifo stack for mouse moves and only processing the last one, and removing others stacked in que would have been a better way to handle the issue if it was added in as a fix for there being many icons on home island, and slower response time of tooltip open close. Peek message has a remove ability(popping), set that and peek till getting last mouse move message, and skip actions on all others on the message stack, or there are many other ways to do same process. (note if some API layer is used to get to windows API, could be different).

Simple way to understand, pop mouse move message at front of function for all tooltip processing, if another in que, keep popping till you get to last one, then process on that message xy.

Also instead of create tooltip window, if 'create window' was to slow, window could be set to visible or not visible, or something like that, on each mouse move if speed of window was an issue. There are a few ways to fix that issue if the problem was speed of processing when tooltips were popped in high density icon area of home islands.

I suspect it was easier to not have to open and close the window, by simply not closing it on the home island, in the previous attempt to try to fix the issue

"On create tooltip", "if no window", "create window" <- creating slowdowns when many request for tooltips were qued. That is the guess of why they implemented 'no close on tooltip' on home islands.

where "On create tooltip window, get handle if already open", it gets the stored window handle to already open window and works faster.

So replacing the close tooltip functionality on the home island, to not closing tooltip window was added in for hexes of Japan home island.

Although switching it to a non visible window, and adding 'is window visible' to front of text processing, and always leaving Window open would correct the same problem, or not processing latent entries in message que(better idea).

The current fix being used creates a minor drop in functionality, and setting window visible not visible, or peeking messages, does the same thing but much faster if that was the issue.

Bug type
It is a minor GUI issue, work around, move cursor off of island to close tooltip as a user workaround to close the tooltip, however it could be repaired pretty easily.

Although not relevant, my vid card is Nividea 765m 2 gigs,
program version the 1.0.6.1108r9 patched version

< Message edited by DHRedge -- 7/30/2013 7:50:55 PM >

Post #: 1

RE: Cursor and Tool Tip Display - 7/30/2013 11:55:31 PM

DHRedge

Posts: 191
Joined: 1/18/2010
Status: offline

To always use the last mouse x,y and not check for every mouse x,y.

Or to make it really simple. If the Windows WinAPI is being used.

Remove the parts that disable the tooltips on Japan Home Islands, whereever that is.

Then at the front of the handler for WM_MOUSEMOVE the part that pops tool tips add something like

int nXToUse;//type int, or long whatever the code uses it probably uses a 32bit signed int
int nYToUse;//

MSG msg;
//ZeroMemory(&msg,sizeof(MSG));//initialize to 0 good form. optional
//by not using, msg is undefined unless a message is found.

//set with the data passed in assuming all x,y
nXToUse = Some var X passed in;//the pixel x that was going to be used for function call
nXToUse = Some var Y passed in;//the pixel y that was going to be used for function call

//for curiosity not needed
//int nRemoveCount = 0;

//get any other pixels stacked in FIFO message que for the WITP AE Window thread
while(::PeekMessage(&msg,NULL,WM_MOUSEMOVE,WM_MOUSEMOVE,PM_REMOVE))
{
//nRemoveCount++;
nXtoUse = msg.pt.x;
nYtoUse = msg.pt.y;
}

//if there are qued WM_MOUSEMOVE messages for the application thread they will be removed
//and the newest mouse pixel location will be set.

(Been 10 years since doing any programming, although should work, assuming it is in C++ and uses Windows API, since there are not mac or linux versions of game, probably a win32 code base, but that is a guess.)

WM_MOUSEMOVE only goes to the thread window handler if it has mouse captured (Active App).

Could also help with some of the delays in highlighting of the display texts on mouse over that occurs in some windows like pilot selection and a few others.

Note, the guy doing the patches probably already knows all this, although it was a puzzle to think on.

< Message edited by DHRedge -- 7/30/2013 11:56:23 PM >

(in reply to DHRedge)

Post #: 2

RE: Cursor and Tool Tip Display - 7/31/2013 7:46:49 AM

DHRedge

Posts: 191
Joined: 1/18/2010
Status: offline

Note the blinking of tool text between two lines in the pilot screen, that is probably overlapping boundary boxes, not due to lag.

For text highlighting,
I have no idea how that GUI is painting text, but there is something that can be done also, when painting for a highlight because of highlight on those menu screens, save the bits that was at that location with a blt to some surface offscreen, and save that bounding box, then there is always a 'bounding box' 'last tooltip highlight', and it gets blted back to non hover state at start of another hover check anywhere not in that box, and if in that box, no reason to change highlight color state. (if screen scroll there might be some math requiered, or just clear rect and set full redraw needed on next hittest after scrolling done, or something like that) if name changes by some user action, redraw and clear blt box of coarse.

So process for every mouse message would be

Get mouse move cursor location from message handler
Remove extras in que

If there was a current highlight Text Blt in the storage, and cursor is not in that same bounding box, blt it back, (turning off last highlight on all mouse moves anywhere on menu or map), and there is no need for knowing the old text, nor processing any drawing functions, nor even what menu it was in to turn off a highlight, and it always gets done first mouse move outside of bounding box. Then set 'someone highlighted rect' to empty rect(0,0,0,0)

if still in same bounding box, do nothing on mouse move

if menu close (esc) clear last storage flag by setting rect to empty.

if not in same bounding, and menu not closed by escape key, and not scrolling where there will be a redraw anyways,

check bounding box for cursor location, if in any bounding rect of an item that needs to be a highlight,
blt current boundry to off surface storage surface, and store the bounding rect being highlighted
then draw the highlighted text as it currently is probably done.

wait for next mouse message.

(Note if no drawing is being done, and a shading is occurring or masking of some type, same process could apply with reversing the shading instead of blt)

I am actually bored, more then anything else, and guessing, fun thinking over a phone call :) heh, something to do though.

if for some reason some mouse messages are not being sent in by operating system(doubtful), a watchdog checker in idle processing checking current pos, and last position, (and if mouse has not moved for 500ms, last last postion from last timer check), could fire a emulated mouse move message correcting any lost positions, and would always be at current mouse location, if sent.

note the blinking tooltip on pilot screen
the bounding overlap of three pixels is probably because of j q g y letters dipping below top of nest text line top, and geting the text bounding box returns overlapped bounding box, add three to the bottom when doing a hit test on lines of text would probably stop that blinking. the blinking is probabably showing two items as in boundry and drawing a tool tip for each one. (note I am using alt font option in command line)

if this is way to irrelevant, and it really is, you can disregard any changes, probably more important things to work on, but something for me to think about.

< Message edited by DHRedge -- 7/31/2013 8:00:48 AM >

(in reply to DHRedge)

Post #: 3

RE: Cursor and Tool Tip Display - 8/1/2013 8:58:40 PM

DHRedge

Posts: 191
Joined: 1/18/2010
Status: offline

The behavior of mouse tooltips, is now also occuring in Indo China, so it may not be a preprogrammed effect, it could be some event based on some combination of units or time to look at units in a hex.

It is still based on hex, and the 'no close of tool tip' also occurs in Burma.

Although there is something true about both tooltips and highlights, weather using windows, or Direct x surfaces. There is always only one tooltip window open, and always only one mouse over highlight. So a storage surface that holds ~~old information~~the tool tip or highlight shading, and is always kept open and used for tooltips and one for highlighting makes sense.

heh, what makes even more sense is have that offscreen surface be the tooltips, and a surface for highlights. Then blt it last, and never change the map or menu surface. For mouse over it would be get area to highlight, blt to storage, do color change, then on rendering cycle then blt tooltip last. And turn the flag on and off for visible or not visible, and move it and construct it on each tooltip pop.

Make the surface for tool tips blt last, over top of previous terrain or menu blt, that might even work better, but still have an always constructed surface that info is blted to, then the storage would always exist since it would be never changed, that might even be a better way to do it.

Probably how the code does that stuff anyways.

Anyways, something for me to think about.

So creating a storage of previous blts would not be needed, they would still be there blt under the tooltip, or highlight. And for highlights a shading blt should be all that would be needed.

However all the stuff about storing current bounding box, and checking mousemoves for stale entries, still makes sense.

The entire drawing of the tooltips code might not be the issue, the issue could be when to draw it, based on mousemove messages detection.

(in reply to DHRedge)

Post #: 4