Object ownership

Ogre3D's object ownership policies are really getting on my nerves ...
Maybe I just skipped the wrong piece of documentation, but being rewarded with a segfault kind of sucks ...



Edit: this post on the ogre forums says it all... why, oh why didn't I see this on the documentation? I was expecting to see it somewhere around here

Posted at at 11:21 PM on Monday, June 23, 2008 by Posted by Rui Pires | 0 comments   | Filed under:

Getting back to Ogre3D

It's been a while since I've used this.
Setting up the Ogre3D SDK is always a tough job, so I decided not to get all smarty-pantsy and to just install 1.4.5 from ubuntu's repositores (instead of 1.4.8 from svn ...).
Well, now it's working, and now I'm going to take some time to get to know this sucker a little better than I did last time!


Ogre3D

Posted at at 10:08 PM on Tuesday, June 17, 2008 by Posted by Rui Pires | 0 comments   | Filed under:

OpenAL and error handling

I'm writing a thin wrapper for OpenAL that only does some basic checking after doing some work.
After writing a few modifier/inspector methods, one thing is impossible to miss. The error handling mechanism in OpenAL is not exactly the most user (in this case user-programmer) friendly.

OpenAL was designed as a C library (which I fully support, although I would like an official C++ wrapper, so that there was no need to reinvent the wheel). After that decision, using C++ exceptions was really not an option anymore. So they were left with returning NULL/an error code or going the errno way. Set an error code and leave it up to the user-programmer to poll it.

Why, oh why did they not put a return code in every function so that one would now when to poll for errors ? Oh no, just return void and force the poor programmer to poll for errors after every call.
Now that hardly seems efficient ... Maybe if I was using OpenAL directly, I could do the error checking after a block of OpenAL instructions ...

My options now ?
1 - check for errors after every OpenAL call (at least the ones with no return code)
2 - implement some mechanism to check for errors at appropriate times (a sentry class? a simple function?)

I'm following Donald Knuth's advice and keep optimization to a later stage.
After all, that's what profilers are for.

Posted at at 10:17 PM on Wednesday, June 11, 2008 by Posted by Rui Pires | 0 comments   | Filed under:

OpenAL up and running

Well, not quite yet, but I managed to play a wav file wohoo!!!

...It's about time! I'm getting rusty at this stuff!
The problem was all mine (as usual when coding alone ;) )
And I was blamming ubuntu for it! Shame on me :(

Now I'm just going to create a thin wrapper around openal so that I can make it a little bit more object oriented. And also error safe. I'll check for errors after each method call and launch a nice descriptive exception when something fails.

Posted at at 11:58 PM on Friday, June 06, 2008 by Posted by Rui Pires | 0 comments   | Filed under:

Havok is free

At least for non-commercial use.
The announcement is here (via gamedev.net).

Thank you Intel!

I hope pal takes advantage of this ;)

update:
I guess pal support for havok is confirmed and will take about 3 weeks...
Thank you adrian!

Posted at at 10:22 AM on Tuesday, June 03, 2008 by Posted by Rui Pires | 0 comments   | Filed under:

OpenAL in Ubuntu

I still didn't get this to work :(

alcGetString (NULL, ALC_DEVICE_SPECIFIER)
always returns NULL.
My problem is similar to this, except in my case it's not for capture, but for output.
I'm hoping this is related to this bug (that didn't get corrected for Hardy Heron).
Let's see ...

Posted at at 10:02 AM on by Posted by Rui Pires | 0 comments   | Filed under:

OpenAL does not like me

It seems either I'm doing something wrong, or OpenAL does not like me and does not want to work on my default sound device.
I guess I need to read the manual again ... :(

Posted at at 10:12 PM on Monday, June 02, 2008 by Posted by Rui Pires | 0 comments   | Filed under: