Holy crap, what a waste of a weekend. Well, some of it was wasted sleeping, but lots was also wasted trying to get the half baked mess known as Managed DirectX to work.
Well, perhaps that’s too harsh, it’s the AudioVideoPlayer that’s the shambles. The rest of managed direct3d is actually quite nice, but it hides a lot… perhaps too much, and it renders almost all information you can get online useless, since it’s very difficult to even convert from unsafe C++ direct-directx code to managed, since usually the person giving help is using a bit of trickery which is perfectly legit in the unsafe world, but doesn’t have an analog (that I know of, that is) in managed. And there is very little online help on managed stuff anyway.
But all I needed, really, other than basic direct3d functionality for a 2d engine, was the ability to play movies onto a texture. AudioVideoPlayer is the class for it, it’s about all it can do, and it can’t even manage it. It’s like a car that won’t start… what’s the point in having it, and then thrashing it with a branch (ala Basil Fawlty). It’s actually quite an adventure to get working at all, the demo seems to work fine, but if you mess with it even a little bit, it can break. But here’s what I’ve found (and other sources on the net can back this up)… you can’t use the same object to play different movies.. every time you open a new movie, you just leak megs of memory. Okay, that’s fine, dispose the object and make a new one each time.. right? Wrong, at least for me, it just causes (sort of randomly) a null reference exception, reportedly on the line that says “videoTexture = null”, which is amusing.. but it is actually occuring in the annals of the dll which gives us the lovely functionality.
So the choice, leak horribly and let the thing run for a while, or don’t leak and crash in a minute. Of course, the option is to just do away with the whole thing. The implementation is broken, hasn’t been fixed in years (people were complaining about this in 2003), directShow is off the table for the most part. I’m sure managed directx would have been okay for Zygote, but I needed movie playing ability or else it was a showstopper.
So the show stopped. And I was back to square one (being my original codebase for asylum, running on DirectDraw 7 wrapped in CDX). It works fine, but why would I want to change it?
Well, a few reasons. The CDX hides a lot of stuff away, making it hard to do anything unsupported by the wrapper. I could examine the wrapper, and I have to some extent (enough to get the sprite thing to work properly), but being a wrapper, it handles a lot of stuff, and it’s all just there, with workarounds and stuff all over. It works nice, but I don’t learn a lot from staring at the code, and further, it’s direct draw, and you’re supposed to use direct3d now (I don’t know why MS wouldn’t just keep the interfaces but just link it up into appropriate direct3d calls to fake it up… oh well, guess that was an exercise for the reader), so I’m not very motivated to learn directdraw at all.
Secondly, being directdraw, and not updated for a while, it has virtually nothing useful that you might want to do to a sprite. Hell, DirectQB had more functions built in If you want to rotate or zoom a surface, you have to write it yourself. Now, I’ve done this, but it was damn slower than the CDX one, but the CDX rotozoom doesn’t preserve aliasing so your colour keys go kaput. Also, the alpha blending routines, that would have come in handy a few times, are nearly useless for anything you want to run more than 5 frames per second. Of course, it’s all done in code, so it’s almost destined to be slow.. that’s why they made things hardware accelerated, but as directdraw was never updated, it’s now standard to use direct3d to fake up a 2d engine, and all that alpha blending and rotating and anything else you would want to do, comes free and fast since drawing triangles (say, 2 to make a quad) and texturing them (with, say, a sprite) with an alpha channel (to knock out the stuff you don’t want), is part of the purpose of the card, and exactly the type of stuff I want.
I’ve been okay so far on my current codebase, and really, so far, nothing I’ve done strictly requires the extra functionality, but it would be very nice to have, since I’ve tossed some pretty but unnecessary things due to this, and will probably want such things in future.
So after the managed directx attempt, I fell back to square one, but now I’m trying again, but on another board. I guess another question is, why would I want to try managed directx at all, you wimpy loser, c’mon, managed is a four letter word, etc etc. Well, I wanted to learn a bit of C# as I went (and realize that I don’t really like, heh, I fall into my C++ knowledge and go wtf whenever C# does something I don’t like), and since I didn’t need crazy power in my game (think turn based 2D game) that the overhead by the managed code was more than fair to be able to use direct3d without a lot of messing about with, in my view, crazy-code. Looking at unmanaged directX code gives me a headache, but that’s because I’m mostly unfamiliar with it. I’m actually not very familiar with COM stuff, so that gets me a lot too.
So Managed DirectX seemed like a good option, but screw it, the damn thing don’t work (huck-yuck). So I’ve been looking at the C++ SDK for DirectX 9 (I’ve also got the VB.NET and C# versions). Anyway, they have a directx 9 video texture renderer in the directshow samples, and it seems to work very nicely. I’m a little familiar with directshow since I needed to make enhancements to the cdx movie player which wraps directshow a very little bit. So I figure if I learn enough of it, I should be able to wrap it into something a little less intimidating (and I think it’s already wrapped in the example code, which doesn’t bode particularly well), and move on.
Direct3D shouldn’t be too bad once I get past the setup, enumerating, initialization, restoration, rendering and releasing… err, well, the code is all in caps, but at least I know what it *should* be up to since I’ve already played with managed directx which basically does the same stuff but in nicer speak. And my openGL knowledge should be of some limited use, if only to get the set up for the 2d working the way I want. I got something interesting going on the managed attempt, so I can just port that when I have a framework set up. DirectX also provides a sprite class which might be useful, although I might want to do it myself to learn.
Not sure why I posted all this,.. it was mainly to vent about the managed audiovideoplayer being a pain. ugh, oh well, might as well learn how to use the fast directx for when I want to port zygote, since then I’ll want all the speed I can get (to cover my other inefficiencies, heh)