Status Bar Modifiable?

ant1991331 · Post by **ant1991331** » Sat Jul 30, 2005 12:06 am

Is it possible at all to modify the Status Bar???
If not, I'll mkae this a Feature Suggestion, modifiable Status Bars will be great, because you can't even see the AltFire Ammo when the status bar is up, and for custom ammunition and slots, you should be able to put the ammunition numbers on the side of the screen, and for the Weapon Slots, 1,2,3,4,5,6,7,8,9, and 0.

Sphagne · Post by **Sphagne** » Sat Jul 30, 2005 12:10 am

I hope we would be able to disable status bar, and remove it from screen, so that we could design our own status bars, by hudmessages and graphical fonts.

ant1991331 · Post by **ant1991331** » Sat Jul 30, 2005 12:37 am

I get your point there.

Post by **Nash** » Sat Jul 30, 2005 1:34 pm

HUD scripts!

http://forum.zdoom.org/potato.php?t=7145

ant1991331 · Post by **ant1991331** » Sun Jul 31, 2005 4:35 am

Oh right, I remember that...

Jonathan · Post by **Jonathan** » Sun Jul 31, 2005 1:56 pm

Why not move the whole hud system into acs? Rewrite the existing game huds using acs functions, then provide some way to override or complement the original scripts, maybe with a function like RegisterHUDRenderer(int scriptnum) or something.

Post by **Graf Zahl** » Sun Jul 31, 2005 2:22 pm

The status bar code is far too complicated for ACS.

AFADoomer · Post by **AFADoomer** » Sun Jul 31, 2005 6:32 pm

Graf Zahl wrote:The status bar code is far too complicated for ACS.

Why do you say that? Other than not currently being able to pull the max ammo amounts from code, and not being able to do the damage direction faces, everything else can be done...

Post by **NiGHTMARE** » Sun Jul 31, 2005 6:34 pm

HUDINFO.

Post by **Nash** » Sun Jul 31, 2005 7:04 pm

In addition to modifying the HUD, any future implementations should also make it possible to modify the game menus... that way you can totally customize the look of your game, determine what menus appear or don't appear, etc.

DoomRater · Post by **DoomRater** » Sun Jul 31, 2005 7:54 pm

DOOM SKINS!

Post by **Graf Zahl** » Mon Aug 01, 2005 1:24 am

AFADoomer wrote:
Graf Zahl wrote:The status bar code is far too complicated for ACS.
Why do you say that? Other than not currently being able to pull the max ammo amounts from code, and not being able to do the damage direction faces, everything else can be done...

No, it can't. The status bar handling contains much more than just display the graphics. And the max ammo amount can be retrieved but what can't be retrieved is the type of ammo the player uses. And checking the current weapon is possible but only with prior knowledge of all the weapons that exist.
Don't forget the other games which also do some specialized stuff on their status bars.

Another very important issue is that the status bar only updates the parts that change so an ACS implementation would be somewhat slower.

Post by **Graf Zahl** » Mon Aug 01, 2005 1:25 am

Nash wrote:In addition to modifying the HUD, any future implementations should also make it possible to modify the game menus... that way you can totally customize the look of your game, determine what menus appear or don't appear, etc.

Cool in theory but IMO that goes far beyond any reasonable amount of work for the features gained by it.

Jonathan · Post by **Jonathan** » Mon Aug 01, 2005 6:44 am

I decided to have a go at making an acs emulation of the status bar myself last night. I managed to get something pretty reasonable with a couple of hours work, I'll probably polish it up and post it tonight. It's actually pretty easy to get 90% of the hud functionality with the current acs capability. Of course it's the remaining 10% that's trickier. Some stuff that would help:

- Some way to get the size of font/image glyphs. It would reduce the amount of magic numbers you have to store in #defines and int arrays.

- Better weapon and ammo interrogation. As Graf mentioned, this is a sticking point. Maybe just a CheckInventory("CurrentAmmo") extension would solve it, or some functions such as GetCurrentWeapon and GetCurrentWeaponAmmo.

- Events/Messaging. A little pie in the sky perhaps, but being able to register scripts to receive engine events such as damage, firing and pickups would save you having to store and check these values yourself each time round the loop. This would also mitigate the speed issues.

- GetLastAttacker, for implementing attack direction faces.

Speed-wise, my test seems to go quick enough. Yes there's bound to be a performance hit, but so long as you code carefully I don't think it would be too significant.[/list][/list]

Post by **Graf Zahl** » Mon Aug 01, 2005 7:03 am

The real hit occurs when drawing all the stuff. The ACS code is fast enough.