Ebook?

I just got a book ordered on amazon, algorithmic trading and DMA. It showed up today, Sept. 28th, 2010.

It was printed Sept. 20th, 2010.

Ebook?

Rack Attack A+ Customer Service

So, I had a bad thing happen with my new Bianchi Infinito Carbon Fiber road bike. We theorize it was somehow related to the fork mounted Yakima roof rack I was using. I was bummed because the rack is only 5 months old and the bike about 2 months. However, upon describing the situation (carbon fiber fork cracking) to the store I bought it, they basically said 'bring them in and we'll swap them out, no charge. We want you to be happy.' and with that they swapped out my bike racks for a new set that don't come in contact with the fork.

I thought this was amazing customer service and deserved a few kind words. Highly recommended.

I'll keep you posted on how Bianchi does at replacing my fork, along with the folks at Lakeside Bicycles in Lake Oswego.

Visual Adrenaline Interview on Game Programming Gems 8

Was recently interviewed at for Intel's Visual Adrenaline regarding Game Programming Gems 8.

The video is 20 minutes long.

D3D .dlls, and system32 vs. syswow64

This is nerdy, but i bet i'm not the only one who thinks this is going to be useful to dig up later. if you have questions, post them and i'll try to answer. time constraints limit me from cleaning this up right now. (TODO: cleanup post).


windows\system32 vs. windows\syswow64

WOW = windows on windows. on 64 bit systems, 32 bit .dlls go into the syswow64 directory. its for emulation of 32bit functionality on a 64 bit system and includes some other windows glue to make this happen, like on a 64 bit x86 microprocessor it switches it between 32 bit and 64 bit mode when needed.


for d3d11ref.dll: if you are running an x86 (32 bit) binary, it will look in the syswow46 directory for the 32 bit .dll. if its not there, IT DOES NOT LOAD
THE ONE IN system32. this was verified by actually moving the working 32 bit d3d11ref.dll into system32, watching the .dlls that were loaded into the application in visual studio, it did not grab the .dll when it was moved. a 32 bit system will load from syswow64. if its not there it does not look for a 32 bit version in system32.

when running a 64 bit build of the same binary, the d3d11ref.dll was loaded in from sys32, and it would not load the one in from syswow64 even if it didn't have one in sys32.

syswow64 is part of the search path for 32bit systems, system32 is part of the search path for dlls for 64 bit systems. you will not pull in a same named file, even the right d3d11ref.dll binary from the wrong directory. this can be verified by watching the load modules window in visual studio as your application starts up.

the naming convention (system32 vs. syswow64) is done for compatibility reasons, and my specifics are related to figuring out search paths for d3d .dlls. did not verify this was a general rule of thumb for all .dlls.

No blogs in 2009?

I've been quiet for all of 2009. Why? Well, mostly I used the time that may have normally been used for blogging on serving as Editor for Game Programming Gems 8. After a full year, we're in the final stages now of getting proofs back from layout and on track for a publication in Q2 of 2010. This was incredibly rewarding and time consuming, so I had to make decisions and the blogging was something that just had to get dropped. Indeed, lots happened in the past year, and 2010 looks to be just as interesting.

Cheers,

--adam