Remove doom_sbar.cpp
Moderator: GZDoom Developers
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Remove doom_sbar.cpp
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.
The Heretic HUD is almost possible, but a small question on that. Would including an animdefs entry for the health icon be acceptable?
The Heretic HUD is almost possible, but a small question on that. Would including an animdefs entry for the health icon be acceptable?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49076
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Remove doom_sbar.cpp
Sure. It's not the first HUD/statusbar icon that has. The rotating powerup icons also use such animations.
Re: Remove doom_sbar.cpp
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49076
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Remove doom_sbar.cpp
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 won't commit today though so if someone who can test says it's a bad idea I'll revert this patch before committing.
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: Remove doom_sbar.cpp
I don't notice any problems performance wise, but of course I am using a Q6600 processor.randy wrote:It's not so much an issue with Windows any more, but it certainly is with Linux.
Re: Remove doom_sbar.cpp
Does SBARINFO respect the hud_scale cvar?
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: Remove doom_sbar.cpp
Yes. It also shifts the upper right quadrant when vid_fps is enabled just like before.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49076
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Remove doom_sbar.cpp
Any decision?
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: Remove doom_sbar.cpp
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.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49076
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Remove doom_sbar.cpp
You call that slow? Wait until Leileilol does such a comparison on his 486...
(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?
(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?
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: Remove doom_sbar.cpp
Scaled I think. (That's is the default correct?)
And I call it slower than a Core 2.
And I call it slower than a Core 2.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49076
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Remove doom_sbar.cpp
I committed the change anyway. If someone doesn't like it it it may be reverted.