Irrlicht Engine

I haven't started using Irrlicht just yet but I've done a lot of "research" into it. I'm wondering if I should get started on my game now, or wait for the next version to come up. Will updating irrlicht in the middle of the project be easy? I'm planning on using Newton, fmod, and ICE, so I'm hoping it won't cause incompatibility issues...

Also, my project needs some kind of saving (either saving the entire scene, or just saving certain things like health and inventory), which doesn't seem to be included right now, but is planned for the next version.

I also have a few unrelated questions: dynamically animating characters' bones and such (for example, programming the leg movements of a giant spider walking on uneven ground) will be pretty important - that's fully supported in Newton, right? And second: is there a good way to treat the screen output as a big 2D array (for example, for every frame could I render it, then take every pixel and divide each blue value by 2 before displaying it) without significant slowdown?

Thanks to anyone who can answer my newbish questions =]

first question: I don't think there will be dramatical changes in each version, but looking at the files distibution, about next month a new version will come out. I don't know what your termine is, but you might want to wait for new functions

last: might want to look at screen filters? just returning the screen itself to the software will be rather slow and incompatible

I don't know what you exactly mean with the saving part. please explain that in a different way

First of all irrlicht is a rendering engine not a game engine....
So there won't be any saving or loading functions in new versions!!!!!
And about the newton stuff...go to their forum. it's totaly independet of irrlicht!!
And ICE is a framework to make game development easier so u have to go with the irrlicht version they are using.

Ohh and ur color changing thing.....use a shader!!! there is a tut in the tutorial section of this page that shows how to use and implement them.

Sudi is right. Irrlicht is a graphic engine. About versions, there's not much trouble porting from one version to the other so on the graphic side you won't have much trouble updating.

About the saving, in the development todo-list page, it has:
"Scene serialization - 0% - Planned - Reads and writes scenes from and to disk via XML"
It sounds like that might be a simulator (or game) save/load type thing, but maybe not. That's ok then. What I meant by "saving" was like the save/load system in many FPSs, where you can save at any time, and load that exact same state (that would be the best-case scenario).

Until now I wasn't quite sure what shaders are, looks like that would work. I was thinking of adding some interesting effects: near-white areas are converted to randomly changing colours (if I can change the shader every frame that would work). Simulate iris shrinking and growing (sampling a bunch of pixels few pixels every second or so to see how the iris should shrink/grow, then change shader accordingly). And possibly even adding a small amount of "noise" to very dark areas. I'll figure that out later then =]

For Newton and ICE, I'll just play around with those (and use tutorials of course), that should sort everything else out. Thanks!

Ok, scene serialization is in between the two possibilities found in your posts. Since Irrlicht is no game engine it will not know about game state. Thus, game saving cannot be implemented with just this serialization. But it will definitely help! Niko has developed a scene editor, thus the scene serialization will be part of this software - and become part of Irrlicht sooner or later. But due to his blog it is not yet finished.

Shaders will be the best choice in ur case.
But with saving and stuff u should think about a file format that will hold the player data and the position of all ur objects....right now i'm having the same problem with my game i thought about something like this:

Header:
Levelname;
Playername; //if needed
//some other global value that could be important

Player:
Health; //Since ur game is an FPS u probably won't need more values

Inventory:
//Maybe a bool value for each weopon so u know if the player had the gun
//and then maybe a number to save the ammo amount of it

ObjectsHeader:
Number of Objects: //So you know how many objects will follow
//Oh and u only save objects that are in the level the player is currently in
//Defined in the header

Object:
//maybe
Position;
Rotation;
State;

Oh and u should save all this in a binary file. First of all it will be small and secondary the player can't change the values otherwise it would be to easy for him to cheat.

I don't think that "security by obsucrity" is the way to go. I have several binary editors here which allow me to patch most binary file formats. And at least the ammunition will be easily recognized by saving two files with just one shot difference. In the late eighties we even had hardware for such cheating things (some rom modules for the C64 )
You would have to use some encryption for this to make it at least a little more secure. Or just use a hash value over all these values combined with a secret value from inside your program. That way you can store all information in plain text and need not bother with bit fiddling. Then, you could even allow to exchange save files between games, and even change some parts of the files in plain text (e.g. XML) such as player names to customize the save files.

Heh, getting a bit ahead of ourselves =p But definately encryption is something that would be good (if not essential later).

I think what I'll do is make a practice game first, and then start a big one when a new Irrlicht comes out. That choice didn't seem to appealing to me a little while ago, but now I've got cold feet (and I haven't even downloaded irrlicht yet)

@hybrid
I know u can just patch binarys but hey u always can cheat and this way the player has to do something to cheat and not only to power up his wordpad....
U shouldn't worry about encryption in ur first realese......

In my opinion, There is no true way to prevent cheating, so why try. I think the binary format is enough. If someone wants to cheat, it is their loss anyway since they didn't get to play the game right.