[http://dphrygian.com/news/]

• http://dphrygian.com/news/ - (David Pittman)

I had a blog at http://dphrygian.com/news/. It was mostly brief essays on topics I encountered in my hobby projects, but then I got busy on my profesh game and it hasn't been updated in a year. And now that Blogger doesn't support FTP publishing, I'm going to have to migrate it elsewhere one of these days.

For starters, don't trust this code. It looks sketchy to me. Put some breakpoints in BMPImg::LoadBmpRLE8() and make sure it isn't hitting any weird cases.

This looks especially suspect:

Code:

case 2:  // Reposition, Never used
  break;

I'd double-check that that case isn't needed in your BMPs--reading about the file format (e.g., here) doesn't suggest that it is actually never used; it may simply be a case the author chose not to handle because his image tools did not export BMPs with that indicator.

Also:

Code:

if(iIndex>iDataSize) // Stop if image size exceeded.
  iDcode=0;

That seems like it should be reporting a warning or assertion failed if not an explicit hard failure case; if image size is exceeded, the program clearly failed in either calculating the image size or reading the data.

Honestly, if you're trying to write your own image loader, you should start by reading the file format spec, and then actually write your own code instead of copying something else. Or if that sounds like a lot of reinventing the wheel, don't write your own image loader. Find a library that does what you need and has been proven in other people's games, and use that instead.

My understanding of that is that Present blocks until the GPU is done, so you're just wasting CPU cycles if you call it back to back with EndScene.

I once tried to change things up so I called Present just before BeginScene instead of just after EndScene. It caused problems on the first frame (obviously, and would have been easy to fix) but also didn't noticeably improve performance. Perhaps I'm just too CPU-bound for it to matter.

Bumping this to say thanks to everyone who recommended Audiere.  

I haven't dug deep into it yet to see if it could replace FMOD for my big projects, but I just followed the incredibly brief tutorial--for getting WAVs and OGGs playing quickly in small projects, it is AMAZING. (Especially because I briefly checked out XAudio2 first, and that is a typically monolithic Microsoft library which nevertheless expects you to parse wave files yourself and give it raw chunks of data. Ha.)

Code:

#include "stdio.h" // really, i don't know why i do that instead of <>

I think it's compiler-dependent, but the quote and pointy bracket forms can actually mean different things. In VC++, quoted includes means to look locally for the file first, then look in other include directories if the file wasn't found; and brackets means to look in include directories immediately instead.

So I tend to do:

Code:

#include "me.h" // This is a header I wrote, so I put it in quotes

// (Whitespace to separate my headers from standard C/C++ libraries)

#include <stdio.h> // This is a standard library header, so I put it in brackets

I've heard it said that standard library headers should be included first, but I can't imagine a compelling reason to do that.

I like the post counts, but it wouldn't break my heart to see them go. I do consciously evaluate posts based on the author's post count, which is probably not a great thing to do.

Edit: postcount++

I never really understood the whole quitting your job to make games thing.

This. Perhaps if I made one successful game first, I might consider using the earnings to fund a second game and so forth, but unless that happens, indieness is a hobby for someone like me. Doing it this way lets me enjoy making indie games, because I'm not concerned with fame or glory or having ramen to eat next month. It's simply fun to learn and develop. It still bothers me when I hit a dry spell in motivation or creativity, but not because my livelihood depends on the game's success.

But that's probably not super helpful if you are pursuing a career in indie games. What I do when I'm not feeling especially motivated is to relax and try to find inspiration elsewhere. I can't force myself to care about my game if I don't; I've wasted hours staring at VS or Blender or the game itself, trying to will myself to care, and it never works. Instead, I'll put the game aside and do something else. I'll play games: new games I haven't gotten around to yet, or old favorites, or things I might usually ignore but decide to check out because it can't possibly hurt (e.g. anything with "Cabela's" in the title). I'll watch movies. I love movies. I often forget how much I love movies because I spend all my time thinking about games. I'll read technical whitepapers. I'll listen to music (though I do that all the time anyway). I might even read a book once in a while. And somewhere in there, I'll usually see or hear something that inspires me, something that I'll wish I had thought of, something that makes me want to create something. And I bring that energy back to the game, and carry on.

Good luck!

I think you just need to dereference your iterator:

Code:

(*i)->Run();

But I haven't used STL vecs in quite a while so if I'm wrong, feel free to call me on it. 

Hey guys, help a bot out.

Code:

unsigned long long start_cpu_cnt()
{
    // Approximation of the CPU time stamp counter
    return 0;
}

unsigned long long stop_cpu_cnt()
{
    // Approximation of the CPU time stamp counter
    return 0;
}

double cnt_to_time( unsigned long long start, unsigned long long stop, char resolution )
{
    double time = (double)( stop - start ); // Approximately in nanoseconds
    if( resolution < 2 )
    {
        time *= 1000.0;
    }
    if( resolution < 1 )
    {
        time *= 1000.0;
    }
    return time;
}

For starters, if you're only exporting the base pose, your bone matrices should all be identity matrices (because you expect the mesh to look exactly the same as it does when you're not using the bones, so there shouldn't be any actual transformation happening). So I'd start from there: take a look at each matrix and see how it is different from identity. Hopefully that will tell you something useful; perhaps you need to transform each matrix by its parent bone space, or perhaps Blender uses a different coordinate system, or something.

I package everything into a single file with a custom format. It's a pretty basic format: a header, a table of file entries (filenames and offsets), and then a big old blob of file data. Most of the files in the blob are compressed with zlib, except for music files, which I just copy straight in so that they can be streamed directly from the package file.

At runtime, I initialize the game from a single package file. File requests are first looked up in this package, then on disk if they're not in the package. I might change this system at some point to let me use multiple package files in some given order, but I don't really have a reason yet. It would be useful for patching or modding a game, but not otherwise.

I considered writing a custom world editor but ended up being able to do almost everything I need with Blender (by using the arbitrary key-value properties as object metadata).

I've written a lot of intermediate tools: a mesh exporter and world exporter for Blender, both of which emit XML files; mesh and world compilers to convert those XML files into a more compact, engine-ready binary format; a global illumination solver to run as a post step on the binary world; a configuration compiler to build binary files from INI-like text config files. But those are all command-line tools, so they have no UIs. (They're also all hooked into my automated bake script so I don't have to remember the command-line formats or ever type them by hand.)

I wrote all those tools myself because they are specific to my engine. It's not something that could easily be generalized--I typically modify the exporter, compiler, and engine in tandem when I need to introduce new features. That said, most people have generally similar needs for things like meshes, and the only aspects that are likely to change are things like the ordering of the data or the size of indices. So a general-purpose tool would just need to be configurable to support each user's slightly different needs for the same common functionality. For example, I could replace my mesh pipeline with a tool that exports from a Blender scene into my custom binary format according to a definition file. Or better yet, it could be a tool that compiles an established standard like COLLADA into a defined binary form. That way, an artist could use any modeling tool that already has a COLLADA exporter, then run this tool and get a game-ready asset out of it.

Frankly, I think games should share more code. There's astoundingly few "logic" libraries, which is the bit truly exchangable between platforms and setups.

It's also (by necessity) the most malleable bit of an engine, so I think we'd gain relatively little by sharing. A high-level entity system could be useful, but actual game logic seems too specific. That's the part that I'm most likely to rewrite between my own projects, whereas core libraries and the renderer and such will remain untouched.

CUTIE
an art game.

by david pittman



Get it at: http://www.dphrygian.com/bin/Cutie.zip

Or, you know, don't. But the charade just wouldn't be complete if I didn't announce it. With sincere apologies to art game people.

Woo, just finished playing this! By which I mean I completed the levels but didn't get nearly all the trinkets yet. I tried Doing Things The Hard Way for a few minutes and called it quits after the first time I finally made it to the top. I'll ehhhhh come back to that one.

That one part halfway up The Final Challenge where you have to bounce around the room clockwise nearly got the best of me. I died 143 times there. But I made it!

Terry and Magnus, you guys did a great job on this.

Edit: oh yeah I'm awesome

I don't understand why graphics APIs have to be a holy war. Use the one that makes sense for you--the end user shouldn't know or care what you're using. (To be fair, Microsoft does market new DirectX versions specifically to make end users care, but that's mostly misinformation and we shouldn't play into that game.) If you're doing cross-platform development, use OpenGL; or better yet, abstract your renderer and implement both GL and D3D on Windows. There's no better way to honestly compare the two than to implement every feature of your renderer in both APIs.

The Essential Blender book is available free at http://wiki.blender.org/index.php/Doc:Books/Essential_Blender. The first four chapters are a pretty good place to get familiar with the interface and low-poly modeling.

The best* solution is to do a sweep test to avoid "phasing" through geometry at high speeds. Here's some pictures!



So you've got a guy moving with some velocity, and you've got some tiles. If you move the character by this velocity (multiplied by delta time) and test for collision at the end point, you'll end up here:



The guy is not colliding with any tiles here, so the move is considered valid. But look at the actual path of the character:



The lower right corner of his bounding box clearly cuts through the tile on this path. The actual point of collision is shown here:



So how do we test for this? Subdividing the movement vector and testing for collision at smaller intervals isn't a completely terrible choice, but it can't catch every case. Then you have to find an acceptable balance between allowing some edge cases or doing a ridiculous number of tests, and that can get expensive. There's a better way.

The next image is effectively the same initial scenario as the first image I posted, but I've reduced the character to a single point and expanded the world by the guy's dimensions (making a Minkowski sum, or difference, or something, of their geometries).



Now you can just find the exact point of intersection of the movement vector with the expanded world (with ray-triangle or ray-AABB tests). That will eventually locate this point:



And conveniently, that small offset from the starting point to the point of intersection is exactly the same as the distance the guy can move before he collides with that tile; so move him that far and you're done!

*This is the best solution in my experience, anyway. But really, whatever gets the job done efficiently and without bugs is the best for any game.

Have you stepped through the execution and confirmed that the file is actually being opened? Because it really does sound like it's just a working directory problem.

I too am curious if people have succeeded with this (although I assume most scripting languages have some way to do this because the sanest way to handle basic system libraries is handing them off to the default C implementations).

I wanted to do this Python once, and it seems to be not too different from Lua (except for needing to link with the Python interpreter), from a glance at the documentation and example. But I can't actually recommend it because I ended up deciding I didn't really need a scripting language and never tried it out.