I was doing some work on an XInput extension for Ruby, and after making some changes I stopped getting controller input data. I had a look, and somehow I’d done this :

XINPUT_STATE state;
if( SUCCEEDED( controllerIndex, &state ) )
{
...
}

Instead of:

XINPUT_STATE state;
if( SUCCEEDED( XInputGetState( controllerIndex, &state ) ) )
{
...
}

Of course, SUCCEEDED was perfectly happy with this, since the following is perfectly valid code. Unusual, but valid.

XINPUT_STATE state;
if( ((HRESULT)(controllerIndex, &state)) >= 0 )
{
...
}

Evil.

While working on my super secret project, I’ve made some improvements to Lardfish. The main improvement is the addition of saving and loading to and from memory, which is useful for packed files (which my secret project uses). I initially though that it would be complicated, but since Lardfish::Internal::InternalLoad and  Lardfish::Internal::InternalSave already used std::ifstream and std::ofstream, I was able to change them to use std::istream and std::ostream, and then used a stringstream to load the data in and save it out. It basically meant that I had to change very little code to add the feature.

The files on the website have not been updated yet, but I will do that asap.

Most of my time is being spent on the secret project, and work for WorldWeaver, which is why there hasn’t been any updates recently. I will try and update more often. Not that anyone (other than bots) read, heh.

Somehow I’ve managed to not get around to updating the site for nearly a month. I’ve been busy at work with the DXMesh API, I keep having to go places at weekends. Anyway, in the last month I’ve updated Lardfish to use exceptions, to make it load from files safely. It can now handle incorrect file types, broken files and the like. Overall it seems quite hard to break, which is good.

At some point I may change the Lardfish format to allow for larger files ( > 2^32 bytes ). It would mean changing it to use 64 bit offsets into the data blocks. Also will need to look at streaming the file in, or loading and unloading based on access. At present it loads it all into a block. With larger files this may use a lot of memory. Ideally it would only store the beginning parts, and transparently load data as requested.

On the GFR2 front, not a lot has happened, as I’ve been a bit lazy. I have however solved the random flickering issue with updating text. Apparently I had a Begin/End scene in there for some reason ( oops ) which was causing a jump.

On the todo list is converting Radnom::IRXSprite plugin to use Lardfish, and updating the Lardfish download on the site, which I will do soon.

I’ve been a bit busy at work in the last 2 weeks, with all the import/export stuff, and now the mesh splitter. Also, my internet at home has been cut back to 70K again (thanks Virgin), which is why I’ve not posted until now.

I’ve improved Lardfish slightly, adding some exceptions for bad files, things like that, which is clearly better than just crashing or reading random data. I decided to use exceptions as opposed to error codes because then the user cannot ignore them. Well, they can just wrap it in a try catch block and catch everything, but then that’s their problem.

I’ve also worked on the editor for GFR2, which is coming along now. I have decided to reorganise the Editor/Main Game relationship though, which should be done sometime this week.

I added the first version of Lardfish here. I will probably add a new version soon, since this version  didn’t take very long to do, and has some points that can be improved on.

Lots of programming languages have local functions – however they are illegal in C++. They can be simulated though by using a local struct and overloading its operator(), like this :

int main()
{
	struct LocalFunction
	{
		void operator()(int a)
		{
			printf("Number : %d\n", a);
		}
	};
	LocalFunction function;
	function(1);
	return 0;
}

If you dont like the look of that, add some #defines :

#ifndef BeginLocalFunction
#define BeginLocalFunction(ret,name) struct __##name { ret operator()
#endif

#ifndef EndLocalFunction
#define EndLocalFunction(name) }; __##name name;
#endif

int main()
{
	BeginLocalFunction(void, Flibble)(int a)
	{
		printf("What are arms %d\n", a);
	}
	EndLocalFunction(Flibble);

	printf("Local function sample\n");
	Flibble(3);
	return 0;
}

There are probably a lot of things that can be improved, and its pretty basic. Its probably also been done before, and done better in boost somewhere. But it was fun to mess around with anyway.

This week I’ve been continuing work on GFR2. I updated the collisions so they were slightly more sophisticated than the version that I managed to get in in about 30 minutes when I first made the game, and added some new gameplay elements that I think turned out quite well.

While working on GFR2 I of course found faults with Radnom that needed to be fixed. One of which was the overall structure of the whole thing. A small fault then. As it was, every plugin was registered with RadnomCore, which you could request module instances from. This was fine, but getting plugin instances from sources that were definitely going to be there was a bit long winded, and involved finding the plugin, calling the creator, returning the instance, casting to the type.

I decided to completely remove RadnomCore and ditch the whole plugins thing for now, since most components of Radnom are actually just mini projects built as DLLs. At some point I’ll create a plugin manager DLL which will do the same as RadnomCore, but for now I’m just going to call functions directly in the DLL.

I also started changing all the Radnom components from raw pointers to tr1::shared_ptr, something I should have done (and wanted to do – I couldn’t because I had a different VS version on laptop) from the start. For each module, a shared and weak pointer type is available. Makes things a lot easier, since I don’t have to care about when things get deleted now. One thing I did have to take into account was where the pointer was being deleted – I had to make sure that it was in the same place (EXE vs DLL) as the allocation, but tr1::shared_ptr provides a constructor which you can pass a deletion function to.

I finally got round to setting up version control too, so I can actually work on laptop and pc without endless copy pasting over the network.

I’ll be working on the characters and the UI in GFR2, and hope to have character creation done soon – if all goes well it will be quite good.

On a side note, the local shop is offering 6 double dip for 50p. Great Justice.

This week I’ve been looking at integrating Javascript into GFR2 for the user interface and game logic, as part of my project to upgrade GFR2. I’m using Google’s v8 Javascript engine, since it is reportedly quite fast, which is good – don’t want the JS holding up the UI.

I chose Javascript over other languages as im fed up with abusing Lua and doing everything wrong with it, and the embedding for v8 was comparitively simple – after a short time I got every Javascript feature I needed working with the C++ in GFR2, compared to Lua where I never actually got it all working.

Embedding v8 itself was quite nice, although I had to use a custom tool to build it, which eventually created a 70MB .lib file. Anyway, the actual structure is organised and not completely full of hacks (hurray). Hopefully by the end of next week I will have got a lot of the GFR2 logic and ui reimplemented in JS, and can continue making the game better.

Also, the base of tomorrow is nearly secured.