Status Bar Modifiable?
Moderator: GZDoom Developers
-
- Posts: 598
- Joined: Fri Jun 24, 2005 3:19 am
- Location: Makin tracks with jetboots
Status Bar Modifiable?
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.
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.
-
- Posts: 598
- Joined: Fri Jun 24, 2005 3:19 am
- Location: Makin tracks with jetboots
-
- Posts: 598
- Joined: Fri Jun 24, 2005 3:19 am
- Location: Makin tracks with jetboots
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
AFADoomer wrote: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...Graf Zahl wrote:The status bar code is far too complicated for ACS.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Cool in theory but IMO that goes far beyond any reasonable amount of work for the features gained by it.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.
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]
- 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]