.gif Textures - a question

Only Chris can really answer that, but I'll guess it'll be a "no", since gifs are, for all I know, very inefficient to display.

Well, I know a nice workaround, which will enable me to create what i need, so I should be fine. Just thought I'd ask.

Definitely not supported, and unlikely to be so.

Nothing to do with inefficiencies per-se, but rather the animation; The engine only supports simple textured polygons, and there's no method for displaying animations/ videos on one.
openBVE should currently load GIF files, but IIRC will only display the first frame of animated gifs.

Your best bet performance wise would be to produce a 'filmstrip' of the animation you wish to display, and use the TextureShiftFunction to move between the frames as appropriate.

Yep, based on the character of the animation I will have to settle for either texture shifts, or cyclic state changes.

IIRC texture shifts are described as by far the most inefficient animation the engine supports at all. State changes should thus be better. Or have you changed this, Chris?

This is one of those cases where the documentation whilst not 'wrong' per-se, it's rather too simplistic to really be taken at face value.

It's going to depend heavily on the individual object and combination of functions / textures it contains, and for that matter what it actually does within the world.

Essentially speaking, anything using transparency slows performance by a factor of approximately 2.
Similarly, a frame which actually contains a state change within an object is considerably slower than one in which the object state does not change.

The math for texture shifting must always be applied to calculate the final co-ordinates, hence an object using this function will be inherently slower than one which changes state infrequently.
As soon as the state changes become more frequent however, the performance boundary becomes considerably more blurred.

Assuming you haven't got '00s of objects using a texture shift though, I wouldn't be too bothered about it.

I think that's also when the HW part comes into play. I suppose it's the processing unit on the GPU that does these calculations...? Or is it pre-chewed by the CPU and then finalized at the video card level?

Dexter wrote:I think that's also when the HW part comes into play. I suppose it's the processing unit on the GPU that does these calculations...? Or is it pre-chewed by the CPU and then finalized at the video card level?

At present, essentially everything is calculated on the CPU.

The GPU speed will have a certain effect, especially if AA / AF are involved, but the CPU is the main bottleneck.

I see. So I have big redundancy on my GPU.
Is openBVE capable of utilizing multiple threads? I think I always observe two cores of my CPU working much more than the other two when playing.

Dexter wrote:I see. So I have big redundancy on my GPU.
Is openBBE capable of utilizing multiple threads? I think I always are two cores of my CPU working much more than the other two when playing.

Mostly not.

My builds make some progress in this area, but not a great deal.

So basically, the biggest factor is the CPU performance in single-threaded mode. That's where Intel should dominate...