Early WIP on v2.55

[Michael Lobko-Lobanovsky]

I shall check my code to see what could cause the limitation.

Thank you!

[Patrice Terrier]

SYNC,

Please use the attached constants.h

[Michael Lobko-Lobanovsky]

Done!

[Patrice Terrier]

Mike,

I you don't mind, there are a few other things i would like you to SYNC with me as soon as i have complete myself my sync with you.

Added
Here is my sync.zip attachment

[Michael Lobko-Lobanovsky]

1. Main.cpp:

            skSetAnchorCtrl(hCtrl, ANCHOR_RIGHT); skCreateToolTip(hCtrl, TipFormat(L"  Animate  "));

            hCtrl = GetDlgItem(gP.hMain, IDC_DEMO_MODE);
            skSetAnchorCtrl(hCtrl, ANCHOR_RIGHT); skCreateToolTip(hCtrl, TipFormat(L"  Demo mode  "));

            hCtrl = GetDlgItem(gP.hMain, IDC_BRIGHT_CONTROL);
            skSetAnchorCtrl(hCtrl, ANCHOR_RIGHT); skCreateToolTip(hCtrl, TipFormat(L"  Stray light intensity  "));

TipFormat() uses a static WCHAR buffer. It stays filled with "Stray light intensity" when it is already required to display "Background" in the info tips. I was (and still am) too lazy to reinitialize it with "Background" here again.

2. Why did you remove the void gl_DrawScene(); forward declaration from Splitter.h? Your compiler has suddenly started to accept this frivolity?


I have sync'ed all the rest with your code. Thanks!

[Patrice Terrier]

Why did you remove the void gl_DrawScene(); forward declaration from Splitter.h?

Because we need it elsewhere, see in Mobj.h line 1112.

About the menu, this is due to the font change i did one month ago, there is some kind of clipping, but from a quick test all the menu items are there.

[Michael Lobko-Lobanovsky]

Why did you remove the void gl_DrawScene(); forward declaration from Splitter.h?

Because we need it elsewhere, see in Mobj.h line 1112.

My friend,

I do not understand what you're talking about. If I remove the void gl_DrawScene(); forward declaration from line 44 in Splitter.h, my project won't compile. This has nothing to do with line 1112 in mobj.h which also needs its own declaration because the function appears in Main.cpp, i.e. well below all the include files it is used in...

Try to rebuild (rather than just build) the solution to see if your project would compile without that declaration in Splitter.h.

[Patrice Terrier]

... from a quick test all the menu items are there

.
I mean all  the name are there when using zTrace, it is just that the last one doesn't display at the right place, but on the line below.

To see what i mean, just put the focus on a menu, then use the left or right arrow to move the popup and see how "Help" is being shown (Under the first item).

I keep trying to understand why Windows doesn't return me the correct location for that one in the ownerdrawn menu section when using
DRAWITEMSTRUCT* lpdis = (DRAWITEMSTRUCT*) lParam;
at the line 2970 of skDrawmenu (in WinLIFT.cpp).

If I remove the void gl_DrawScene(); forward declaration from line 44 in Splitter.h, my project won't compile.

Obviously we don't use the same Splitter.h code, could you send me yours for comparison purpose.
I made several changes in mine to fix the different misalignments we spoke about.
(Note: i am always using "Rebuild solution")

[Michael Lobko-Lobanovsky]

... use the left or right arrow to move the popup and see how "Help" is being shown (Under the first item).

     

Obviously we don't use the same Splitter.h code ...

I'm using exactly what you've been sending to me as the splitter mods and for sync'ing...

[Patrice Terrier]

I never put void gl_DrawScene(); in the case WM_NCLBUTTONDBLCLK: case section, because i was not aware that this C++ syntax could be used like this inside of a case message cracker. 

You learned me something new about the C++ syntax , thank you! 

[Michael Lobko-Lobanovsky]

I'm glad you liked it!

Yeah, you can put a declaration anywhere you want, but if you put it inside a scope (in between curly braces as inside an if-clause), it just isn't going to be visible anywhere else.

[Michael Lobko-Lobanovsky]

Thanks for the library, it solves the problem even if temporarily! Hopefully it'll also allow us to add yet more main menu elements as might be necessary in the future.

Regarding the new rendering modes,

1. Vertex normals (and even more so, face normals which I haven't yet implemented due to the lack of spare controls on the tool window) help isolate faces that have wrong (flipped) normals. They may be difficult to spot in complex meshes with hundreds of thousands of polies but in simple and symmetrical meshes, the irregularities are easily spotted at a glance.

2. Customized skinned color dialogs would be nice but only if their color selectors are large enough, substantially bigger in size than your usual rainbow strip.

3. Sometimes it is difficult to tell by the looks of normal map alone if it has correct normal Y orientation (the green channel). It should be +Y (upwards) for OpenGL and -Y (downwards) for DirectX. But it becomes immediately prominent when you inspect the white material surface void of the model's diffuse maps. That's the purpose of the new material surface mode.

4. Last but not least, I've put our billboards to useful service. Now they visualize our rotating lights instead of the colored spheres. I hope you noticed the new corona.png texture map in the zip. You're supposed to put it into the \x64\Release\Reader folder alongside the skin and other system maps.

[Patrice Terrier]

I've put our billboards to useful service

I have just checked the new corona billboard, and it looks better than the previous sphere, good work.

Thank you!

[Michael Lobko-Lobanovsky]

I made a copy-paste typo in the ToolProc() function, line 219, ToolWindow.h:

........
        case IDT_CHECK02:
            if (HIWORD(wParam) == BN_CLICKED) {
                if (gP.bTexVertNorms) {
                    gP.bShowNorms[1] = (BOOL)SendMessage(GetDlgItem(gP.hTool, IDT_CHECK02), BM_GETCHECK, 0, 0);
                } else if (gP.bAnimateLights) {
                    gP.bRotateLight[2] = (BOOL)SendMessage(GetDlgItem(gP.hTool, IDT_CHECK02), BM_GETCHECK, 0, 0);
                }
                gP.redraw = -1; // request redraw
            }
            break;

        case IDT_CHECK03:
            if (HIWORD(wParam) == BN_CLICKED) {
                if (gP.bTexVertNorms) {
                    gP.bShowNorms[2] = (BOOL)SendMessage(GetDlgItem(gP.hTool, IDT_CHECK03), BM_GETCHECK, 0, 0);
                } else if (gP.bAnimateLights) {
                    gP.bRotateLight[3] = (BOOL)SendMessage(GetDlgItem(gP.hTool, IDT_CHECK03), BM_GETCHECK, 0, 0);
                }
                gP.redraw = -1; // request redraw
            }
            break;
        }
        break;
........

Please correct it.

[Patrice Terrier]

I found the cause of the menu problem:
That was a wrong size computation of the menu container, because the use of GetTextExtentPoint32 is not reliable with the new font i am using for menu.

The new pandora with the new DLL is attached to this post.