Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Announcing foo_vis_dx (Read 4974 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Announcing foo_vis_dx

Try out 0.1 pre-alpha at http://www.cs.indiana.edu/~cshei/nb/foo_vis_dx.dll.  Watch out MilkDrop! (just kidding, MilkDrop 0wns me like Banias notebooks 0wn G4 notebooks).

To turn it on/off just use the Components menu - it's labeled "Test DX visualization" at the moment.  It looks a little nicer with pixel shaders, but I took that out since I figured some old skool video cards lack pixel shaders - I was just using the pixel shader to blur the image slightly.  It also runs faster with SSE2, but I haven't added processor detection routines yet so I just require MMX right now.

At the moment, it only draws the left/right waveforms with a geiss-like effect.  Requires DirectX 9 and MMX and probably at least a 1 GHz processor.  If it looks like it went all black, just wait 10 seconds - that's the bad color randomization at work.  It shouldn't crash, but I make no guarantees about that as I just started it yesterday.

Hopefully, I should have more interesting effects and stuff other than the kind of lame waveforms soon (although I am very busy with lots of fun computer science and numerical analysis homework).  I would love to hear from YOU about your suggestions.

Announcing foo_vis_dx

Reply #1 –
Got this crash...  It is quite an old Pc but I thought I'd post this anyway.  If you need any specs just ask.

ERROR (foo_vis_manager) : Illegal operation:
Code: C0000005h, flags: 00000000h, address: 00A6203Ch
Access violation, operation: read, address: 00000000h
This is the first crash logged by this instance.
Code bytes:
00A6201Ch:  60 A7 00 A1 A0 76 A8 00 50 FF 15 74 60 A7 00 A1
00A6202Ch:  34 77 A8 00 6A 00 68 00 00 80 3F 68 00 00 00 FF
00A6203Ch:  8B 08 6A 01 6A 00 6A 00 50 FF 91 AC 00 00 00 A1
00A6204Ch:  34 77 A8 00 50 8B 10 FF 92 A4 00 00 00 85 C0 7C
Crash info dumped to failure_00000002.txt in your program directory.
If you are reading this, you should restart the program as soon as possible to avoid further trouble, and report this exact message to the developer.
ERROR (foo_vis_manager) : error while processing visualization data, one of visualization clients has been shut down.

Announcing foo_vis_dx

Reply #2 –
Hmm, null pointer...probably a combination of old pc + lack of good error checking at the moment.  Once I add error checking, it would probably just give you an error on that pc.

Announcing foo_vis_dx

Reply #3 –
Quote
If it looks like it went all black, just wait 10 seconds - that's the bad color randomization at work.

This hasn't happened to me yet, but I wondered how this "bad color randomization" works: pick random RGB color and normalize that? Why don't you use HSV color model and ranomdize the H (hue) component? And please add smooth transition between colors (also in HSV space).

PS: If you need HSV<->RGB conversion routines, feel free to dl to source code of my simple spectrum vis and use copy&paste.

Announcing foo_vis_dx

Reply #4 –
Nice effect... A tad slow, though. Are you reading directly from the video surface, or rendering to a texture?

Announcing foo_vis_dx

Reply #5 –
foosion: that sounds like a good idea.  right now I'm just using what timeGetTime() returns as a color directly.

kode54: I'm (software) rendering to a texture.  The bad thing is that you can't use hardware rendering to a D3DPOOL_MANAGED texture so I have to software render it all.  I was reading the back buffer directly before - writing it is fast enough, but reading it drops the frame rate to probably ~5 fps.  It's pretty unoptimized at the moment because I was just getting my thoughts together - the really slooow part is most likely computing a 512x512 vector field to do the swirly effect (that's 262,144 vectors per frame).  To speed it up a lot, I'll put that in a lookup table, since it doesn't change at all.  Eventually I think I'll probably experiment with using a grid and shifting all the pixels in each grid box the same direction to see if that looks OK and if that works it will probably also speed things up.

Announcing foo_vis_dx

Reply #6 –
Render to texture in OpenGL and Direct3D 7. I see nothing about managed DirectX in the latter example, but then, DX7 probably predates that stuff.

...This just assuming you actually have a use for such a process.

Announcing foo_vis_dx

Reply #7 –
Quote
It's pretty unoptimized at the moment because I was just getting my thoughts together - the really slooow part is most likely computing a 512x512 vector field to do the swirly effect (that's 262,144 vectors per frame).  To speed it up a lot, I'll put that in a lookup table, since it doesn't change at all.

If you're doing static movements, a full-rez field is nice, but for a dynamic movement, you probably don't need much more than a 32x32 field. I noticed primitive beat detection too... Nifty.

I'm kinda excited; this is one of the first foobar viz plugins. What do you say the chances would be like to make this configurable like say Winamp's AVS plugin? I don't mean that complex all at once, but over time, maybe?

Heh, I'm an old AVS junkie (even made it into a couple AVSociety releases, way back when), but I'm too lazy to boot up Winamp to mess around with that stuff anymore, and I'm way out of practice.

Announcing foo_vis_dx

Reply #8 –
I gotta tell you... I've got a 1.7ghz P4 here with a random Radeon (can't be troubled to find the exact info), and it's maxing out my processor at what looks like about 15 frames per second.

There's a plugin in the 3rd Party Plugins area called Bubbla.  It's OpenGL, I believe.  Here's the forum thread:
http://www.hydrogenaudio.org/forums/index....ic=5209&st=275&

And here's the direct link to the download

http://webpages.charter.net/gl_ext_biscuit..._vis_bubbla.dll

Announcing foo_vis_dx

Reply #10 –
Bubbla only does 1 thing on here - it says it does 9?

Fathead: You need a faster computer/video card  - it runs fine on my 1.6 GHz with mobility radeon 9000 (then again, it's a Pentium M).  But seriously, I'm working on speeding it up, just need to find time to do it.

kode54: I saw NVidia article once - I think the issue is that if you render to texture, the texture must be in device memory, and reading it is SLOOW.  Right now the texture I'm drawing on is in system memory and gets copied to device memory when needed (D3DPOOL_MANAGED has nothing to do with .NET, even though it sounds like it does).

Announcing foo_vis_dx

Reply #11 –
Yeah, he's testing it now.  It works flawlessly on all the cards we've tested so far... but then again, they were all Nvidia cards.  I wonder if that has something to do with it.

Sorry for posting the link to the vis in this topic... I did it before I realized that it should have its own topic.  I'll take my -1 Offtopic now.

Announcing foo_vis_dx

Reply #12 –
just d/led this (dx, not bubbla). Very nice looking already. Definitely needs optimisations though

Using almost full cpu on AMD 3000+..

Looking forward to this progressing. Nice work!

Announcing foo_vis_dx

Reply #13 –
I was referring to using RTT with hardware-based transformation, rendering to a texture, then using that texture and using that texture and a map of polygons to warp it and render to another texture, then use that texture and the same or a similar map to render to the first. Of course, you'll also be wanting to render this to the display. :B

Similar process can be used to achieve a motion blur effect, rather than using accumulation buffers. Of course, hardware rounding in the repeated blending may cause trailing or other garbage...
 

Announcing foo_vis_dx

Reply #14 –
Oh, nice idea kode54.  I'll give it a try sometime when I have time.