With a library as common as OpenAL, you're probably much better off just stating it as a dependency and letting the user install their own via their package manager.

As a Linux user I hate it when programs ship their own libraries, but tastes will vary.

also, superior technologies don't always win out, sometimes inferior ones can win due to other factors. one classic example of this is VHS vs 8-track,

You may want to check your facts before using them to support your argument.  8-track has nothing to do with VHS.  8-track was the predecessor to the audio cassette tape.  VHS competed with Sony's Betamax format.

i wanted to buy this immediately based on the description alone! what is your concept for the unit art? im hoping to see some depraved yet brightly colored plasticy looking fast-food mascots or something, haha

I personally always envisioned things looking a lot like Tiberian Sun, but I don't really know at this point how they will end up.

Not much to report this week.  Still doing a test playthrough of all the single player maps, and fixing various AI issues along the way.

My graphics guy got his new computer, so hopefully I'll have something more interesting to post next week,

The usual download links:

Linux x86
Mac OS X (Intel only)
Windows

The one thing that seems to be common in all of those lines in NULL.  Definitions of NULL can be really funny, sometimes headers feel like declaring their own versions.

Try replacing all of the NULLs with 0 and see if that helps.

I have a related question. My application SEEMS to sync to vblank when using glXSwapInterval(1) (or when letting the driver decide) but even though it runs consistently at 60 fps the buffer swap isn't perfectly synced with the vertical retrace which results in the screen torn vertically always at the same height. I have to disable the vsync with glXSwapInterval(0) to achieve higher framerates (300+) and get rid of the tearing.
Anyone experienced something like this before?

I had that issue back when I was using get_video_sync/wait_video_sync but it went away when I switched to glXSwapInterval.  I had always assumed it might have something to do with the fact that I use a KVM switch, but I never proved anything conclusively.

i like how you streamline the movement by autoselecting the next avaliable unit.

That isn't actually what's going on, although it's hard to see it until you play a map with enemies on it.  All units go into a global initiative pool, there is a specific order that they move in.  If you've ever played any of the Shining Force games, it's the same idea.

one gripe i had was the readability of some of the features, specifically the potato mines.  on the first training mission i was confused for a few turns because i thought i had occupied all mines, but missed two becaues they were hard to notice. *edit* i see that you are currently working on overhauling the graphics

Yeah, the graphics are very much in flux right now.  We're concentrating on getting placeholders and all of the relevant code done, then prettying things up.


This week was really just more bug fixes and stage testing.  My graphics guy's computer is still down, so no advancement on that front.

The usual download links:

Linux x86
Mac OS X (Intel only)
Windows

Not a lot to talk about this week apart from some bugfixes and new shortcut command, you can now issue a hold order to a unit by double-clicking it.

My graphics guy's computer died this week and he won't be getting a replacement until sometime next week at the earliest, so the modelling work has taken a slight setback.

The usual download links:

Linux x86
Mac OS X (Intel only)
Windows

you can't honestly call something the most powerful/free language of all time, of all time. (unless the only other language you're familiar with is Java or something)

Programming languages are formally specified constructs with well understood and analyzable properties.   It is absolutely reasonable to claim that there is a 'best' programming language (proving which one it is may be prohibitively difficult, however).  Programming language theory is widely studied branch of computer science that deals with exactly that.

I wouldn't go so far to claim that C++ is it, as the resident Ada fanboy I have to point out that Ada is roughly of the same size and complexity of C++, and is in my opinion a better language for game programming.

And then you just want to kill the guys who designed the compilation process.

That would be Dennis Ritchie, and he's already dead.

I've been saying for years that the biggest problem with C++ is that it inherited C's compilation model.  This worked OK until templates and inline functions were introduced.  I just hope that whatever new system the C++ committee introduces still allows something like header files.  Header-less languages like Java make me want to shoot myself.

Shouldn't a lock/mutex or something like that prevent this?

Yes, it should.  The code the deallocates the AI players operates in a locked context.  The AI players themselves each maintain their own copy of the game state, so they shouldn't be touching anything.

The really odd thing is that the exception is being generated on the main thread, and it isn't coming directly from the thread termination code, since I set up an exception handler there too.

I hate it when the only solution I can find to a problem is terrible.

The AI players in my game each operate on their own thread.  When shutting down the thread, if the AI player is currently "thinking" I get an exception.  I can't find any way to prevent this exception.  The only way I have to get around it is to handle the exception, then try shutting down the AI player a second time.  So far, it seems to be working, but I really don't like it.

What's the exception?

It's a Program_Error, which is one of the predefined Ada exceptions.  It claims it's because the code is trying to iterate through a container twice simultaneously, but the code in question is doing nothing but aborting a thread.

I hate it when the only solution I can find to a problem is terrible.

The AI players in my game each operate on their own thread.  When shutting down the thread, if the AI player is currently "thinking" I get an exception.  I can't find any way to prevent this exception.  The only way I have to get around it is to handle the exception, then try shutting down the AI player a second time.  So far, it seems to be working, but I really don't like it.

We got some primitive resource models in place now, but the shaders aren't ready yet, so they're very difficult to discern.  Hopefully we can get them looking better this week.

Most importantly, the resource drawing system is completely in place now, so that's one less thing to worry about.

Also a number of minor bug fixes this week.  I've been playing through the single player campaigns and timing them.  I got through the first one in a little over 10 hours.  Since this is the campaign that I plan to release as the demo, I think this is a good number.  I can realistically estimate a total single player time of at least 40 hours.

The usual download links:

Linux x86
Mac OS X (Intel only)
Windows

[new]

You can do variable length stack arrays in c++ with alloca() if you really want to, I've done it a few times before to avoid massive amounts of memory allocation/deallocations.

alloca() isn't standard.  It also causes problems in C++ because you won't get proper execution of constructors and destructors.

You would be much better off writing a custom memory pool object and overloading new and delete to use it for those scenarios.

I kept getting these really odd memory related crashes in my game, and I spent months trying to figure out what was happening.  Based on some prior experiences I had, I was about 85% certain that I was actually suffering from a bug in the compiler I was using.

Changed to a different fork last week, and since then haven't any problems.  Not proof that I was right, of course, but I still feel confident that the crashes weren't my fault, and that makes me happy.

Code:

void funk(int size)
{
    int array[size];
}

I once did this by accident and was surprised it worked, because I'm pretty sure that at the university they taught us that in C all arrays must have constant length known at compile time.

Now I'm surprised it doesn't work in C++ although I never tried it.

This feature was added in C99.  In C89 and C++, all array sizes must be a compile-time constant.

C has quite a few things that C++ doesn't have either.  Variable length arrays (generally better performance than std::vector, since they're usually stack allocated rather than heap allocated)

Wut?

C can do this:

Code:

void funk(int size)
{
    int array[size];
}

This is better than std::vector because:

The array is allocated as part of the function's stack frame, which means that no heap resources need to be located and consumed.  std::vector relies on new/malloc by default.  It may be possible to define a stack based allocator for your vector, but I've never seen this done.

The array is deallocated along with the rest of the stack frame, so it's just popped off with everything else, giving you zero cost deallocation.

The array can be better optimized, since its base address is usually known at compile time.  std::vector's internal base address is never known until runtime.

On the other hand std::vector can be resized at runtime, so it has more flexibility.

If you think about it most of C++ is just syntactic sugar. You don't need C++'s syntax support to fully work in the OO paradigm.

I find that thinking of C++ as syntactic sugar for C helps to increase understanding of it a great deal.

That said, C has been rather left in the dust, there's a lot of things that C++ supports that C has not been updated for. Templates, references, etc. Depending on how brave/stubborn you are this may be good or bad.

C has quite a few things that C++ doesn't have either.  Variable length arrays (generally better performance than std::vector, since they're usually stack allocated rather than heap allocated), a native complex number type, restrict pointers, size guarantees for array parameters to functions, and a few other things.

C++ really hasn't left C "in the dust," the two languages have simply evolved in different directions.

So uh, allowing a user to choose a windowed display mode and but then restricting their inputs to only be able to affect the program (save for alt-tab or other such obscure keyboard interrupts) is totally not a game programmer attitude of owning the system but doing the same thing while making the application full-screen is?

I never said I did that.  The choice to capture the mouse or not is also a user option.

If you can't task switch without alt-tabbing (not something all users know how to do), what's the point of making it run windowed?

The point for me is that I'm providing options to the user, and it isn't my business to tell them how they can and can't run my game.

There seems to be this attitude among game programmers that they practically own the user's system and should be able to dictate every detail of how their program is run.  I see terms like "immersion" thrown around.  What if I don't want to be "immersed" in your game?  What if I want to run it side-by-side with my email client because I'm waiting for an important message and using your game to kill time?  Modern PCs are designed for multi-tasking.  Let the user do it.  If the user wants to run fullscreen, then they will.

Not to mention that it also helps enormously with debugging.  My current game has network support, and being able to run three or four instances at once to test network code is hugely convenient, as is being able to shove a copy off to the side in a little 20x20 window while it runs some tests.