Custom Query (5409 matches)
Results (58 - 60 of 5409)
|
Ticket
|
Resolution
|
Summary
|
Owner
|
Reporter
|
| #103 |
fixed
|
GL_ARB_texture_env_crossbar requirement is unnecessary
|
Nicolai Hähnle
|
Philip Taylor
|
| Description |
GameSetup.cpp checks for the presence of the GL_ARB_texture_env_crossbar extension, and complains if it's not there, in a way which implies that it's required and the game may break in unexpected ways.
That extension appears to be used only in FastPlayerColorRender, which is optional - it falls back to SlowPlayerColorRender if the required features are missing. Currently it's only testing for >= 3 texture units. It should probably be testing for GL_ARB_texture_env_crossbar too, and quietly switching to the slow method if it's unavailable.
|
| #104 |
fixed
|
GUI - Modal Dialogs (Namespaces)
|
|
Stuart Walpole
|
| Description |
- Problem: Currently all the GUI XML files are combined into one big GUI object, and you have to hide/unhide individual screens at appropriate times to make them appear, which is kind of nasty (and would make any editor much harder to do). This also creates problems with hotkeys (if the Esc key has a specific effect on the main menu, the Esc key will have the same effect everywhere else), as well as determining z order. For example, the dropped-down part of a combobox should usually be visible on top of everything, except when a message box is open on top of that (which seems to be an unavoidable problem if there's a single global z, instead of a localised per-GUI-screen z).
- Solution: Separate GUI XMLs (other than those reserved for special purposes, such as sprite.xml, styles.xml and setup.xml) are considered their own namespaces (local pages). To switch between them, call a function to open/close an XML screen.
- Each page is an independent GUI window ("modal dialog") with its own local z order. When objects with the same z order overlap, whichever object is written first should have the lower z, making specification of z values largely unnecessary.
- There could be any number of these pages; pop-up windows (like game setup or a Yes/No dialog) could also be separate pages.
- The XMLs are added to the GUI scope via init.xml (so that each XML load is not hardcoded into the engine).
- Pages are drawn in z order using the sequence in which they are declared in init.xml.
- .cfg Hotkeys are grouped under page names (hotkey.mainmenu.quit, hotkey.session.return) so that they are only effective while that page is open, or can be set as part of the reserved "global" page (hotkey.global.watermark) and the hotkey has the effect on any page.
- This will also facilitate the -quickstart allowing the game to jump straight to a default session for testing purposes (while currently loading the GUI means having to start at the main menu).
|
| #105 |
fixed
|
GUI - Hotloading
|
|
Stuart Walpole
|
| Description |
- Problem: Although VFS recognises when game assets are modified and reloads them while the game is running, the GUI does not currently support this feature.
- Solution: Adapt the GUI to be capable of auto-reloading changed assets. Such functionality should greatly improve rate of GUI development, since coordinates can be tweaked while the game is running without the need for an equivalent WYSIWYG editor.
|
Note:
See
TracQuery
for help on using queries.