Revision: 31158
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=31158
Author: merwin
Date: 2010-08-08 07:13:29 +0200 (Sun, 08 Aug 2010)
Log Message:
-----------
Earlier Windows notes.
Added Paths:
-----------
branches/soc-2010-merwin/notes/week 10 notes.txt
branches/soc-2010-merwin/notes/week 9 notes.txt
Added: branches/soc-2010-merwin/notes/week 10 notes.txt
===================================================================
--- branches/soc-2010-merwin/notes/week 10 notes.txt
(rev 0)
+++ branches/soc-2010-merwin/notes/week 10 notes.txt 2010-08-08 05:13:29 UTC
(rev 31158)
@@ -0,0 +1,19 @@
+26 July --
+
+General optimizations.
+
+Remove 'virtual' functions from childless classes. Not sure if this would
reduce the vtable or speed things up, or change anything, but it's worth a
shot. One standalone class (no parents or children) even had virtual members.
Weird. Oh well, nothing in here is as bad as MoTo! For example...
+
+GEN_INLINE MT_Vector3 MT_Vector3::random() {
+ MT_Scalar z = MT_Scalar(2.0) * MT_random() - MT_Scalar(1.0);
+ MT_Scalar r = sqrt(MT_Scalar(1.0) - z * z);
+ MT_Scalar t = MT_2_PI * MT_random();
+ return MT_Vector3(r * cos(t), r * sin(t), z);
+}
+
+Why bother inlining with all that slow math code? Not to mention the
directional bias. Oh wait, I just mentioned it.
+
+Also, use single-precision floats by default. Dreamworks didn't switch to
doubles until Bee Movie, and we're not even to Madagascar yet! Small difference
on x87 or PowerPC GPRs, but a very big difference for SSE and AltiVec! SSE is
largely automated by the compiler, but strongly wants to deal with 32-bit
floats. One more word: memory.
+
+
+Hmm. After updating my Windows source (after recent merge), there's a
mysterious link error. It's getting late, so I'll run a clean build tomorrow.
\ No newline at end of file
Added: branches/soc-2010-merwin/notes/week 9 notes.txt
===================================================================
--- branches/soc-2010-merwin/notes/week 9 notes.txt
(rev 0)
+++ branches/soc-2010-merwin/notes/week 9 notes.txt 2010-08-08 05:13:29 UTC
(rev 31158)
@@ -0,0 +1,180 @@
+24 July --
+
+Had to edit the SConscript for the first time, for GHOST. Learning all kinds
of new things this summer! It was trying to compile the Mac NDOF manager on
Windows, so I had to hunt down the problem. It was assuming all Mac code was of
the form *.mm or *Carbon.cpp, which it was before I started throwing wrenches
around. GHOST_NDOFManagerCocoa.cpp doesn't fit that mold. Technically it's not
Cocoa, but it seemed to fit the naming convention. Discarded the older Carbon
code, and removed reference to it in the SConscript. I'm sure it's still useful
as a reference (and a stepping stone to blending on Mac OS 8.6!), but it's
otherwise obsolete.
+
+New naming conventions inside GHOST?
+
+Foo
+FooWin
+FooMac
+FooX
+
+And of course IFoo, even though I don't care for using inheritance to define
interfaces. Or the practice of naming things with an 'i' up front. It will
never be retro if we don't stop doing it!
+
+I'm sure there's a way to limit the '-weak_import 3DconnexionClient' to GHOST
only. But how?
+
+One quick gripe before I move on.. Why doesn't file.c++ have better support?
It looks totally cooler than file.cpp. Ok, done.
+
+I was hesitant to add the Mac SpaceNav driver as a build dependency, but think
about all the crap you need to download to build blender on Linux. One driver
(in addition to the libs in svn) is not that big a deal.
+
+Alright, reading up on scons... Neat stuff, but I'll continue down this road
when I'm back on the Mac. Windows awaits! It looks like I can append a short
list to LINKFLAGS to get the desired behavior. Scons doesn't seem to notice
that I changed the build script for GHOST. Hmm. Starting a clean build now.
+
+SpaceNav capture for Windows --
+
+Does it work? We shall see, after it builds. 1:41am. Ok, I'm tired of
struggling with the build script. Just name it GHOST_NDOFManagerCocoa.mm (even
though it's not) to get a clean Windows build. Do it properly later. You mean
I'm doing a clean build for *nothing*!? You can do it, Pentium4!
+
+By the way, I am not looking forward to the next merge. Some stuff has changed
in my branch, but LOTS of things have changed in trunk. Some other gsoc'ers
have noted difficulty with recent merges, and mine has been 'off trunk' for too
long.
+
+Ah, Chapter 16, Hierarchical Builds. (btw, my Intuos4 is in Dallas, on its way
to the 'burg!)
+
+Good news, everybody: SpaceNav works on Windows, without a plugin or even a
driver! Some duplicate input is getting through, so I'm about to simplify the
two-stage WM_INPUT handler and see if that helps. Removing code:
+
+/*
+ UINT dwSize;
+ GetRawInputData((HRAWINPUT)lParam, RID_INPUT, NULL, &dwSize,
sizeof(RAWINPUTHEADER));
+ LPBYTE lpb = new BYTE[dwSize];
+ GetRawInputData((HRAWINPUT)lParam, RID_INPUT, lpb, &dwSize,
sizeof(RAWINPUTHEADER));
+ RAWINPUT* raw = (RAWINPUT*)lpb;
+*/
+
+ RAWINPUT raw;
+ RAWINPUT* raw_ptr = &raw;
+ UINT rawSize = sizeof(RAWINPUT);
+// UINT bufferSize = rawSize;
+
+ puts("processing first event:");
+ // I don't know if this is needed. Can we get by with just
GetRawInputBuffer?
+ // Thought some mouse events were missing, so I put this in to be
cautious.
+ // Test and remove if redundant. [mce]
+ GetRawInputData((HRAWINPUT)lParam, RID_INPUT, raw_ptr, &rawSize,
sizeof(RAWINPUTHEADER));
+ eventSent |= processRawInput(raw, window /*, mousePosX, mousePosY*/ );
+ DefRawInputProc(&raw_ptr, 1, sizeof(RAWINPUTHEADER));
+
+// GetRawInputBuffer(NULL, &bufferSize, sizeof(RAWINPUTHEADER));
+// UINT n = bufferSize / rawSize;
+// printf("allocating %d bytes (room for %d events)\n", bufferSize, n);
+
+...
+
+#if 0 // this is part of the 'old' NDOF system; new one coming soon!
+ case WM_BLND_NDOF_AXIS:
+ {
+ GHOST_TEventNDOFData ndofdata;
+ m_ndofManager->GHOST_NDOFGetDatas(ndofdata);
+ m_eventManager->
+ pushEvent(new GHOST_EventNDOF(
+ getMilliSeconds(),
+ GHOST_kEventNDOFMotion,
+ window, ndofdata));
+ }
+ break;
+ case WM_BLND_NDOF_BTN:
+ {
+ GHOST_TEventNDOFData ndofdata;
+ m_ndofManager->GHOST_NDOFGetDatas(ndofdata);
+ m_eventManager->
+ pushEvent(new GHOST_EventNDOF(
+ getMilliSeconds(),
+ GHOST_kEventNDOFButton,
+ window, ndofdata));
+ }
+ break;
+#endif // old NDOF
+
+
+And from processRawInput:
+
+#if 0 // now using the existing mouse button handlers, improved movement
handler
+if (raw.header.dwType == RIM_TYPEMOUSE)
+ {
+ USHORT const& buttonFlags = raw.data.mouse.usButtonFlags;
+ if (buttonFlags)
+ {
+ printf("button flags: %04X\n", buttonFlags);
+
+ if (buttonFlags & RI_MOUSE_LEFT_BUTTON_DOWN)
+ {
+ puts("left button down");
+ window->registerMouseClickEvent(true);
+ event = processButtonEvent(GHOST_kEventButtonDown,
window, GHOST_kButtonMaskLeft);
+ }
+ else if (buttonFlags & RI_MOUSE_LEFT_BUTTON_UP)
+ {
+ puts("left button up");
+ window->registerMouseClickEvent(false);
+ event = processButtonEvent(GHOST_kEventButtonUp,
window, GHOST_kButtonMaskLeft);
+ }
+
+ if (buttonFlags & RI_MOUSE_RIGHT_BUTTON_DOWN)
+ {
+ puts("right button down");
+ window->registerMouseClickEvent(true);
+ event = processButtonEvent(GHOST_kEventButtonDown,
window, GHOST_kButtonMaskRight);
+ }
+ else if (buttonFlags & RI_MOUSE_RIGHT_BUTTON_UP)
+ {
+ puts("right button up");
+ window->registerMouseClickEvent(false);
+ event = processButtonEvent(GHOST_kEventButtonUp,
window, GHOST_kButtonMaskRight);
+ }
+
+ if (buttonFlags & RI_MOUSE_MIDDLE_BUTTON_DOWN)
+ {
+ puts("middle button down");
+ window->registerMouseClickEvent(true);
+ event = processButtonEvent(GHOST_kEventButtonDown,
window, GHOST_kButtonMaskMiddle);
+ }
+ else if (buttonFlags & RI_MOUSE_MIDDLE_BUTTON_UP)
+ {
+ puts("middle button up");
+ window->registerMouseClickEvent(false);
+ event = processButtonEvent(GHOST_kEventButtonUp,
window, GHOST_kButtonMaskMiddle);
+ }
+
+ // similar for BUTTON_4 and BUTTON_5
+
+ if (buttonFlags & RI_MOUSE_WHEEL)
+ {
+ signed short wheelDelta = raw.data.mouse.usButtonData;
+ printf("wheel moved %+d\n", wheelDelta);
+ }
+ }
+
+ int dx = raw.data.mouse.lLastX; // These might be in Mickeys, not
pixels.
+ int dy = raw.data.mouse.lLastY;
+ if (dx || dy)
+ {
+ printf("mouse moved <%+d,%+d>\n", dx, dy);
+ x += dx;
+ x += dy;
+ event = processCursorEvent(GHOST_kEventCursorMove, window, x,
y);
+ }
+ }
+#endif // unused experimental mouse code
+
+...
+
+ // assume only one event will come from this RawInput report
+ // test and adjust assumptions as needed!
+
+ if (event)
+ {
+ pushEvent(event);
+ event = NULL;
+ eventSent = true;
+ }
+
+ return eventSent;
+
+
+Ah, it feels good to get that outta there. Nice streamlined event-processing
code. While I'm in here, there's still something unfinished in the Windows
hi-fi mouse code: GetMouseMovePointsEx provides the last 64 mouse cursor
positions for the whole system, not just our window. I still haven't looked
into a way to filter out foreign mouse events. Dropped a TODO into the relevant
code.
+
+/*
+ // standard HID mouse
+ devices[0].usUsagePage = 0x01;
+ devices[0].usUsage = 0x02;
+ devices[0].dwFlags = 0; // RIDEV_NOLEGACY; // ignore legacy mouse
messages
+ devices[0].hwndTarget = NULL;
+*/
+
+SystemWin32 cleans up pretty nice!
\ No newline at end of file
_______________________________________________
Bf-blender-cvs mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
