glOW - New (unofficial) light generator program

[Uhyve]

So, I've made a quick program that let's you use amBX with anything your computer displays (the desktop, flash videos, whatever). It might cause alittle bit of stuttering when playing games, so maybe let FXgen handle that, but it should work fine with everything else (including Aero).

Dunno if there's any interest in this. It's really early (the interface will have a purpose at some point) but it should be relatively bug free I think. Interesting features include: Aero support, multimonitor support and color balance settings (check the settings.ini for the latter two).

Guide: Just run Interface.exe. And let me know if you have any problems.
Possible Problems: Not entirely sure it'll work on Windows XP. If it does, apparently the screen grabbing method I'm using may be slower on it.

In case of '.Net' error on program start, install this:
http://www.microsoft.com/download/en/details.aspx?id=17851

In case of other errors on program start, try installing this:
http://www.microsoft.com/download/en/details.aspx?id=8328

Recent updates -
Reduced memory footprint (10x)
Improved screen averaging
Added fan and rumble control
Added the ability to select areas to average (ini)
Split the screen grabbing into separate jobs (speedup, with a tiny drawback that I'm fairly certain nobody will notice...)

Check changelog for more details and to see older updates.

[LoB]

Hi Uhyve,

thank you for participating in the amBX (developer) community. I'm sorry to tell you, but something similar has been created already. Have a look at Aurora Synesthesia.

But keep things coming. The amBX community is always in need of new cool software.

Or, maybe you could take over the development of Aurora Synesthesia? Zodius, the creator of that program was searching for a successor. Maybe you want to get in contact with him, and your ideas and his can be merged.

[Uhyve]

Yeah, I noticed Aurora, I don't expect to compete with it or anything. I was making a completely unrelated program that turned out to be a bit of a bust but it just so happened that the code could easily be stripped down and turned into an amBX app. Been curious about the SDK for a while, so I figured I'd give it a quick go.

I could get in contact with Zodius, but I'm not really sure how much I could improve with Aurora, the guy who did that thing seemed very good.

PS Just curious, does Aurora work with Aero? I heard it didn't, but if it does then me uploading this was probably alittle pointless, haha.

[icke]

Yea Aurora doenst workt with Aero and is abandoned by its creator.

So i was just thinking how annoying it is to have Aurora turn off Aero and wanted to request something to work around.

And then i found your program, wich i am happy to try. If it reacts fast and works with Aero i will be happy.

Edit: just tried it, sadly its far to slow to be useful

That light calibration is great idea, i asked the developers many years ago to include it into the drivers.

Another great thing would be, if you could program something to setup the right positions of the lights. Like showing the available zones on-screen (wich the lights can react to) and people place the devices they have in thoose zones, to get the best reaction to onscreen content.

[Uhyve]

If you mean the flicky light changes, that should actually be fixed now. But if it is just the delay of the lights changing, it should be down to 0.2 seconds in the version I just uploaded. You can improve that by lowering the ScreenFreq value in the settings.ini, but it might cause some slowdown (I've not tested how far I can push it on my computer but it's at 1-2% with a frequency of 200).

I'll have a think about the light position idea, there's no option for it in the SDK but it'd definitely be possible.

[icke]

Ok i will check the cfg file then, great.

Just tried a value of 20, takes about 11-14 % of my CPU, and i think it reacts almost as fast as the native amBx profiles. But at too much processing power.

Are there ways to improve that? Might have to do with my relativly high screen resolution (2560x1600). I have no idea how you read out the screen content, if your program calculates with every pixel on screen or it it sums up into bigger blocks and takes the average, maybe there is some room for improvment in the way your program reads the screen content.

Also another feature idea, how about a setting that ignores total blackness. Just tried your program with a photo slideshow, and since i configured my ambx setup, as good as its possible with the drivers, to react to the sides of my screen, most of my lights stayed black if a portrait picture is just shown in the center of the screen. I imagine it would be nicer if it ignored the black stripes left and right and just calculated with the area the photo is acutally displayed it. Also good for movies, ignoring the black stripes below and above the video. Ok enough ideas for now.

[Kryss2k]

I just gave it a go and I like the fact it works with Aero - AS didn't overly bother me not working with Aero as I'd have my videos on full screen anyway.

I found no issues with delay but - I'd love a way to move the source spots as for me I think they need to be closer to the edge of the screen but can see why this could be an issue with some sourcing methods.

I did notice that the lights do on occasions tend to stay black/off but I personally prefer that when using some programs/applications - the ability to turn that on/off would be great

One thing that bugs me with the Winamp plugin is that when parts of the screen go black the lights stay the last colour that was in that section - in this case your program is better

I'd love to see how your program progresses

[Uhyve]

@icke: The newest update should improve stuff with borders and lower CPU usage a bit. I was getting 5-7% CPU with an updatefreq of 0 (though I wouldn't recommend that), not sure what it'll be like at a nice screen resolution like that, but it might be alittle faster than before.

I found no issues with delay but - I'd love a way to move the source spots as for me I think they need to be closer to the edge of the screen but can see why this could be an issue with some sourcing methods.

I've actually been looking into this a bit, I wasn't happy with the screen averaging in <=0.12 since it didn't seem to be averaging screen colors properly. So, I've been messing with different screen capturing/averaging techniques, in the newest version, I'm using something called StretchBlt(), it's very old but works surprisingly well and will allow me to select different portions of the screen to average, when I get to that point.

I was originally getting the screen image using something called BitBlt() and shrinking it down with a DX function called stretchrect, but yeah, didn't seem to work properly and was very wasteful memory wise.

I did notice that the lights do on occasions tend to stay black/off but I personally prefer that when using some programs/applications - the ability to turn that on/off would be great

Hmmm, yeah, I heard that there might be a few programs that are incompatible with these techniques, may need to implement an alternative option at some point.

[icke]

I dont know if its possible or if you have access to how the screencontent is calculated for ambx. Maybe things could be made faster with an option that skips pixel. So if it now is really processing every onscreen pixel to get the color, the program could you only use every 2nd pixel or 4th, 8th, 16th an so on, that should still give an accurate color, but could be faster in processing. This could be something people could find their personal setting in the config file. But again, i have no idea how its done or if this makes sense.

[Uhyve]

It's a good idea, my current method can select portions of the screen to use, so technically, grabbing every other screen pixel would be possible, but I'd wager that having that many separate memory accesses would end up being slower, as opposed to the current big sequential one.

If I do implement the screen portion selection stuff, that may end up being alittle bit quicker, since it could be a middle ground between every other pixel, and every pixel, since I'll be able to tell the program to grab a rectangle of pixel values, which is something that most hardware will have been designed to allow.

One thing that could definitely speed it up is Windows 8, as it includes something called WDDM 1.2, which apparently allows hardware accelerated screen duplication and the ability to only grab pixels that have changed. It would need to be specifically programmed for, but I'll probably give it a shot when a newer beta comes out... as long as amBX works for it.

Edit: I'll try the screen portion thing next, I just tried Minecraft and it was definitely stuttery. Guessing other games are even worse.
Edit 2: Added the screen portion thing to 0.15, it's quite a bit faster, but games still don't really like it.

[CountRock]

Amazing work there! Works great. Need to fool around with a little bit more.

[Milmoor]

Windows 7 has small versions of the actual program in the taskbar when alt-tabbing. They have enough pixels for processing, this might speedup things. Not a clue how to read them though and whether they are always generated or not.

[Uhyve]

It's definitely something to consider, the method I'm using at the moment has too many drawbacks. I think you might actually be able to get access to those thumbnails, though I'm not entirely sure whether or not it's considered a hack. I believe that it would be very fast though, because they're nice and small, and because they're pulled straight from the WDM. It'd have a few hurdles, the main one being that you can only get window thumbnails, not a thumbnail for the entire screen. So I suppose, I could either try to make a composite of the desktop using all of the windows thumbnails, or just use the top window (so much easier, but then amBX would only create effects for the top most window... which could actually be pretty cool).

What I've been looking at most recently is a mirror driver for graphics. It'd be super fast, work with practically everything and have very little latency. It'd be massively time consuming to do this myself, and I don't think many people would feel comfortable installing a driver from some random guy on the internet, but luckily there's already people who have done this, even more luckily, UltraVNC have an SDK for their driver (they use it for remote desktop). So yeah, that's definitely a possibility.

The other possibility; make do and wait till Windows 8. Annoyingly, since I've got different (stressful) project that I have to get done, that is probably the next version I'll release, it shouldn't be, but probably will because I want to play with the new Windows APIs at some point.

PS Tiny update for glOW uploaded (0.16), performance should increase maybe 25-50% at most, made a small mistake with my update timing, and was grabbing some portions of the screen more than once per ambx update (which meant some screen grabs were completely pointless).

[Broccoli]

Been using Aurora for years and stumbled on this thread - this is just what I've been looking for, and it's great that it works with Aero!

The only improvement I could ask for would be a little more optimisation - running with an update frequency of 100ms currently takes around 8-12% CPU (running in 1080p on a 2.66Ghz dual core). I would have no problem at all with installing a mirror driver, if it meant better performance.

[Bad213Boy]

Been using Aurora for years and stumbled on this thread - this is just what I've been looking for, and it's great that it works with Aero!

The only improvement I could ask for would be a little more optimisation - running with an update frequency of 100ms currently takes around 8-12% CPU (running in 1080p on a 2.66Ghz dual core). I would have no problem at all with installing a mirror driver, if it meant better performance.

Exactly what I was about to post.

Hey please keep working on this thing. You might be on to something great. I like how you included the Fans and Rumble pack, hug props. amBX software really sucks balls IMO. The old software worked better with lights than the new stuff.

Is it ever possible to use drivers from game controllers for our rumble pack?

Here's a link for Aurora Synesthesia Alpha v1.06

Here's the original thread:
viewtopic.php?f=2&t=2766

***** ADMIN *****
Please sticky this!