Project

General

Profile

Bug #2025

Doom64TC does not have a fully functional HUD

Added by rhargrave almost 9 years ago. Updated over 4 years ago.

Status:
Progressed
Priority:
Normal
Assignee:
Category:
User experience
Target version:
Start date:
2015-05-02
% Done:

80%

Tags:

Description

This is likely the cause of #2019.

ST_BuildWidgets in doom64/src/st_stuff.c only initializes the automap.
It does not initialize the log, chat, status bar, etc...

doom64-013.png (834 KB) doom64-013.png HUD rhargrave, 2015-05-07 22:25

Related issues

Related to Bug #2019: ST_UILogForPlayer returning garbage in jDoom64Closed2015-04-30

Related to Bug #2024: doom64 plugin does not draw HUDClosed2015-05-02

History

#1 Updated by rhargrave almost 9 years ago

  • Tags changed from Doom64TC to Doom64TC, HUD
  • Subject changed from Doom64TC plugin does not fully initialize HUD widgets to Doom64TC does not have a fully functional HUD
  • % Done changed from 0 to 10

I've added the log (and chat) widget to the HUD, which has effectively stopped the crash-on-LogPost bug from happening. As it stands right now, however, the HUD is not being rendered. I've checked that Hu_Drawer is being called, and it is. I'll debug this and check back.

#2 Updated by rhargrave almost 9 years ago

  • Related to Bug #2019: ST_UILogForPlayer returning garbage in jDoom64 added

#3 Updated by rhargrave almost 9 years ago

It looks like the HUD drawing logic that is present (and obviously not working) is all spread throughout `st_stuff`. Once I finish migrating this to C++, I'll refactor it all out and see about better HUD support.

#4 Updated by danij almost 9 years ago

I have just pushed a hud-cleanup work branch which I started a month or so back where I began doing just that. You may want to continue or adapt that work as it'll likely save you a fair amount of time.

With regards to the HUD, please bear in mind that we plan to replace the implementation entirely using libgui components. A primary goal for any cleanup work should therefore be code clarity. As opposed to best OO practices, code-quality concerns, etc...

#5 Updated by skyjake almost 9 years ago

danij wrote:

we plan to replace the implementation entirely using libgui components

To clarify what this means:
  • libgui is where the low-level OpenGL code resides. It does not contain any higher-level UI widget functionality.
  • The new UI widgets in libappfw do their drawing using the OpenGL classes in libgui. These are the ones responsible for the engine UI overlay (task bar, console log, FPS indicator, etc.). This is completely engine-side functionality currently, because the game plugins have their own UI drawing code, including a simple widget system.
  • There is a plan to replace the game plugins' menu system with one based on InFine and Doomsday Script (#1630).
  • I am not aware of a concrete plan (in the tracker) for exactly how the game HUD widgets should be reworked. Having a direct dependency from libgui to the plugins is not advisable because game plugins must be compilable also in a server-only configuration. That's why there is currently the DGL API published by the engine (which provides a simple OpenGL 1 like drawing API), which is only offered to plugins by the client executable.

#6 Updated by danij almost 9 years ago

Indeed I should have been clearer. The plan is not to literally base the game side HUD widgets directly on top of libgui components. My usage being rather colloquial, there.

#7 Updated by skyjake almost 9 years ago

  • Related to Bug #2024: doom64 plugin does not draw HUD added

#8 Updated by rhargrave almost 9 years ago

  • % Done changed from 10 to 50

I've finished integrating DaniJ's HUD. All that appears to be necessary at the moment is to debug a rendering issue that results in the HUD being rendered starting at the bottom of the display.

#9 Updated by rhargrave almost 9 years ago

  • % Done changed from 50 to 80

I've got the HUD working, the bug that was borking the render had to do with the order in which it was initialized. All that's left now is to insure that it is fully functional and spot any other bugs.

#10 Updated by rhargrave almost 9 years ago

#11 Updated by rhargrave almost 9 years ago

I've marked this as being related to #4 (UI Renovation) since implementing the 64TC hud effectively involved implementing DaniJ's HUD widget system for all engine plugins.

#12 Updated by rhargrave almost 9 years ago

I've attached a picture of the HUD. It is notably more similary to D64EX than D64TC. The keys are currently not displayed -- I will fix that, however.

#13 Updated by skyjake over 7 years ago

  • Status changed from New to Progressed

#14 Updated by skyjake over 4 years ago

  • Related to deleted (Feature #4: UI improvements)

#15 Updated by skyjake over 4 years ago

  • Target version set to Modding

Also available in: Atom PDF