Might be an engine feature request

Does anyone know whether it is possible to change the centre of rotation for a sprite from being its actual centre to being somewhere else along (or even outside) it?

I have tried various ways of trying to drag the little 'centre' box in the sprite (i.e. with various modifiers help down)

If it isn't possible, perhaps it could be added. It can't be that much of an engine improvement if the game currently doesn't support it to allow?

This would be especially useful in parent child relationships as often a rotating parent just creates an irritating effect in the children as they also all rotate around their own centres rather than the parent's. Of course, sometimes this is wanted, but it would be nice to be able to change.

I don't believe the game stores a per-instance center of rotation. It defines the center for each sprite, and if you change it for one (by hacking the game's data files), you change it for every instance of that sprite you place in the map.

It would be a nice engine feature, but I bet the changes required would be substantial.

That's a very, very good question. Unfortunately, you can't. Well, unless you hack the game's data files which changes it for all the sprites of that type, which is probably not what you want. I'm afraid that the way the engine works is reliant on the position of the rotation center in the sprite, so it's unlikely that will ever change. And, yes, this is unfortunate for parent-child enemies, I've noticed this long ago: when the mother sprite rotates, for the whole to keep its shape the centers of all sprites have to be on top of each other. You can use sprites with an off-center rotation center, like the enemy shield or Ice Boss shield, etc... for some purposes, as a workaround. But yes, the engine has its limitations.

Oh well - at least I know I'm not missing something obvious.

I did notice that some sprites do have a different COR - like the save ring pylons for example - which is what made me think it must be possible. Rotating about an arbitrary point is really quite easy with matrices - and GL must do all that for you anyway - or so I would have thought. We're even only talking 2D here.

The game can already semi handle it anyway as you say and the pylons show. It would just be a case of storing a dy and dx integer value for each sprite's COR and applying it to the base COR...

Ah well... I'll plead for it to be in 1.0.2 or whatever comes next. Along with (but not limited to)

- being able to select multiple sprites in the editor and change properties for many
- being able to hide and show sprites in the editor (not just by layer)
- being able to 'select prev/next sprite under cursor click'
- being able to (optionally) still drag/rotate sprite parents without doing likewise to the kids
- showing the names of the sprites in the sprite palette as you mouse over them (and perhaps a larger/full size version to preview too). In fact, just get it into a separate window.
- not chewing 60% of my CPU when foregrounded but 'idle' - come on, the editor when I am not interacting with it chews more CPU than the game when I am!
- multiple undo (or at least redo what I last undid)
- proper naming of extra1 and extra2 based on sprites (e.g. hit-points / damage colour etc)
- making extra1 and extra2 drop-downs with appropriate labels for when they aren't free integers (e.g. again, colours, damage, font-choice etc)
- proper quick colour drop down for the 'correct' colours. Yes, I know you can do it by saving into the system colour picker, but that's assuming we don't use the system one for other things (and it's a royal pain to re-order the swatches)
- A revert to 800x600 box - yes currently I can get round this by using maximise/restore, as long as I never resize but again like the colour picker, it's relying on OS functionality and as soon as I accidentally move/resize the window, I'm lost.

I could go on, but I'll stop there as I probably sound like I am ranting even though that wasn't really the case.

okay.. I was ranting about the idle CPU usage, but that really is poor.