[DIY] homemade NVIDIA 3dVision interface code

[cms]

I've written some code to interface directly with NVIDIA's 3dVision IR emitter.

I wanted to be able to work with OpenGL while utilizing the glasses.

I'm still unsure of the meaning behind some of the data that is passed to the emitter. It all seems to be tied to the refresh rate, and I've been able to find some equations to map it out, but I dont understand it. If anyone figures anything out please let me know.

Also, I only have two monitors that support higher refresh rates, and only up to 100hz. So I wasn't able to test anything higher than this.

How it works:

There are two rendering contexts (in separate threads). The offscreen thread is not bound by vsync and continually renders the scene to a set of frame buffer objects (one for each eye). The visible context is bound by vsync and has access to these fbos. It renders the appropriate eye fbo to the window and toggles the 3dVision's "eye."

A file named "validRefreshRates.ini" holds a refresh rate per line. The program will initially use the top refresh rate. (You may want to change this)

Keys:

F1 - toggles stereo
F2 - swaps eyes
F3 - goes to the next refresh rate (or loops to the first)

F5/Shift-F5 - modifies the convergence
F6/Shift-F6 - modifies the separation

It uses glew, sfml, and winddk and is released under the boost license (so hack away!).

NOTE: use at your own risk. It works fine for me, and I suspect it will for you too, but because this is interfacing with the hardware there is a potential for damage.

Let me know if anyone finds this useful or has any questions!

Edit: oops, I accidentally hardcoded something in that old zip. Fixed.

-cms

[Okta]

I have no idea what this does and dont own the Nvision but i like the sound of your reverse engineering. Good work mate

[elroel]

Hi cms,

Thank you for sharing this. But I couldn't compile it I would appreciate if you can give me an executable for win xp (if you have time). I am trying to make this IR emitter switch on in OpenGL apps.

Thanks in advance

elroel

[gzhang207]

Can I get a copy of your code?

Thanks

Gary

[mickeyjaw]

Can I get a copy of your code?

Thanks

Gary

Er... it's already attached to his post - you don't have to ask

[crim3]

Thanks for sharing, cms, you are a genious.

[Allilya]

Formulas rate*rate*rate seems wrong.
mb b=~150000/rate (IR transmitter has clock generator? a b c )
a=4*b
c=8*b

a,c - timing for LR, b - ... close state time?

a,b,c in drivers? nvstusb.inf ?

[bennibo]

I'm having trouble getting this to compile as well... I'm not exactly a software developer, so I'm not really proficient at this.

Would anyone mind kindly posting a binary of this? I've been looking around for a while for this kind of solution. I'm on Windows 7 x64, if it makes a difference at all.

[bwheaton]

Thanks for providing this. I'm trying to get 3D vision going with Quadro on Linux, and it's pretty scary. The 'driver' looks at the monitor EDID and checks against an internal database, so it doesn't enable the card and emitter a lot of times. This is a big grind for us - we can get the Quadro to send a sync signal, but the IR emitter won't enable.

Where did you get the codes? Snooped them? Did you get a chance to write up what you think they mean?

I also need to move this to Linux, and maybe Mac, so I may have a couple of questions as I try to interpret the windows USB stuff.

Regards,

Bruce Wheaton

[mickeyjaw]

bwheaton:

Hey if you can get this ported to linux that would be amazing, as there are projects ongoing for 3d picture and movie players on Linux e.g http://www.mtbs3d.com/phpBB/viewtopic.php?f=21&t=5723&. At the moment we are only supporting Interlaced and anaglyph output. Do you have any idea how you intend to implement this i.e will you make it a kernel module and device node, or do you intend to do everything from userspace using libusb or similar?

Finally, there is also code for outputting DDC signals for older VGA pass-thru dongles available too, if you cannot get the NVIDIA dongle to work you could plug the IR emitter into one of these instead (provided you are using an analog display).

http://www.mtbs3d.com/phpBB/viewtopic.php?f=16&t=7691 <-- DDC code for >=8 series Nvidia

http://netjuggler.sourceforge.net/SoftGenLock.php <-- old, unmaintained code, but contains code for DDC on older NVIDIA cards.

[magestik]

+1 Mickeyjaw
But, I think it's not difficult to make a little thing in python using somes usb library. The problem is that I don't have the Nvidia Kit .. too expensive for me ^^
If I can buy one, I think I'll try some reverse engineering and make it

[celblazer]

Anyone able to get this to compile?

[drowhunter]

I got it to compile, heres what i did

i am using vs2008

1) Download activator.zip from post at beginning
2) Download SFML development files (headers / libraries / external libraries) http://www.sfml-dev.org/download.php
3) Follow the tutorial here to set up sfml properly http://www.sfml-dev.org/tutorials/1.6/start-vc.php
4) Download glew 32-bit from here http://glew.sourceforge.net/ and extract it somewhere e.g(C:\glew-1.5.3)
5) In vs2008/Tools/Options/Projects and Solutions/VC++ directories under include files drop down, add path to glew include folder (c:\glew-1.5.3\include)
6) under library files drop down, add path tp glew lib folder files (c:\glew-1.5.3\lib)
7) Download wxp ddk version (3790.1830) from hehe http://www.torrentz.com/0550bbd127aec58 ... 2c3310e40c
note the new w7 version doesnt compile
8) install it and add the include and lib paths similar to step 5 and 6
mine were located here
include files --> c:\wdk\3790.1830\inc\wxp
lib files --> c:\wdk\3790.1830\lib\wxp\i386

9) before you canbuild activator you will need to build glew

10) where ever you extracted glew look for the vc6 folder (in my case c:\glew-1.5.3\build\vc6)

11) open the project in vs2008 and build it
12) now open the activator sln and build it hopefully it will build
check the debug or release folder for activator.exe
13 in order for it to run copy all of the dlls from the sfml package to same folder as activator.exe as well as glew32.dll from glew package(assuming you built it in step 10)

also copy the validRefreshRates.ini file alongside activator.exe or it wont work

**im not sure if this is neccessary but i also had the dxsdk jun08 and had included the directories for it as in step 5 and 6

[drowhunter]

I have a question for cms

is it possible to strip/modify your code so that it simply enables the emitter, to recieve the sync signal from my dlp and blink the ir leds for the 3d vision glasses

i would like the option of using my glasses with any 3d source for example ps3 avatar, or using iz3d drivers

[Shymere]

Hi cms, do you think it could work for my problem :

http://www.mtbs3d.com/phpBB/viewtopic.php?f=26&t=10023

If yes, could you send me the compiled files, would be great. I tried to compile it following the tutorial of drowhunter, but may be because of my newbiness, I did not get it....

Thanks

[Slah]

Could you please post the compiled tool?

[kolrabi]

Hi, I'm new to this forum, but I thought I might share this.

I have hacked together a small linux library for the NVIDIA 3d stereo controller using the libusb library to access the device. As libusb is also available for Windows, I assume it might work as well for OpenGL under Windows (if it compiles). You will need the nvstusb.sys from the Windows installation (currently only 190.62 is supported, I'll fix that). If you want to give it a try, you can find it on my blog: http://codesklave.de/2010/04/26#nvstusb. Use at own risk!

I might also have an explanation for the timer values that are sent, when setting up the device, as well as any time the eyes are toggled. By looking at the data it seems the upper word is always 0xFFFF, and the lower word is the cycle count of a 23.592 MHz or 23.592960 MHz clock. I came to that conclusion after noticing that at 120Hz refresh rate they the four timer values from the setup code and the eye toggle command always seemed to add up to around 0x30000. It might actually be 0x2FFF8 because that would mean a 23.592 MHz clock for which there are crystals that are cheaper than the 23.592960 MHz ones. I don't know yet, which timer value does what, but I suspect they correlate to the durations of on/off states.

I also had a look at the firmware and it seems to me like there is a 80c51/80c32 microcontroller in the device. I'll have a closer look at that to confirm my findings.

All in all a very hackable device, in my opinion.

[bwheaton]

bwheaton:

Hey if you can get this ported to linux that would be amazing, as there are projects ongoing for 3d picture and movie players on Linux e.g http://www.mtbs3d.com/phpBB/viewtopic.php?f=21&t=5723&. At the moment we are only supporting Interlaced and anaglyph output. Do you have any idea how you intend to implement this i.e will you make it a kernel module and device node, or do you intend to do everything from userspace using libusb or similar?

Thanks for the links - I had just found some of them a minute before. Great work going on!

I was thinking of something like libUSB, since installs should be easier, and hopefully I can use the same code for Mac too.

Let me dig around a bit, and I'll report back. Be helpful if anyone using the windows version that gets a better idea of what the parameters do would let us know. I'm also interested in whether the emitter will run it's own clock, instead of getting explicit swap commands.

Bruce

[bwheaton]

Oh, nice job kolrabi. I was just starting to hack around in libusb. I guess, without the firmware, I wouldn't have got too far anyway. Is it one of those devices that needs to get his whole firmware every boot?

Can I double-check some things with you? When I queried the device, I came up with no endpoints. Just a mistake here?

Then there's a lot of stuff about rate, and yet switching seems to be manual. What do you think about that?

Also, when you look at timing, some of what you're seeing that's odd may be related to dark periods - blanking when neither eye is on. It's also possible that they have built in a delay from when you trigger the swap to when it starts - there's a definitely a delay somewhere to correct for all different sorts of monitor, and it may be in the box, driver or back in the OpenGL driver. Not sure.

Anyway, would you mind sharing any snooped information also? I ran into a block trying to convert the windows Activator version when it starts using an array of ints instead of bytes, and working out which bytes to swap.

Bruce

[asdfqwer]

Compiled version of the activator:
http://www.mediafire.com/?jqw3ncxktmo" onclick="window.open(this.href);return false;

[kolrabi]

Oh, nice job kolrabi. I was just starting to hack around in libusb. I guess, without the firmware, I wouldn't have got too far anyway. Is it one of those devices that needs to get his whole firmware every boot?

Yes. The windows driver uploads it at boot time if it is connected. If it's connected later the firmware is uploaded when 3d mode is being entered.

Can I double-check some things with you? When I queried the device, I came up with no endpoints. Just a mistake here?

The endpoints become available as soon as the firmware is loaded.

Then there's a lot of stuff about rate, and yet switching seems to be manual. What do you think about that?

I think this is to prevent the device and the monitor to get out of sync due to clock drift. Clock rates may change over time.

Also, when you look at timing, some of what you're seeing that's odd may be related to dark periods - blanking when neither eye is on. It's also possible that they have built in a delay from when you trigger the swap to when it starts - there's a definitely a delay somewhere to correct for all different sorts of monitor, and it may be in the box, driver or back in the OpenGL driver. Not sure.

When switching eyes something that looks like a timer value is transmitted in addition to the selection of the active eye. I didn't implement it in my code because I'm not yet sure how to calculate that value correctly. I suspect it's related to the time that the device should wait before changing the eye.

Anyway, would you mind sharing any snooped information also? I ran into a block trying to convert the windows Activator version when it starts using an array of ints instead of bytes, and working out which bytes to swap.

I used SnoopyPro and you should be able to use it to open this file: http://codesklave.de/files/usblog.zip

[bwheaton]

When switching eyes something that looks like a timer value is transmitted in addition to the selection of the active eye. I didn't implement it in my code because I'm not yet sure how to calculate that value correctly. I suspect it's related to the time that the device should wait before changing the eye.

That makes sense. They need a specific time to trigger the swap, and I suspect the best time would actually be at the vertical interval, but to trigger the next swap, if that makes sense. So if they're about to issue the GL commands to draw left, they would trigger left, even though it's going to be displayed at the next swap. Then they would/do also build in some sort of delay for the latency of display devices.

I suppose, if you assume there's always some latency, you could trigger at the VBI and the glasses would swap 'in time' for the actual video to start arriving. Hmm. My point really is that finding accurate times in between vertical intervals is tricky. I think in your version, you tell the glasses to swap when you issue the swap command. You probably know that it won't actually swap right then, you're just queuing the command, right? That's especially true when v-sync is enabled, which it pretty much has to be for 3D.

In glut (which is the best way to code this example, for sure - it's actually cross-platform), I'm not sure you really get any kind of accurate, frame referenced timer - just a render timer.

Thanks for the snoop, I'll check it out.

Bruce

[bwheaton]

Oh, and Kolrabi - did you try putting a Vesa sync signal into the emitter? That's the way it's meant to work with Quadro.

Bruce

[Slah]

Compiled version of the activator:
http://www.mediafire.com/?jqw3ncxktmo" onclick="window.open(this.href);return false;

Can't run it =/

[kolrabi]

That makes sense. They need a specific time to trigger the swap, and I suspect the best time would actually be at the vertical interval, but to trigger the next swap, if that makes sense. So if they're about to issue the GL commands to draw left, they would trigger left, even though it's going to be displayed at the next swap. Then they would/do also build in some sort of delay for the latency of display devices.

That's easy for NVIDIA to do, as they also developed the video driver. They know exactly what to do when and how.

I suppose, if you assume there's always some latency, you could trigger at the VBI and the glasses would swap 'in time' for the actual video to start arriving. Hmm. My point really is that finding accurate times in between vertical intervals is tricky. I think in your version, you tell the glasses to swap when you issue the swap command. You probably know that it won't actually swap right then, you're just queuing the command, right? That's especially true when v-sync is enabled, which it pretty much has to be for 3D.

Yes you're right, I didn't think of that. Unfortunately there is no OpenGL command to explicitly wait for the v-sync. But there should be a way to do it. Maybe one could use glFinish() after issuing the swap to wait for it to happen and then either swap the eyes (assuming the swap itself is quick enough and the monitor is still in vertical blank at that time) or take some time measurements that could be used to swap the eyes in time. Hmm... tricky...

I also have the problem on my machine that the swap doesn't happen exactly a the time of the vertical blank. On the top of the screen I get some flickering where a seemingly random number of lines a swapped too late. But I think that's a configuration issue. (I'd also like to get my 2233rz into the same mode it is in when I use 3d on Windows, so far no luck)

In glut (which is the best way to code this example, for sure - it's actually cross-platform), I'm not sure you really get any kind of accurate, frame referenced timer - just a render timer.

Time measurements would ideally in units of raster position. But that would require access to the video adapter. On Linux one could use read the CLOCK_MONOTONIC clock for a high resolution timer, or QueryPerformanceCounter on Windows. Or write a real driver that can use timer interrupts.

Oh, and Kolrabi - did you try putting a Vesa sync signal into the emitter? That's the way it's meant to work with Quadro.

No, I don't have a Quadro. I also don't know the pinout or voltage levels to create my own signal.

[Fredz]

Time measurements would ideally in units of raster position. But that would require access to the video adapter. On Linux one could use read the CLOCK_MONOTONIC clock for a high resolution timer, or QueryPerformanceCounter on Windows. Or write a real driver that can use timer interrupts.

On Linux there is new a function in the kernel since version 2.6.32 or 2.6.33 which is called KMS page flipping Ioctl. As the name suggests, it should be able to give a user interrupt when a page flip is occuring. I don't know if it's supported by graphic cards drivers for now though.

[andrei123]

Nice find kolrabi !

kolrabi:
I also had a look at the firmware and it seems to me like there is a 80c51/80c32 microcontroller in the device. I'll have a closer look at that to confirm my findings.

Indeed, it seems to me that the the uC is EZ-USB FX2. Checkout the datasheet here:
http://www.keil.com/dd/docs/datashts/cy ... x2_trm.pdf" onclick="window.open(this.href);return false;

I believe the controller is based on this uC because:
- it supports USB firmware uploading directly to RAM (without any eeprom), and it is 8051 based.
- has 8KB RAM for both code and data.
- clock is 24MHz.
- reset and booting sequences match exactly those Kolrabi found.

I will later check out the firmware in more detail. Maybe we can figure out the extract clock info
sent along with the flipping command, and even write our own firmware .

[bwheaton]

Yes you're right, I didn't think of that. Unfortunately there is no OpenGL command to explicitly wait for the v-sync. But there should be a way to do it. Maybe one could use glFinish() after issuing the swap to wait for it to happen and then either swap the eyes (assuming the swap itself is quick enough and the monitor is still in vertical blank at that time) or take some time measurements that could be used to swap the eyes in time. Hmm... tricky...

No, I don't have a Quadro. I also don't know the pinout or voltage levels to create my own signal.

I use this:

Code: Select all

// this is the actual sleep/wait
			glXGetVideoSyncSGI (&retraceCount);
			// Since the retrace is apparently unreliable, get the current count
            glXWaitVideoSyncSGI (2, (retraceCount + 1) % 2, &retraceCount);

All being well, you get a visit at/very close to the vertical blank, which you can use as a reasonable guesstimate, i.e. trigger blanking right away *if* you have control of the pause before it actually blanks.

VESA sync is a super simple signal - +5V square wave at eye frequency.

Bruce

[mmmmmmmm]

Last night, drawing inspiration from Kolrabi's code, and some quality time with a USB sniffer, I got our 3d vision glasses working on a Mac.

Rock solid 120Hz on a recent Viewsonic projector (PDJ6251), very little ghosting, no glitches, HDMI. This Viewsonic has two 120Hz 3d modes — the contrast ratio trashing "DLP-link" mode and a almost transparent "3d vision" mode. But the projector itself has not yet been "whitelisted" by Nvidia's drivers which, for me, was just the last straw.

I'll try to write this up properly soon, but some key facts for likeminded hackers:

1) I know hardly anything about the current state of OpenGL on Linux, but I suspect that the route being pursued here in this forum to sync the buffer swap to the glasses might be a bit of a dead end. I don't think there's any contemporary hardware on which you can say anything about how long it's going to take between a GLUT or a window system swap call and when your back buffer actually ends up as photons.

2) On the mac the solution is straightforward — we can busy loop on CGDisplayBeamPosition to pick the spot to swap (note: CGDisplayWaitForBeamPositionOutsideLines seems to be completely decoy, it returns instantly). The brute force approach of course takes most of a core, but it does give you a completely independent program that you can run in the background sending sync out while you start and stop various opengl programs (you have a 50% chance of having the eyes flipped at the start). Of course, being a little smarter about sleeping at the right time will reduce the CPU usage of this approach.

3) Like Kolrabi's code I'm currently using '0' as the offset in the eye switching packet since I can't compute any better value and I don't seem to need to. Staring closely at the USB dump it appears that both the left and right eye signals are being sent with no delay in between them, and then, around 16ms later the same thing happens. Here the offset is clearly required. In my code, I'm sending left and right with an 8.333ms delay between each.

4) It appears that all of the recent "real" graphics cards on Mac's support genuine quad buffered stereo that would appear to work with this technique without inserting additional FBO's into your code's swap routines. All in all, it seems like OS X + 3d vision is an ideal home-brew stereo hacking platform.

5) But I was unable to use Kolrabi's firmware extractor to extract the firmware from nvstusb.sys — either the most recent version or 190.62. It doesn't locate the right spot in the .sys file to make the extraction. Right now I'm booting into bootcamp once — this gets the "green light" on the unit and then rebooting into OS X. As long as the device isn't unplugged it stays useable. Of course, this means that you need to be able to install 3d vision on a windows partition in the first place, so short of illegally distributing the firmware file, ATI users remain out of luck. If it wasn't for that, I imagine it would work just fine on those cards as well.

6) And I needed a different set of magic timing numbers from Kolrabi (different from both sets that they included). The original set inside that code cause both shutters of my glasses to turn almost completely opaque (I can see a little color from the color wheel of my projector phasing in and out). The "correct" set is easily sniffed from the USB exchange that happens when you enter the "medical test image" from the 3d vision control panel. But I'm no closer to understanding the timing formulae — I have it working at 120Hz (actually 119.96Hz) and that's that.

7) Multi-screen stereo is a no-go since the clocks out of both ports of the cards we've tested have an arbitrary phase offset. If you are feeling up to it, you can check and uncheck "mirror displays" until you happen to get them close enough (you can call CGDisplayBeamPosition to find out). That can actually be automated, but seems like a ridiculous solution.

We're going to continue testing the setup here — including purchasing a new transmitter, just to make sure that there aren't multiple versions of this hardware out there (ours is from December).

In any case, it's working and working well — comparable, albeit on a far smaller scale, to our experiences working with high end digital cinema projectors and XPand x101's. It has far better contrast ratio than the XPanD x102's with consumer DLP-Link on the projectors I've tested.

It's probably time to set up a group & repository somewhere to formalize this project, no?

[kolrabi]

Indeed, it seems to me that the the uC is EZ-USB FX2. Checkout the datasheet here:
http://www.keil.com/dd/docs/datashts/cy ... x2_trm.pdf" onclick="window.open(this.href);return false;

I believe the controller is based on this uC because:
- it supports USB firmware uploading directly to RAM (without any eeprom), and it is 8051 based.
- has 8KB RAM for both code and data.
- clock is 24MHz.
- reset and booting sequences match exactly those Kolrabi found.

I will later check out the firmware in more detail. Maybe we can figure out the extract clock info
sent along with the flipping command, and even write our own firmware .

Actually it seems the uC runs at 48 MHz from a 24MHz crystal. But I also think it's an EZ-USB FX2(LP?). In fact most of the routines from the development kit (http://www.cypress.com/?rID=14321" onclick="window.open(this.href);return false;) framework can be found in the firmware, as well as some of the library routines from the small device c compiler (http://sdcc.sourceforge.net/" onclick="window.open(this.href);return false;).

I like the idea of writing our own firmware, it might be made to be compatible with other brands of infrared shutter glasses.

VESA sync is a super simple signal - +5V square wave at eye frequency.

The connector looks like a 2.5mm stereo jack. Which contact carries the signal, and which one carries ground? I wouldn't want to it by applying the wrong polarity.

Last night, drawing inspiration from Kolrabi's code, and some quality time with a USB sniffer, I got our 3d vision glasses working on a Mac.

Very nice

5) But I was unable to use Kolrabi's firmware extractor to extract the firmware from nvstusb.sys — either the most recent version or 190.62. It doesn't locate the right spot in the .sys file to make the extraction. Right now I'm booting into bootcamp once — this gets the "green light" on the unit and then rebooting into OS X. As long as the device isn't unplugged it stays useable. Of course, this means that you need to be able to install 3d vision on a windows partition in the first place, so short of illegally distributing the firmware file, ATI users remain out of luck. If it wasn't for that, I imagine it would work just fine on those cards as well.

Hmm.. what version is your .sys? I could have a look at it and why it doesn't work.

6) And I needed a different set of magic timing numbers from Kolrabi (different from both sets that they included). The original set inside that code cause both shutters of my glasses to turn almost completely opaque (I can see a little color from the color wheel of my projector phasing in and out). The "correct" set is easily sniffed from the USB exchange that happens when you enter the "medical test image" from the 3d vision control panel. But I'm no closer to understanding the timing formulae — I have it working at 120Hz (actually 119.96Hz) and that's that.

Those numbers are still a great mystery. But I found out that two of the bytes sent during initialization of 3d mode are more or less directly loaded into the reload registers of timer 2 of the uC. But I need to read more of the uC manual to really understand those.

It's probably time to set up a group & repository somewhere to formalize this project, no?

Good idea.. I created a project on sourceforge and moved my files there: https://sourceforge.net/projects/libnvstusb/" onclick="window.open(this.href);return false;
I can give you write access to the repository if you want.

[peter64]

Hey Kolrabi and CMS,

This is some fantastic work you guys are both doing. I'm going to setup my development environment some time soon, but i wonder how complicated it would be to get your library Kolrabi working under windows. Assuming I have libusb installed any chance of me getting it to run? I noticed on Sunday you commited some changes that said you were removing win32 support as USB was different on windows.

"- removed code for win32 from nvstusb.c, usb support on windows is more complicated"

Thanks for any updates you can give! You guys have done some great work!!

[kolrabi]

Hey Kolrabi and CMS,

This is some fantastic work you guys are both doing. I'm going to setup my development environment some time soon, but i wonder how complicated it would be to get your library Kolrabi working under windows. Assuming I have libusb installed any chance of me getting it to run? I noticed on Sunday you commited some changes that said you were removing win32 support as USB was different on windows.

"- removed code for win32 from nvstusb.c, usb support on windows is more complicated"

Indeed. It's not as easy as I thought. Just using the Windows version of libusb didn't work. That version is based on an older version of libusb, that has a different API and if I understand the documentation correctly, requires the installation of a special driver. I think it's possible to get it running using cms's code somehow, but I'm not sure how to integrate Windows support in a clean (without using #ifdefs every other line) manner yet. It's something I plan to do, but first I'd like to try getting it to work right. At the moment it is very experimental at best and everyone who wants to try it might need to hack the timings they need directly into the source code to make it work.

Thanks for any updates you can give!

I think I made some progress analyzing the firmware and added my findings as comments in the source code.

You guys have done some great work!!

Thanks

[flyguyjake]

Guys I can't get the activator to run in Win7. I'm getting "The application has failed to start because its side-by-side configuration is incorrect.

I've got a Samsung HL67A750 67" LED DLP which has only 1 3D enabled HDMI port so I need to either force the emitter on or lock it on once activated. I want to play Monsters Vs. Aliens with my new Panasonic 3D Blu-Ray player, but need the emitter on... Please help!!!

[peter64]

flyguyjake:
I got the same error as you, upon investigating it said you might need to install the VC2008 runtimes, but it didn't fix the issue. I think someone linked debug dll's into the pre-compiled version perhaps? If you get it figured out do say report back. Thanks.

[peter64]

Hey I rebuilt it in release mode so now it runs in vista. I see the glasses flickering! good stuff!

[Slah]

Hey I rebuilt it in release mode so now it runs in vista. I see the glasses flickering! good stuff!

Thank you. Good job!

[flyguyjake]

Hey I rebuilt it in release mode so now it runs in vista. I see the glasses flickering! good stuff!

Hi Thanks for that! I got it to run. Only problem is when it turns on the glasses aren't flickering properly or in sync. I'm using a Samsung DLP TV with a Panasonic 3D Blu-ray player trying to watch Monsters Vs. Aliens. I've got 120 & 60 in the ini for the hz. Also I don't think that the F1, F2, F3 thing is working.

Help!

Thanks!

[Likay]

Just a noobsuggestion but have you tried turning on v-sync?

[flyguyjake]

Just a noobsuggestion but have you tried turning on v-sync?

Tried that and still not syncing up. Interestingly enough which my HTPC plugged into HDMI port 2 on my Samsung LED DLP and my Panasonic 3D Blu-Ray player plugged into HDMI port 3 I was able to activate the 3D Vision emitter!

I'm assuming this is working due to the activator.exe but I'm not 100% sure. I don't think it worked before. Here's what I did to get things working.

1) Enable 3D Vision in control panel.
2) Start test 3D functionality. You will get VESA unplugged error message across your screen.
3) Switch DLP TV to HDMI 3 & turn 3D mode on. Turn on 3D Vision glasses, 3D Vision emitter should turn bright green and glasses should flicker

Monsters Vs. Aliens 3D Blu-Ray looks amazing! Images really pop out & depth is terrific.

[Petr]

int a = (int)(0.1748910*(rate*rate*rate) - 54.5533*(rate*rate) + 6300.40*(rate) - 319395.0);
int b = (int)(0.0582808*(rate*rate*rate) - 18.1804*(rate*rate) + 2099.82*(rate) - 101257.0);
int c = (int)(0.3495840*(rate*rate*rate) - 109.060*(rate*rate) + 12597.3*(rate) - 638705.0);

int sequence[] = { 0x00031842,
0x00180001, a, b, 0xfffff830, 0x22302824, 0x040a0805, c,
0x00021c01, 0x00000002, //note only 6 bytes are actually sent here
0x00021e01, rate*2, //note only 6 bytes are actually sent here
0x00011b01, 0x00000007, //note only 5 bytes are actually sent here
0x00031840 };

Do anyone knows the meanings of fields in sequence?
cms please tell how you get those values. Can you publish more info and your ideas about this commands. I would like to join to experiments, but I never use any USB monitors. Please help me to start. My purpose is to launch the emitter with my engine (I can not use native driver because it provides only horizontal shift with a specified value, but I try to create a rendering with head tracking).