Eihort Slippage

· by Steve · Read in about 4 min · (724 Words)

Well, I’ve been busting a gut trying to get everything sorted for Eihort but it’s still slipping. I spent almost all of last week processing patches that had been queued up for it, and in some cases ended up either rewriting or making significant changes or extensions to them. My current work item is to do with GLSL - whilst I’d already improved things for GLSL recently, what with the unified program definitions and some array work, there are still some issues with supporting auto-bound arrays due to the fact that in GLSL, vertex and fragment programs require linking together before you can grab parameters out of them. So far that’s been coped with by auto-adding parameters and then resolving it later, but that has problems with automatically bound arrays because there is often not enough space reserved. I’m experimenting with various approaches to solve this more elegantly at the moment, and also reviewing the way that information is held in the parameter objects, for things like re-serialisation later (e.g. tools). There was another patch on this which nfz originally looked at, but he’s busy right now so I’ll fold that into my current work.

It’s frustrating because it feels like I’m climbing a mountain that’s getting bigger the more I climb it. The depth shadowmapping work had the feel of being in a quagmire due to the small issues that seemed to take forever to tackle robustly (and I still have to go back to polish that), and these patches are raising as many new issues as they solve. It’s all good stuff, and very worthwhile once it’s done, but it strings things out a bit. I’m going to do a little more work over the weekend to try to steal as much advantage as I can on the patch-and-derivative-work situation before I go back to the other things later next week. I still have more testing to do on the threaded loading and new custom shadow sequences, and I have to find time to add unicode support to overlays. I’m tempted to shunt the latter to the next release again, since it’s really not that important in my eyes (if you want uniode support, you have CEGui anyway), but I’ve already shunted it on a release before so I probably shouldn’t.

So, sorry if you’re waiting for the final Eihort release, but no-one is more keen to get this finished than I am,and I’m working hard on getting it done. Whilst I could just stop at pretty much any point and say “it’s done” really, since there are already a ton of new features in the current codebase that in themselves would easily justify a release in anyone’s book, I don’t really work like that. For me to say it’s done, it’s gotta be right - and I think you feel that in your gut as much as anything else. It’s really, really close, but I’m not calling it done yet. I think one of the things that sets Ogre apart is the attention to detail, and that when you dig underneath the surface feature list you find a really solid bedrock underneath, with plenty of breadth, robustness and flexibility. So I’m not happy just paying lip service to things; I try to look at it from a library user point of view - having personally been disappointed as a developer using other libs that don’t stand up to sustained / varied use - and give people what I would want if I was using it. That means making the default behaviour as simple and useful as possible, but making sure there is lots and lots of scope for customisability and alternate uses. That kind of breadth can take a while, but it’s a good investment. I promise it will be worth the wait.

[edit]One of the other reasons not to rush this out is that we keep interfaces (and therefore features, mostly) stable once a major release is done, so if something’s not in Eihort, it will have to wait for the next major release after that (Shoggoth). People who use CVS can of course get these things early but most of our users like to stick to the stable interface version, and I certainly understand that it’s the best option for production development. Another reason for me being a stickler on this.