Author Topic: There are many ways to go to Rome.  (Read 5356 times)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1542
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #210 on: April 25, 2019, 09:56:35 am »
Is that any better to select a specific dot?

Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1373
Re: There are many ways to go to Rome.
« Reply #211 on: April 25, 2019, 11:01:13 am »
Patrice,

1. Red color is the color reserved for selection. Can the UV hot spots be normally colored with some different clear color, say, cyan or white?

2. When at low zoom levels, both the cross and the fist obscure the entire bullet and texture area beneath it so that the user can't clearly see the exact spot to drop the bullet on. Can there be no cursor seen at all while the bullet is in the process of dragging?

3. When the LMB is released and the bullet is dropped, the zoom control redraws the wireframe tris associated with the hot spot being dragged, at a position slightly different from what it was when the mouse stopped right before the LMB was released. This means the hot spot being dragged always lags one step behind the red bullet while dragging. I don't think that's logically correct. Instead, the hot spot should always be exactly beneath the red bullet all the way while dragged.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1373
Re: There are many ways to go to Rome.
« Reply #212 on: April 30, 2019, 02:36:32 pm »
I will be delighted to test it. It will hopefully bring me back to work. Spring time is so distracting... :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1542
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #213 on: April 30, 2019, 05:13:53 pm »
Here it is…

If that works, then we will have to figure what to do, for updating the .obj file.
This is where the work you have done 10 years ago could come to rescue   8)
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1373
Re: There are many ways to go to Rome.
« Reply #214 on: April 30, 2019, 05:36:58 pm »
Here it is…
Downloaded, thanks!

Quote
This is where the work you have done 10 years ago could come to rescue   8)
Yes, we had a plugin that was able, to an extent, to export some .XAN binary data to a simplified .OBJ file. .XANs used to have features unsupported by the Wavefront specs. I can't recollect now exactly how good or bad the exporter was. But it can certainly serve as a starting point for adding this feature to ObjReader.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1373
Re: There are many ways to go to Rome.
« Reply #215 on: April 30, 2019, 11:35:53 pm »
OK Patrice,

That's a good start for the Undo/Redo stack indeed! My observations follow below:

0. What's the big idea behind changing all the literal #defines in the file to const ints?

1. The current stack is too granular, hence excessive in the number of events to store. Instead, it should follow a pattern like this:
  • If the bullet is dragged by multiple auto-repeated WM_KEYDOWNs, the bullet moves should not go on stack until the corresponding arrow key is released and a WM_KEYUP event is generated. In other words, only two events should go on the Undo/Redo stack: i) initial WM_KEYDOWN at the drag start point, and ii) final WM_KEYUP at the drag end point.
  • In the same vein, only two events should go on stack when dragged by mouse: i) initial WM_LBUTTONDOWN at the drag start point, and ii) final WM_LBUTTONUP at the drag end point.
2. The stack should be able to branch and clear/release the steps that become unreachable due to an alternative later action taken somewhere along the current branch, for example like this:
  • The bullet is dragged from point A to point B in 10 successive WM_KEYDOWN/WM_KEYUP events by an arrow key.
  • The sequence is undone by 5 Undo button presses/steps to somewhere midway between points A and B.
  • At this midpoint M, the LMB is pressed, dragged and released at point C somewhere else in the map. This action should lead to clearing arrow key steps 6 to 10 from memory making point B unreachable as if we haven't been there at all. From this moment on, the entire Undo/Redo stack should look like i) point A, ii) 5 arrow key steps (1 thru 5) to point M, and iii) LMB drag to point C.
3. It would be terrific to have a visual representation of Undo/Redo stack in a windowed list view like in the Paint.NET screenie below. There you can see a short series of actions taken on a loaded image. Following the Eraser action, the stack is rolled back by clicking Rectangle Select again, and the actions undone below it are grayed out. If we now take an alternative branch of actions, say, move the selection instead of erasing it, all the grayed actions will disappear from the list view, and the entire actual list of actions on the stack will turn to i) Open Image, ii) Rectangle Select, and iii) Move Selection.

Do you see my points and do you think you'll be able to implement such an ideal vision of what the point-and-click Undo/Redo stack should be like?
« Last Edit: April 30, 2019, 11:41:24 pm by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1542
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #216 on: April 30, 2019, 11:44:47 pm »
The huge granularity is because of the use of arrow keys, that move one pixel at a time.
But in case of mouse move, we could just consider the mouse down and up event.

The use of "const int" is to follow the current VS recommendation, that is even more enforced on VS 2019 that complaints everytime it encounters a "define".

« Last Edit: April 30, 2019, 11:56:38 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1373
Re: There are many ways to go to Rome.
« Reply #217 on: May 01, 2019, 12:12:08 am »
The huge granularity is because of the use of arrow keys, that move one pixel at a time.
But in case of mouse move, we could just consider the mouse down and up event.
No! No compromises, my friend!!

Keyboard key auto-repeat generates a series of WM_KEYDOWN messages only without matching key-ups until the key is physically released. Technically speaking, there is no difference between handling arrow keys and LMB presses, so the both options should be handled identically.

Quote
The use of "const int" is to follow the current VS recommendation, that is even more enforced on VS 2019 that complaints everytime it encounters a "define".
The current VS recommendation pertains to the current C++ compiler and may very well be sub-optimal for earlier compiler builds. Please #ifdef/#if defined(...) (or similar) your VS2019 bells and whistles for other compilers to generate solid code based on their own code of conduct. Or simply suppress your VS2019 warning code altogether.

const ints are initialized memory objects while #defines are mere PP substitutions that don't eat up process memory at run time.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1542
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #218 on: May 01, 2019, 02:15:30 pm »
To please you, #define has been restored.

There is a new parameter gT.UpDown (IsUp/IsDown) that is used to reduce the stack granularity.

Note: Using the button "Save tex UV", clears the stack history.
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1373
Re: There are many ways to go to Rome.
« Reply #219 on: May 01, 2019, 07:16:30 pm »
Thanks, this one seems better, granularity-wise. Not perfect though:

1. When I first home on a hot spot with the cross and press the LMB to drag the red bullet, I can't do it: it won't move. I have to first release the LMB and then press it again to start dragging. These two events go on the UR stack as two separate actions, so that when I unwind the stack to its beginning, the very last action (immediately before the Undo button goes gray) doesn't move the bullet anywhere as it's already at its origin where dragging started. This "empty" LMB down/up may however be somehow (although with a considerable stretch) classified as a distinct "hot-spot selection" event, and as such may have a (weak) reason to live.

2. But the above "empty" LMB down/up also occurs any time I release the LMB and then press it again to resume dragging to a new location. When unwound by one action, the stack brings me to the previous location, then yet one more action unwound, the bullet just stays where it is, and then unwound for the third time, the stack moves finally to the yet farther previous location.

This glitch is unjustifiable because the hot spot (and bullet position) was already selected and hasn't yet changed. Which means the stack is still almost double-oversized against what it should be.

3. This unwanted phenomenon doesn't occur when dragging the bullet by arrow key auto-repeat, and that in fact is good.

Note: the stack still isn't brancheable and stores the entire sequence of actions not partially cleared regardless of my unwinding it to some previous state and taking a different route for dragging the bullet from that midpoint. Thus, when I start to Redo the actions again, I'm still brought to all the locations I used to visit despite my having taken an alternative midway action that should've cancelled the locations visited after that midpoint had been visited for the first time.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1542
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #220 on: May 02, 2019, 11:07:13 am »
Quote
Also, please acknowledge that you understand fully my stack branching/clearing concerns that I'm trying to describe to you in my numerous notes to my recent messages.
Yes, i understood them perfectly well, i just have to figure the best way to do it.
Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1542
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #221 on: May 02, 2019, 06:58:28 pm »
ID_DOT drag, is now performed asap during WM_LBUTTONDOWN rather than WM_MOUSEMOVE, to bypass the default GDImage click and drag processing.

Undo/Redo action has been revisited to avoid storing twice the same coordinates
        // Save for UnDo/ReDo action
        if (MoveDOT) {
            if (gT.UpDown) {
                if ((lastX != x) || (lastY != y)) {
                    nItem = UBOUND(g_UR);
                    g_UR.resize(nItem + 1);
                    g_UR[nItem].idx = idx;
                    g_UR[nItem].index = gT.wasIndex;
                    g_UR[nItem].wasX = gT.wasX;
                    g_UR[nItem].wasY = gT.wasY;
                    g_UR[nItem].rx = gtm_vertexBuffer[idx].texCoord[0];
                    g_UR[nItem].ry = gtm_vertexBuffer[idx].texCoord[1];
                    if (!IsWindowEnabled(GetDlgItem(gT.hPanel, TOR_UNDO))) { EnableUndo(TRUE); }
                    gT.UpDown = 0;
                    lastX = x; lastY = y;
                }
            }
        }


Quote
stack branching/clearing
Has not been done yet !
« Last Edit: May 02, 2019, 08:39:26 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1542
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #222 on: May 02, 2019, 09:31:32 pm »
Quote
ID_DOT drag, is now performed asap during WM_LBUTTONDOWN rather than WM_MOUSEMOVE
This is causing extra redraw problems, if holding the mouse down for too long, i shall have to find another solution…
« Last Edit: May 02, 2019, 09:33:48 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1373
Re: There are many ways to go to Rome.
« Reply #223 on: May 02, 2019, 09:46:42 pm »
Yes Patrice, I've also noticed it. Looks like some window freezing problem... ???

But as far as the stack is concerned, this implementation seems to be better than the previous one. Yet we can only be 100% sure of it when (if?) we see what (and how many) events really go onto a Paint.NET-like visual representation of stack...
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1542
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #224 on: May 03, 2019, 01:46:21 pm »
With this version, i hope i have twisted the neck of the beast, without side effect.

Do a WinMerge to see what has been changed to avoid the conflict between scrolling the background with the mouse (now disabled), and dragging the hot spot.

The main problem is that WM_MOUSEMOVE is a high priority message, while redrawing the map in CreateUVmap is a rather lengthy process compared to the mouse movement.

Search for "stack clear/release", for the new Undo/Redo erase action.
However i am unsure of the indices being used.
« Last Edit: May 03, 2019, 05:35:37 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)