Irrlicht removal progress: part 2

It's been slow replacing the whole graphics engine, but I'm nearly finished now. I've found dozens of additional bugs in the process, so everything will be running even more smoothly in the future. Plus the rendering speed is now a bit faster in several key areas, particle rendering and floor rendering in particular.

Sadly I couldn't find a good alternative for the text box used in Irrlicht. I resorted to using the default DirectX text box, which doesn't have multi-lining - I'm going to have to come up with some ideas for the conversation editor which was the only place where multi-line editing is a requirement.

Oh, and I don't remember showing you this fancy automatic shadow system I implemented! It's an on/off toggle button in each object's graphics edit screen, it renders the same sprites in transparent black.

Since working on the low level code is so boring I've been thinking about the actual world and the framework for the gameplay. Anne says I've got to sleep today, so I'll talk about that next time.

Irrlicht removal progress

For the past couple of weeks I've been removing our graphics engine Irrlicht and replacing it with DirectX 9. Well actually for the past week I've been too sick to really code, but nevermind that, I'm back in the wheel!

Here's a shot of the menu, it's the part I've been working on most and it looks pretty much the same as before.

The difficult part is coming next, replacing the text edit box. These are a notorious bane of all programmers who cannot use the default operating system edit boxes. A simple multiline box where you can write can be suprisingly complex to program. Most users have already used some windows text editor, so they're expecting the same functionality. If any of you know of a good edit box I can drop into Driftmoon, do tell.

Oldies part 2: Bikez 1

So this Pharaoh from Egypt comes to me and says: "Love your Bikez 2 game, but I have a kinda stupid question - was there any Bikez 1 game? It bugs me and my friends " Well, Ramzes and friends, you're in luck, because it's time for part 2 of our oldies list.

Bikez 1 was a GTA 1/2 style top-down deathmatch for two players split screen style. There was a level editor, a shop for choosing from a dozen or so weapons, and more importantly, you could shoot the civilians.

Sadly time has not been so kind on Bikez 1, as the transparency function doesn't work on any modern hardware. You can download it, but be warned, it's in Finnish! And if you see the pink borders on everything, it's not playable.

I somehow managed to make Magebane 1 without ever learning to use things like arrays, for loops, while loops, or even any kind of structures. This time I had used actual DirectX, and most of the code that actually worked came from DirectDraw example code. I still have no idea how the whole thing took 7000 lines of code, whereas the simplistic game I do at work goes well into 200 000 and counting.

Bikez 1 was probably my least downloaded game. At first I released it as shareware, but sadly I really didn't know how to use the internet to sell it. Later on in 2004 I released it as freeware, but I could never really get it working with modern hardware. Surprisingly it seems to work fine on my Windows 7 right now.

I'm still hoping to do another split screen game someday. Now that I have a wife I can force to play with me, it should be much easier than in 1999, when I had to wait for my brother to come and play with me.

I'm really hoping someone asks of The Forge next, so we can do this chronologically.

Reinvent the wheel!

This is a technical rant, so be warned. I'm reinventing the wheel. I'm systematically replacing all of other people's code with code of my own. Here's why:

In 2005 I wanted to make a cutting edge indie game engine for my next game. I wanted to compose my engine of different parts, thinking that somehow that would speed things up. I didn't want to reinvent the wheel, obviously. I chose Irrlicht for graphics, Newton Dynamics for physics, RakNet for networking, Angelscript for scripting, and Audiere for sound.

Choosing to use good existing libraries was a good choise wasn't it? It would speed up development, I could start using those sounds and physics and whatnot straight out of the box. As the libraries were updated, my code would become better with no effort on my part. All I had to do was combine the well designed interfaces. Naive thinking.

No library is perfectly suited for the task you have. You're better off writing the code yourself.

1. The library doesn't have all the features you need, and it never will. If the library you want to use is missing a feature, it will never be there. The maintainer's may tell they're hard at work implementing it. But it will never get in there. If you really need that feature you can't depend on promises. Real life can get in the way, other features can get in the way. It's a risk you don't want to take if you really need a feature. I waited four years for Vertex Buffer support in Irrlicht. It got there in the end, but not the way I wanted.
2. The library won't suit your needs after all. Newton Dynamics couldn't support the amount of physics objects Driftmoon deals with, mainly because it was a 3D physics library. Turns out I wanted a 2D physics library instead of 3D.
3. Updating the library will break your software. In the beginning Angelscript had a lot of bugs, it was just getting started after all. But each time it was updated, some of the interface changed, requiring extensive code changes. There's no telling what an update of a library does, maybe it fixes something and adds features, maybe it adds some very clever bugs, requires a complete rewrite of your own code, and removes just the feature you needed.
4. There will be hard to track crashes and bugs. Audiere crashed the whole game at random intervals (see earlier post about sound libraries). The reality is that a library will have bugs in it, and you may never know whether the problem is in the way you're using the library or within the library. Right now my Irrlicht text rendering becomes crawling slow at some random point in the game. I have no idea what's causing it, maybe it's a bug in Irrlicht, maybe I've done something wrong.
5. The library interface will suck. Newton Dynamics wanted you to build your code around it. You didn't tell it that your object had this physics representation, it told you that I've got your physics right here, you can add your object to that. You shouldn't be forced to structure your code to suit a library, but that's often the way it goes.
6. The library will be bloated. So maybe the library has all the features you need, and then some. I wanted to use OGRE graphics library at some point, but turns out the library would have taken ten times the space my code did. The space is less of a problem these days, but you'll have to think forward to the day you need to debug the library. Can you find the code paths you're using in the mess of code? Can you add the feature you need if you can't understand what the thousands of source files do?
7. The library maintainer will abandon the project. You find a huge bug in the library, what do you do? Fix it? No, you point it out to the library maintainer. Maybe he's lost his interest, got fired, or maybe the company is bankrupt even though you've got paid support.  So what do you do? If you're lucky you've got the code so you can fix it yourself, which brings me to the next point.
8. You will not be able to fix any of the bugs in the library. Chances are the maintainer isn't interested in your bug reports, and  you're the only person on the planet still using the library - you'll have to fix the bugs yourself. But you can't understand advanced physics/networking/graphics, that's the whole reason you used the library in the first place!

Notrium bugfixes

All of the bugs already existed in the vanilla 2005 version, but thanks to improvements in compiler technology we're now getting hard crashes for these instead of random behaviour. This enables me to find the problems and fix them. If you're getting any crashes, please comment here so I can fix it.

If you're working on a mod for Notrium, I encourage you to use this latest version. If you're now getting crashes and didn't previously, just tell me and I'll get it fixed.

PS. Thank you everyone who submitted bug reports! Special thanks  to Tschmopp who found out interesting crashes in various mods.