AaronCameron.net
Wrecking things for people is important - it makes you a better person. -- Sabrina Constans
Not a Member? - Login or Create an Account...MC Offline
Tuesday the 17th of October 2017 @ 02:40pm
Front Page Projects Your Profile About
[]
[]

Filed Under: Development - Game Development

Week Ends Update

2003.07.02 12:55am
Aaron

So, the time off has ended and I figured it would be a good idea to summarize some of what got done before heading off to bed. It has been a good break with a fair amount accomplished, and I can say I'm mostly happy. Unfortunately I seemed to falter toward the end, but I suppose that's somewhat to be expected. So anyway, here I go.

Onyx

Onyx got a fair amount of attention including a new website, bugtrack project, wallpaper and a set of internal design documentation and story line outlines. As far as the code base, I did a little work, but not much. Most of the actually coding I did has been auxilary to Onyx and focused on the libN2L codebase instead. All of that added code directly mapped to things needed to get Onyx off the ground though, so progress was made.

In the artwork department I'm honestly not sure what if anything got done. pierre had a lot on his mind with moving and *ahem* other things... so I doubt much of substance got added. That's fine for the most part because I'm not really blocked by the artwork at this point. I'm sure things will start materializing a lot more in the next couple of weeks.

Soundtrack has moved not at all, unfortunately. I still have to get off my lazy ass and arrange quite a lot to get the audio side of things lined up. Not to mention the fact that there is absolutely ZERO audio code in libN2L at this point. I still haven't even decided if I'm going with SDL_mixer or OpenAL, yet. Probably OpenAL from the looks of it, but having never even compiled a test project yet I can hardly say with any certainty. So, that was a long winded way to say, nothing.

Story is finally taking root in the Onyx world, and is starting to gel to a point where I can get a feeling for where I want things to go. This has to be the only project I've ever worked on where the story backbone started appearing well after the game assets started to materialize. Luckily I think things are still early enough that no work was wasted. I can also say on a personal note that some of the adjoining material between Onyx and Life 2130 is really helping me to engage myself. It's almost as if a moving target just had a net thrown over it and it's finally possible to start attacking it.

LibN2L

LibN2L was (as usual) the primary focus of all the development that took place in the last few days. Almost all of that development I've been posting about in my journal this week, so I won't go into it all again. To summarize things development went very well. New events and event handling was added, lots of optimizations were added and a lot of bug fixes went into place. All in all, good strides were made in the code base.

On a more exciting note, I've set up a working cross-compile suite and can now make Windows binaries (exe's) right from my Linux box, just by running a script. Getting things working was a little hairy, and testing was a pain in the ass since I don't actually have access to a Win32 machine. BUT, things do indeed work. I even have proof:

That is indeed the Md2 selection test running happily on a Windows XP system which Thanatos generously donated along with his patience to help me get things working. This is actually a big step for me, since up till now I haven't been able to get a project actually link on a windows system. It also means I don't have to deal with the nightmare that is Visual Studio's compiler. All around I'm quite pleased with the cross-compile tools. You'll also note that Thanatos went that extra mile and endured my Onyx background long enough to take the shot. That speaks volumes of his character, let me tell you. :)

Life 2130

Life 2130 is not a dead project! I really can't say that enough. In the past few days I've clarified some of the story line, and mucked a little with the RPG system it will be using, as well as plotting out its development schedule a little bit more. It is safe to say that Life 2130 is alive and well (excuse the pun) and receiving active attention. Most of everything that has been done is internal development and documentation, though; so there really isn't much for me to say about it.

Jimmy's World.org

Not a whole lot happened to Jimmy's World, unless you count the addition of the Onyx site. I'm about half way through adding a C++ tutorial, which makes about 3 tutorials which are half done now. I had really hoped to add it before Wednesday, but not everything can get done, and the tutorial was a very optional project, as far as I was concerned. So, yeah. Jimmy's World is still Jimmy's World... and that's all I have to say about that.

And... Yeah..

All in all I suppose I'd have to say that yes, things went rather well. Certainly I could have used more time, and I could have made better use of the time I DID have. As always though, this isn't a sprint, it's a marathon. The real test will be to see if Onyx can materialize into a runnable test in the next three weeks. Longer than that and it has taken too long. LibN2L has more flaws right now than I can comfortably comprehend, but certainly it is far enough along to not be a restrictive agent any longer. The time is right, the story is starting to be there and the art is falling into place. Now starts the real test. Can I get this to materialize?

And with that rather melodramatic question floating in the air - I'm going to go to bed. Reality is afoot.

See or add to 0 Comments

Share:

Keywords:

Filed Under: Development - Game Development

Speed & Selection

2003.06.25 09:24pm
Aaron
So I had intended to do some interface code, and as it turns out I wasn't quite ready for it. At least not as ready as I had thought. Drawing stuff isn't really a problem any more, it turns out that actually interacting with things on the screen was a bit less trivial than I had expected. The way I figure, most of my interface with widgets will all be taking place in an orthographic projection, so the coordinate maps will be really easy to map. That is, the mouse is @ x,y in real screen resolution, and I can easily scale it to the orthographic coordinates that widgets exist on. It occured to me though that I had no way of selecting anything that wasn't rendered on the orthographic layer. So, I had to take a brief trip into OpenGL selection.

You know, I'm working witht he selection mode now and I can't help but feel like this isn't the way it's done in reality. I mean it works, but it seems more than a little cludgy to re-render the scene over again just to find out what the mouse has clicked on. But look as I may the only method that seems to be described over and over is using selection. Anyway. I took my orc model toy and set it up to do selections on it, and got the code in place and it DID work, but good lord was it slow. When I did the Md2 class I was basically just hacking to get it working. Not dirty, but not fast either. I set up three of my 'dancing' orcs and everything worked like a charm, but when the mouse was clicked it was rendering eight copies, four visually and four for the selection... and damn was it slow. The frame rate was diving to around 20-30 fps when the mouse button was down.

My little orc models aren't terribly complicated, so rendering eight of them shouldn't have been causing THAT kind of speed drop. So, even though I wasn't planning on doing any optimization until the end I was stuck messing with the Md2 class just to get it to work under TEST conditions. It was prety depressing. I hadn't expected any test scenario to run into speed problems, not on the hardware I'm running here, but herer I was with a simple scene, unlit even, and it was a dog.

I figured I should set up a baseline test, so I set up the camera and positions and disabled my checkboard floor and mouse cursor and got to work with some optimizations. Just to quickly start I did some pre-calculations for the verticies and texture maps and unrolled a loop, figuring I'd buy myself a couple extra fps and boy, was I ever suprised. When I started my baseline code was running at about 55.3 fps, after the optimizations it shot up to 425.7 fps. Not exactly a small gain. Not only did the speed increase, but I found a bug in my vertex transformations that was causing the z-axis to be a little fuddled. Something to do with reversing the axies before doing my translations.

So, yay! About an hour later, a bug fixed and a ~ 700% speed improvement everything was good to go. The only thing left is to disable the texture rendering when doing the selection, and maybe find a way to render a simplified model. Even without things are acceptable again, so I'm happy.

After my success with the md2 class I dug into my particle engine to see if I could buy some quick improvements in that code too. I probably shouldn't have, because I didn't have nearly the luck I did with the md2's. I moved some of the billboard calculations out of the render method and grouped my particles by texture but it didn't buy more than a 5-10 fps increase for 5000 particles. I'm not sure what to do about it now, exactly. I know I can get about 10,000 particles to run at ~30 fps if I lower the particle size, but it just doesn't look as good. *shrugs* Anyway, I doubt I'll get into any scenario's with Onyx that even require two thousand particles at once, let alone ten thousand, so maybe it won't be a big deal.

Just for the fun of it here's a screen shot of the fps test and selection code. The models clip into each other all over the place, but it gives the idea. Notice the nicely rendered hyperion font (anti-aliased, even) and the little orc-hand mouse cursor in the bottom right-ish corner of the image. Even casts a shadow... that's how bored I was. For even more fun I threw in a shot of the particle fountain running with 10,000 particles. Well, 9892 particles, with the target being ten thousand. It's been reduced to 800x600 from 1024x768. Nothing new or exciting about it, just makes the screen shot row two wide instead of one, which looks lonely.



Anyway, now that I have selection code working (which I'm not even going to use for the menus) and some more experience I think I'll try again on my widget code tonight. And I still need a stupid keyboard manager as well. I'm not super clear on how to move focus around, and how exactly to set up buttons and text boxes vs. their input controls... but hey, if I knew it wouldn't be any fun, right?

So... back to it.

See or add to 0 Comments

Share:

Keywords:

Filed Under: Development - Game Development

So, yeah. It would seem that textures in fact must have power of two dimensions. How in gods name there's so much discussion about using non-power of two dimension textures alive and well on the net is a total mystery to me. Maybe some magical property on the card has to be toggled, or diddled or twiddled before it'll work, but you know what? I just don't care. That's right. This is me, not caring. La la la... still don't care.

So now I'm going around the code dutifully un-fixing the texture creation code. And let me tell you this, it's great fun.

Disclaimer

The preceeding journal entry had absolutely no value, and should not have been read by anyone.

See or add to 0 Comments

Share:

Keywords:

Filed Under: Development - Game Development

Yay, updates. So I've been spending lots of time reading about lighting and trying to figure out the best/easiest way to light things in Onyx. Right now it would seem that the best thing to do will be to use regular GL lighting to create the simple shading effects (making things look 3D) and use a modified patch/lightmap for each ship to paint hilights caused by engines, explosions and weapons fire. I'll write more when I have a better idea what I'm doing. Right now lighting is still a bit of a mystery to me, so I'm not sure anything I'd say would be even remotely correct.

Fixes. There have been quite a few fixes. And, there have been quite a few fixes of fixes. The most notable of these bumbles would be my 'fix' to the cGlTexture class to enforce that all textures be sized of the form m^2 by n^2. Basically that textures had to have a size like the following, 16x16, or 32x256 or 512x2048, etc. I have no idea where I read that requirement, but it seems it should have been 2m by 2n. The xSize and ySize only have to be divisible by two, not some power of two. So a whole lot of ugly code to fix that mistake has been removed and a bunch of new ugly code has been put in to fix that requirement.

Along with the fixes I've enhanced the cSurface interface quite a bit to allow more sensical access to the surfaces, as well as some simple primitives to manipulate them. It's truely awesome to have a good software surface API like SDL to be able to muck with things before they get into texture memory. It allows all sorts of trickery like the true type font texture generation that I'll be talking about soon. It really is priceless to have a solid community and well written interface to all these low level things. I can't even imagine trying to do a graphical project without it.

Along with fixes, I've added font support to libN2L, which was a long time coming and a LOT easier than I had expected. Right now I'm only allowing texture fonts, what Photoshop/Gimp people would know as a bitmap scaled font. Luckily, with some surface trickary using SDL I can generate a bitmap font on the fly from a True type font, which makes importing fonts into the engine wicked easy. Eventually I'll have to make some class to support the actual geometry of true types, but for now I'm content with using prerenders. They're anti-alised and mipmaped by any arbitrary quaility level, so it isn't like they're ugly... and when they get converted into a texture font it's wicked fast to render them. So I'm not going to be complaining any time fast.

Thanks again to SDL, the whole thing is tied in and working well with the virtual file system. I was worried for a bit when I saw that SDL_ttf didn't have RWops support but apparently the newest version has it built in, which saves me a lot of tinkering with code I don't understand. I'm a little disappointed that Red Hat is still distributing an old version of SDL's runtime but I would imagine by time I'm ready to release Red Hat will have caught up. It doesn't matter that much anyway since any binary public release I do will all be statically linked anyway.

A good friend of mine asked just a couple of days ago if Life/Onyx/? was going to run on Win32 and I said yes, but there's a good question buried in that question. Does it? The last test build I did on Win32 was over a month ago, and there's a lot of new stuff in the codebase that hasn't been tested. There's also quite a few outstanding problems that I had to jiggle the handle to get working in Win32 LAST time. I can only imagine how much there is now. I'm really getting a sinking feeling that I'll have to waste some time soon getting a test environment set up on my machine to build Win32 versions. All this is forgetting that my successful test months ago was only building libN2L, not any test application itself. I seem to remember that when I tried to build the particle fountain toy the linker went nuts, and I never found out why. I'm just assuming that my ignorance of Visual Studio was the problem. Hopefully.

Speaking of compatibility, I haven't even TRIED this thing on OS X yet. My girlfriend has a Mac in the apartment, but I haven't installed any development tools on it, so I'm really not sure what's going to happen when I actually try to BUILD anything, let alone run it. I guess I've just been assuming that Darwin's UNIX roots would make it easier to cross-compile than windows. I hope that doesn't turn out to be a big mistake. I just loath the idea of wasting a whole bunch of time setting up a test environment. Bah... some day.

I took some of pierre artwork and twiddled it a bit to make a desktop. I'd like to put it up, but the bastard hasn't emailed me back with his approval. I'd do it anyway but I know he'll have a hissy-fit if he thinks it's as ugly as I suspect he will. Oh well, works for me at least. *rolls eyes* Artists.

Speaking of pierre, he's been learning some 3D graphics stuff himself. I never stop being amazed at how quick he's learning, and it really, really PISSES ME OFF. Bastard. I'm thinking he's going to catch up and pass me in a matter of weeks. I can't even begin to explain how depressing that is. Of course, he IS learning DirectX, and you know what Master Yoda says... "If you choose the quick and easy path... you will become an agent of evil."

I think that's been a long enough break. I'm getting more into keyboard handling and I'm going to slap together some quick GUI widgets so I can move onto the Onxy startup. Now that I have fonts, and will have simple widgets I think it'll be time to actually focus on the game itself. Now that I'm only about 3 months late, it's about time.

See or add to 0 Comments

Share:

Keywords:

Filed Under: Development - Game Development

Where to begin? It has been over two months since I last wrote a game journal, and the libN2L development page is even further out of date. So, is that the end? Is there no more Life2130? No more libN2L?

Nay!

Nay I say. No, in fact things are cooking along nicely. I'm just a useless boob that doesn't have the attention span required to write regular development journals. But all that's going to change as of tonight.

So, as I was saying; where to begin? Well, scanning over my last entry I see that quite a lot has changed. The suggested Life2130 site is now up and running right here, and new libN2L updates are in the pipeline.

I guess first I'll go over the new stuff and changes in libN2L, since it is the root of all of the development I'm doing right now. Firstly, the version for the library has been bumped again, so now it's libN2L-4. The version was bumped because of a file structure revamp and a new naming protocol which I'll be putting up on the libN2L Development site soon. I've also renamed a few classes, and restructured the video class tree a bit, so it didn't seem right to keep with the same version any longer.

Along with the format and structural changes, libN2L has a few new rendering classes including a camera class, and some basic code to allow billboarding. The real excitement right now is the addition of md2 file loading, with basic support for animation. The interface for it is really rough and it leaks like crazy, but it does work. Soon I'll be polishing up the interface and cleaning things up and it should be good to go for our first tech demo. For those of you who care, here are some screen shots of a model in my test environment. They are actually both moving, so it's kind of neat.

Along with the addition of the md2 loader I've been working with particle effects, which is pretty much hand-in-hand with billboarding, at least axial aligned billboards. I've been able to get some pretty neat stuff working in the test environment, but nothing has been integrated into the library yet. I'm not sure exactly what kind of interface I'll need for particle systems so rather than rewrite a dozen times I'll put it off until after or during the first tech demo. That way I'll have some experience working with them. Anyway, once again here are some screen shots.

What else... what else. I've also added some utility classes to work with the VFS to load configuration files, and to validate the settings defined inside them. It's a pretty neat toy with arguably useful application. The basic idea is that the game can create a configuration file template outlining what values it expects to be defined, along with default values if they aren't, and it can have a list of validators attached to it. Validators like vfs node types, it must be a file, it must be a directory, it must be a image, etc. The types can also be more generic like must be a string, must be a float, etc. The whole thing is set up using the dynamic variable system, so the values assigned can be used without any conversion from the file.

Anyway, Onyx awaits. It still needs a site, and I've got some last work to do with the engine before starting. And I'm not getting any younger.

Please note: Nothing is going to change, in fact. Journal updates will be as infrequent as they are now, forever.

See or add to 0 Comments

Share:

Keywords:

©2017 Aaron Cameron