Navi Menu
main blog files profquotes Zygote Asylum contact link junk

19day

2006-02-17

Asylum Dev journal downdate

Filed under: Asylum — 19day @ 00:01:32

It’s been a while since I’ve last worked on Asylum, a pity, but I’ve had a lot of work to do and pulled long nights and some weekend work, and I have my PS2 which keeps me entertained as well. I also have a predilection for buying DVD box sets, the latest being a british comedy called Chef, which I loved way back when watching WNED on saturday nights.

Anyway, I had bought a new book and read through most of it. Called Introduction to 3D Game Programming with DirectX 9.0 by Frank D. Luna (got to love snappy, concise book titles, eh?). Anyway, I wanted more of a background in Direct3D since I’m still porting elements over from the old DirectDraw style. I also need a new videocard, but that’s another story.

The book was alright, didn’t go into too much detail (but given my project’s requirements, I don’t need blazing poly-pushing just yet) but has some nice examples I might be able to learn from. It has to be better than that last book I got, not that it was a bad book, but the example code was in the form of a single massive project that demonstrated everything at the same time, and plain doesn’t compile. And not just for me, for others as well. I still managed to isolate bits of code and play with them enough to understand them, but usually when I think of example code, I think of … well, an example,.. not an entire project which happens to have a million other things going on. Which in turn is why I seriously dislike the DirectX samples MS ships with, the test framework does too much, it’s hard to figure out what is absolutely required, and what is just cruft.

Hopefully I’ll be able to devote more time to this project soon. Though a lot of it will still need to be in the planning stages, since a Mysty like game is one where a mistake can cost hours and hours of wasted effort. Course, not everyone likes Myst like games anymore, a slew of them came out in the past few years, mostly awful, but nice looking. Maybe by the time my game is ready, everyone will be so sick of senso-feely fully-immersive 4D games that mine will seem shockingly retro, heh.

I’d also like to note that lots of people seem to find the asylum subsite due to google image searches for the terms “castle sketch”, funny, my brother drew that, and is basically the only real inspiration I ever had for asylum. If only I could draw.

2005-11-18

Asylum Dev journal update

Filed under: Asylum — 19day @ 02:02:43

More insane adventures in DirectX. I’ve been trying, before actually porting the engine code en mass, to get some foundation stuff off the ground, to make sure all the facilities I want are available. How was I to know that something as simple as capturing the screen to a jpeg would be such a problem?

In the old asylum code, I didn’t bother trying to write my own image routines, I had already written a bmp and gif reader and writer in the past, and that was quite enough for me. I used a library called BMGLib, which had some general purpose image manipulation routines. I had a rather hiddeous API route to take to get there though. I had to get a device context, through my CDX wrapper, to the DirectDraw surface, and copy it into an HBITMAP. BMGLib could then build an image in it’s own format from the HBITMAP and then save it out. I also used this to make the screen desaturate, by bringing the surface into a BMG image structure, using the API call (which was still faster than my method, dammit) and then copying it back. It wasn’t a critical operation to have super fast, and it sufficed.

Alas, with the Direct3D surface, I couldn’t use this method so well, not that I tried it at first, it was a penultimate ditch effort to get a desaturation effect working at all. The problem was that virtually any information I could get on getting a grayscale in DirectX was to either have a second set of textures that were desaturated (useless for me, and a waste of space) or to use a fragment shader (didn’t want to do that since I wanted to keep this thing as simple as possible, who would feel sympathy for a 2D game that didn’t run because their graphics card wasn’t good enough, I’m trying to make it as portable as possible)

One last method was presented, which was using what I beleive is called a fixed function, which is a sort of pseudo pipeline program, except it’s sort of pre-limited by the functions it offers, and was a forerunner before the shaders took over the scene. The information I found suggested setting it up so that it performed a dot product with the texture and a predefined constant such that the result would be the correct desaturated version of the colour. It didn’t use the straight up average of the colour intensities, since apparently the eye responds to colours more or less than others at the same intensity. Regardless, the thing didn’t work, I kept getting an image that was waaaaay to dark, like the contrast was turned up. I fudged the numbers a lot until finally getting something that looked decent.

Now the problem is that I need some way to use this to convert an image (ie: texture) from colour to grayscale for the save/load screen I’ve been thinking of, which was easy the old way, but now I’ll have to come up with some cockamaney render to texture method to convert to black and white so I have 2 copies of the image. Writing out a black and white version of the image alongside the other one is silly and not worth considering.

Which brings me back to writing out textures at all… at first, just a simple screenShot method, writing out to PNG, failed with no output. Odd, the docs said that was a valid format, oh well, let’s try Jpeg. Hey, that worked, let’s look at the picture… okay, it seems it only wrote a third of the image out before giving up, the rest is garbage, and the dimensions of the image appear to be transposed. Turns out the only thing that worked was BMP writing, why did they even bother?

A check showed my DirectX SDK was quite old, like from 2002 or something, but still, the function was valid for Jpeg, the implementation was broken, oh well, time to download hundreds of megs of SDK and hope it doesn’t break anything. I decided not to uninstall the other one, against the wisdom of Microsoft, since I knew that the new DirectX had gotten rid of DirectShow and shoved it off in the Platform SDK which I A) didn’t want to download and B) knew that the one I had worked just fine. Getting the new DirectX stuff working with the old DirectShow actually went off without a hitch.

So I had some basics done, but didn’t feel like porting over yet, maybe now that I’ve got more power, better IDE (VS.NET 2002 (all I got) instead of VC6’s) and know the code a little better, maybe I’ll add in some stuff the old engine never had. I started with zlib, which with a wrapper I got off of that book I talked about in my last entry, integrated fairly seemlessly. I tried compiling the library myself, but it was useless (that kinda stuff never seems to work for me) but it had precompiled static libs and dll’s as well, and they worked fine, so now I can store my resources in zips to make things a little more efficient and nice looking.

I’ve also just recently, and barely, brought Lua into the mix. Lua is a scriping language that I first had to deal with in Graphics class, it was actually quite useful, easy to extend, but still bewildering, and nearly all the documentation I can find is about writing for the scripting language, rather than integrating it into your own code (which is sorta the point, but whatever).

I tried a bunch of different ways to compile the source to libraries, then using existing project files to compile it, then using precompiled libs, and nothing worked. Finally I just brought in all the code into my own project and that seemed to work, and that’s the way it will be until I figure this out. It means longer clean builds, but it will at least allow me to experiment. Oh, and it also caused an Internal Compiler Error which seemed to be related to the use of precompiled headers, so I’ve turned them off for the moment.

I had my own scriping ‘language’ for the old asylum code, it worked well enough, and my infix math parser worked surprisingly well, but I’d prefer something a little more stable. I’ve spent time in the past tracking down a bug that turned out to be a problem in my own script runner.

So I’ve got infrastructure going, I should have a demo available in five or six years.

2005-11-13

Asylum Dev journal update

Filed under: Asylum — 19day @ 22:37:07

I’ve been making inching progress toward my new engine, if you can call it that, there’s still nothing. Really, what I’ve been doing is playing around seeing if the underlying capabilities are easily usable so that I might port my existing engine. I’m still going to have to rewrite a lot of it since the old code depended on a wrapper that won’t exist anymore, but I’ll just write my own wrappers to expose the functionality I need to those ported areas.

I’m going with C++ under visual studio .NET’s IDE, with DirectX 9, but it’s still being quite a chore. I managed to adapt the video rendering to a texture example from the SDK without too much trouble, unlike my previous .NET adventures in the same area. But of course, having taken that step forward, I move a step back.

I tried to see if MP3’s would work ‘out of the box’ without needing to do too much. I stole my MP3Music class from Asylum’s old code base and plugged it in and took a look at it to see what I had done, as it was just an adaptation of the movie player in the old code base which just happened to work. Well, it turns out that it was very nearly what was already in the shiny new video code, except it just took the file and built the render graph completely, rather than what the video to texture example was doing, which was, confusingly, adding input and output filters, and then asking DirectShow to fill in the rest, which didn’t seem to save anything, but whatever.

Anyway, tried playing an MP3, didn’t work… hmm, well, I guess that was to be expected, hey, I’ll just put an MP3 file in my call that renders to a texture, wonder if it will handle that without crashing. Nope, conked out there too.. hmm, always the same problem, all the helper threads spawned by GraphBuilder’s Render function were exiting with error code 0×2, and finally the main program would exit with the same problem. Odd, 0×2, accoriding to the DX error lookup utility, was File Not Found… but earlier checks already present in the routine assured me that the file existed… and then I tried it, rather futily, from the executable rather than starting it through the IDE, and it played. Wha?

This problem only presented itself whenever running through the IDE, debug or release builds, but worked properly through the executables themselves. The interweb was of no help, I tried lots of searches to no avail. The best I was able to come up with myself through debugging was that for some reason, the graph automatically built by the graph builder was wrong under the IDE but fine under the exe alone. It was also able to run as long as the debugger wasn’t attached, either in Debug or Release mode.

I tried a few things futily, was playing with just building the filter myself in Graph Edit and then doing it in code, but in the end I decided that it would probably be best to let the builder do the work (try the filters until one works). I decided to try OGG format, knowing it was a friendly MP3ish thing, converted a test file, and it seems to run file with the graph filters attempts, in all methods. So for now, OGG is what I’m going to use.

Funny that movies haven’t given me this problem, as they are more complex, oh well.

I’ve also just received a new book that I ordered, Game Coding: Complete, Second Edition by M. McShaffrey. I’m both impressed and dissapointed, but I guess I should have read the fine print on the recommendations of the book. It’s really good in the sense that it talks about a lot of high level stuff that is interesting if I was trying to make a breakneck speed game (which asylum isn’t, but might be handy later on) and on how to handle yourself if you were working on a grand project as part of a company. Unfortunately, I thought there would be more actual code, with specific utility in mind. But this is a general game programming book, and not a directx one, so I can only blame myself. It has enough good stuff to keep me occupied for some time, but it won’t be a replacement for the message boards I’ve grown to loathe. I wanted a better resource for the problems seen and sometimes half solved on game programming or directx forums. This book isn’t it, but it covers lots of things I wouldn’t have anticipated needing to do, like rolling my own memory manager, and also tries to get me to do things I still resist against but should do for proper coding, like separating the game logic from the input logic, for example.

Anyway, so at least, for now, progress is being made. All I need to do is write a sprite class (or wrap the existing one on offer from the SDK to give me better functionality) and then I can port some of my crap over. But I think I should give a lot of it a rewrite, since some of the fundamental stuff, like “View” representation is really sucky.

But that means rewriting the View Editor, which is a task I think I’ll put off for a little while.

2005-11-09

Not really a dev journal update, as no progress is made

Filed under: Asylum, General — 19day @ 02:00:24

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 :P 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)

2005-11-03

Asylum Dev journal update

Filed under: Asylum — 19day @ 19:05:12

Ugh, I keep debating what to do about Asylum. Right now it’s on fairly shaky ground with VC6, using DirectDraw with a nice wrapper called CDX on which development has fallen silent. But there are a lot of things I would want to have work, which I don’t really know how to do myself, and if I did (since I know somewhat what would need to be done to make them work) it would be too slow. Like, I’d like to be able to rotate a sprite. You can’t do that with direct draw, CDX does something close, but it uses a filtering mechanism that produces anti-aliased edges, which is usually good, but then it applies the colour keying, which is a single colour (I think I could fudge it up to use a range, but it would be annoying) and regardless it doesn’t work very well. Nor does the alpha blending, hideously slow.

So the idea is moving on up to something a little more clean, but could quite easily be as slow, or slower. Managed DirectX in C# works well enough, at least the demo’s do, and I think I’d have access to everything I need. So no worries about memory crap, and I could use DirectX, er, directly. I’m not really good with Windows/COM nonsense and it’s very flakey to me. But since I took CS488 (Graphics) I have a grip on 3D programming, which is easily adaptable to a 2D game, and I get the benefits of fast rotation, scaling, blending, nearly without thinking.

But, of course, that would mean, essentially, a rewrite. Which isn’t actually too bad, since I’m not far into this project, most of it was infrastructure, which is the stuff that has to be rewritten. I dunno, then I would be bound to the CLR, which isn’t something I want (ViewEdit is fine cause it’s just a tool for me) but it’s not like the .NET Framework is installed with XP, which means my audience will have shrunk.

I could remain in VC6 with DirectX and use Direct3D to get everything I want… but DirectDraw alone is messy, I dunno if I could stand Direct3D. More research is clearly indicated.

2005-10-30

Asylum Dev journal update

Filed under: Asylum — 19day @ 23:35:15

I suck. It’s been so long since an update, and over two years since the last release, wow… university really sucked the life out of me, and work has left me a little too tired, but I’m determined to start up one of my projects again. The options were working on Asylum, or on Zygote, and as I don’t think I’m ready to deal with porting a heavily unix codebase to windows for the larger casual download market, or to find windows versions of the libraries I’m hooked into, nor do I feel like working on an intelligent sperm game at this time.

So I’m focussing on Asylum… not sure if I’m going to do the code rewrite for managed DirectX on C#. I would lose the use of my wrapper (CDX, makes DirectX on VC6 bearable, but it isn’t being updated anymore, and I certainly don’t feel like rewriting it for Managed DirectX on a .NET language) plus I don’t know how fast it would all be. But if I rewrote it to get away from Direct Draw and use Direct3D methods for a 2D game, I could take advantage of a lot of faster stuff, so it might be worth doing. Anyway, for the moment I’m working on stuff on the existing codebase, and working on ideas for another demo.

Powered by WordPress


Page by 19day (S.B.H.)
Everything here is property of 19day productions, unless it isn't, and cannot be claimed by anyone else regardless, sort of like a copyright, but in many more words.
Last modified: September 07 2009 18:21:00.
Valid XHTML 1.0! Valid CSS! CWH Get Firefox