Main > Main Forum

<News> - Sweet eye candy cabinet!

Pages: << < (6/7) > >>

bfauska:

I have an idea that is neither as inexpensive as randy's nor as expensive as the comercial product.  2nd video card+small cheep LCD+duplicate the image from primary card onto second card+put one monitor behind cabinet facing wall= similar effect.  eh?

Ok maybe a sill solution, but I think it would work.

Randy your progress on this sounds great, cool idea and potentially another great way to add some GroovyGameBling to our cabinets.  Too Cool.

MJCarroll:

It's funny because I was just about to start on this exact same project.  I have a brand new HDTV and HTPC and a lot of free time, so I was going to do all of the hardware myself, but hearing that LEDwiz could have support for this feature is awesome.

The main sticking point that I have found for the entire project is that when you take screen shots with Windows, it will not capture the video overlay.  Another person who has homebrewed his own project using CCFL tubes normally used in computers used a DirectDraw Filter to get averages for the screen when it has a movie.  Unfortunately, he will not release his source...

Anyway, I'm excited that this is happening, and I'm wondering when we'll see some preliminary software.

Santoro:

This place always amazes me.  Watching with interest.

blueznl:


--- Quote from: RandyT on April 17, 2007, 11:34:56 am ---I think I mentioned earlier that I was able to use the windows clipboard screen grab method under MAME, even at full screen.  DirectDraw is enabled, so I'm assuming that it is working. 

--- End quote ---

In a window, I assume? Or full screen?


--- Quote ---FWIW, I now have code which does a grid-type sample (user definable frequency) over either the entire screen or just the active app.

--- End quote ---

Using grids is somewhat dangerous, as the screen may be showing a grid, thus confusing your program. A better way may be to use randomly sampled pixels.


--- Quote ---It performs a bunch of real PITA logic to get an assessment of the main colors.

--- End quote ---

Pita?


--- Quote ---I haven't hooked anything up to an actual LED-Wiz yet, but running WOW in a window next to the output window of my app and the colors are reflecting what's going on in the game.  When the screen changes to the blue maze, my control lights blue.  When the Worluk appears, it goes red/orange and so on.

--- End quote ---

Ah, in a window then  :)


--- Quote ---It may not be compatible with D3D.  Don't know, haven't tried it.  It's not "real-time" (currently ~ 300ms intervals)

...

BTW, does anyone know if "real-time" is important on this kind of thing?  If one were watching a movie (which, BTW, doesn't work with this method because the windows capture can't touch the overlay   :'() the lighting would really only need to change with scene changes.  I can imagine it being very distracting if it was all "blinky blinky" every time something happened on-screen.

--- End quote ---

Well, that one is tricky. If you would follow each and every change it would get blinky indeed. What I understood from the AmbiLight stuff is that it actually samples the whole screen, and tries to be smart. Obviously I don't have a clue what Philips is doing in detail, but I guess it's something like this, in pseudo code: (I'm a PureBasic programmer, so I haven't got a clue what you're working in)


--- Code: ---sample screen
if massive changes
  change colour aggressively
  do not allow another aggressive change for 'n' seconds
else
  make small (slow) colour adjustments
endif

--- End code ---

I've got some background in electronics (but haven't touched it for 10 years or so) but here's an interesting variation: using the VGA information directly. Looking at VGA pinning, it looks like the RGB information is right there, effectively making the system work with any form of output.

One idea might be to build a little board with three A/D converters, that simply samples the VGA signal, and returns the information to the PC over USB. A small background program would sample this information, and accordingly control a ledwiz. As an alternative, the board might be able to drive the led's directly (which looks like something rather simple, first an opamp to measure the signal, a capacitor to average the signal, another opamp and driver stage to drive the actual leds, though a PWM driver cirbuit and some PIC logic may improve the results).

Oh dear. I'm rambling.





Kaytrim:

PITA = Pain In The  :censored:

Pages: << < (6/7) > >>

Go to full version