ZDoom

I committed the change anyway. If someone doesn't like it it it may be reverted.

Scaled I think. (That's is the default correct?)

And I call it slower than a Core 2. ;)

You call that slow? Wait until Leileilol does such a comparison on his 486... :mrgreen:


(Obviously, I doubt that the relative difference will be more significant there... ;))


One question though: Was the second comparison with a scaled or unscaled statusbar?

I got around to testing on a slower coputer IBM TP T22: Pentium 3 900mhz I think.

320x200
With doom_sbar.cpp: ~122fps
Without doom_sbar.cpp: ~114fps

640x480
With doom_sbar.cpp: ~36fps
Without doom_sbar.cpp: ~35fps

I don't think sbarinfo is going to cause a whole lot of trouble for Linux users.

Any decision?

Yes. It also shifts the upper right quadrant when vid_fps is enabled just like before.

Does SBARINFO respect the hud_scale cvar?

[quote="randy"]It's not so much an issue with Windows any more, but it certainly is with Linux.[/quote]
I don't notice any problems performance wise, but of course I am using a Q6600 processor.

The irony being that this patch was done by a Linux user... ;)


I won't commit today though so if someone who can test says it's a bad idea I'll revert this patch before committing.

I don't know about this. The native status bar is still faster than SBARINFO when done with software rendering, since it doesn't redraw everything every frame. It's not so much an issue with Windows any more, but it certainly is with Linux.

Sure. It's not the first HUD/statusbar icon that has. The rotating powerup icons also use such animations.

As far as I am aware the SBarInfo implementation of the Doom status bar and its ZDoom HUD is accurate. If this patch is applied be sure to delete src/g_doom/doom_sbar.cpp.

[attachment=0]doomsbar.zip[/attachment]

The Heretic HUD is almost possible, but a small question on that. Would including an animdefs entry for the health icon be acceptable?