[WIP] Zeta-Windows

[Sarah]

Code: Select all

[img]http://orig06.deviantart.net/e05b/f/2016/288/1/7/zlogo_by_saican-dal3fzq.png[/img]

Z e t a - W i n d o w s
----------------------------------------------------------------------------------------------------------------------- v 1.0


Relive by Firefreezer - the Z-Windows Demo theme

---

-----------------------------------------------------------------------------------------------------------------------

• A Generic GUI API for (G)ZDoom!

• (Z)eta-Windows is a generic GUI API aimed at enabling unique implementations that are flexible and dynamic, specific to the needs of the user, fast, powerful, and simple to use. The entire Z-Windows API is written in C and compiled with GDCC in order to be interpreted by the ACS VM. Furthermore, the system requires a custom build of either engine flavor****.
  
  While Z-Windows is capable of being a tool for the general (G)ZDoom community, independent developers looking for extensive interface design flexibility in custom environments without exhaustive production time spent in-code will benefit the most from the Z-Windows API.
  
  Z-Windows gets its name not from Microsoft Windows, but from the X Window System (also ZDoom), which provides the basic GUI functionality for many UNIX-like operating systems. Just like X, Z-Windows provides just the basic GUI framework without mandating what the actual interface is supposed to look like. The term windows is both a GUI organizational concept and a programming concept the interpretations of which can vary dramatically. Z-Windows does deviate from X in that the functionality of Z-Windows is geared toward complete GUI management in a video game architecture and as such can mimic the appearance of an actual operating system but does not offer the wider functionality of one. Also, while GDCC is a full C compiler, functionality like reading and writing files is impossible as the ACS VM does not have that kind of access to the computer's operating system.
• Completed Z-Windows GUI Features:
  1. Key-bound, mouse driven input
  2. Variable cursor speed and click sensitivity
  3. Multiple predefined fonts and support for custom fonts
  4. Multiple font sizes, colors and support for custom colors
  5. Multilingual build options*****
  6. Predefined, optional, "core" buttons
  7. Window movement and resizing
  8. Window priority-based layering
  9. Game-level signaling objects that grant access to specific windows
  10. Finite "popup" windows
  11. Better text wrapping*
  12. Support for various HUDMessage types, including translucency
  13. Check, radio, and custom single-interaction buttons**
• Work In Progress Z-Windows GUI Features:
  1. Window object linking for tab groups, scrollbars, radio/check buttons, and the text wrapping system*
• Planned Z-Windows GUI Features:
  1. Scrollbars
  2. Key-bound interface driving
  3. Inventory management module
  4. Application dock module, similar to Macintosh***
• Z-Windows API Features:
  1. API structure and syntax that's similar to the Win32 API
  2. OO C-Class implementation using a basic tabling system for direct memory access to objects
  3. Internal HUDMessage ID management for all objects
• Progress to v1.0 - 72%
  • ▓▓▓▓▓▓▓░░░

-----------------------------------------------------------------------------------------------------------------------

• A Few Notes on Z-Windows
  1. * Better Text Wrapping: Z-Windows-handled text wrapping is almost complete! Text can be either hyphenated or not, wrapping can static or dynamic, and all elements can be connected to a text element who's wrapping changes will effect the vertical position of the connected element. The code is much closer to complete than before, but there's still some work to do.
     
     • Update! Text wrapping is about 98% complete, pending some future tweaking. In either case, it's being moved to the Completed Z-Windows GUI Features category. The video below demonstrates the ability of Z-Windows text wrapping.
     • Object linking to text objects is complete, other objects are on the priority list now.
     • Note: The window that appears to be missing it's edges is actually not! This is a feature where the window is drawn using a single background image; meant for simpler or even static designs. (I call it Win8 mode)
     
     
  2. ** Radio, Check, and Custom Single-Interaction Buttons: Z-Windows differentiates between two different events, a click and a drag, the latter of which is more complicated and is the reason why these kinds of buttons were given a low priority. Interaction with radio, check, and any other button is now a matter of calling a boolean check function for that particular button and executing whatever you want if it passes. Right now this is all kind of messy, so future updates will probably include still easier manipulation of button objects.
     
  3. *** Application Dock Similar to Macintosh: A single Z-Windows implementation is designed to mimic several applications running at once, in this case it could be the player's inventory, their health bar, their ammo bar, and so on. So instead of having a "desktop" my goal for mimicking the opening, closing, and minimizing of applications is to create a dock system. This is likely the last of the features to go in because it will rely on the majority of the system functionality to work. I tend to think of this module as a further abstraction of the windowing concept.
     
  4. **** Custom Engine Build Requirement: Probably the most important update to date, after several very important optimizations to the internal Z-Windows system, it appears that the requirement of tweaking the ACS VM instruction count is likely no longer a requirement. To clarify, there has been no stress testing yet to determine if this is fact or blubbering, hopeful, fiction. However, after a few more things are done and other stuff cleaned up, stress testing will begin.

-----------------------------------------------------------------------------------------------------------------------

• ***** Multilingual Support - Your Help is Greatly Appreciated!

• Z-Windows is not Unicode therefore multilingual support comes in the form of ASCII character sheets, which can be translated into the actual fonts used by the system. There are a few strings that are explicitly defined and Z-Windows offers translations of those strings, currently, to German, French, and Spanish via user controlled compiler directives in the headers of the source code. I will gladly add translations for more language support, but I request the community provide them so I'm not spending all of my time in Google Translate; on a side note, native speakers will hopefully give proper translations where Google may not. However, supporting languages like Chinese may be difficult at this time because of the word structure difference. An extreme long-shot goal is possibly to offer better language support via a lump like LANGUAGE. In it's current form, language selection is far too hardcoded.
  
  Explicitly Defined Strings that Need Translated:
  • Close
  • Minimize
  • Move
  • Resize
  • Instance
  • Priority
  Currently Supported Languages:
  - This will be updated as more translations become available. Don't see your language? Post translations of the strings above, please! Corrections are also appreciated!
  • English
  • French
  • German
  • Spanish

---

Google Translate

-----------------------------------------------------------------------------------------------------------------------

• Licensing for Z-Windows
  • Z-Windows is licensed under GPLv3 to allow for both freeware and commercial usage of Z-Windows.

-----------------------------------------------------------------------------------------------------------------------

• Z-Windows Updates are Mandatory - (DD/MM/YYYY)
  • 14-10-2016 - initial post
  • 22-10-2016 - Added key-bound driving to Planned Features, object signaling to In Progress Features, and removed multi-player support. Progress meter has been updated to 47% (8 of 17 features)
  • 22-10-2016 - Object signaling has been implemented. Progress meter has been updated to 52.9%
  • 11-11-2016 - OP update to include silent changelog
  • 08-12-2016 - OP update to Custom Engine Build Requirement, this is looking more and more like it's going away!!!!
  • 16-01-2017 - OP update to Better Text Wrapping feature information, getting close to done with it!
  • 16-01-2017 - OP update to overall post, Better Text Wrapping is complete
  • 23-02-2017 - OP update to overall post, buttons are done, HUDMessage handling is done, new demo movie, and progress is now 72%!
  • 04-03-2017 - OP update to download list, Z-Windows Alpha is now available!

---

• 11-11-2016 - Added Silent Changelog to OP
• 11-11-2016 - Moved user implementation definitions from system definitions to their own file. Build language control has also been moved to its own file.
• 12-11-2016 - Several macros have been created as argument replacements for default and disabled window constructor states which can greatly shorten the constructor argument length.
• 14-11-2016 - Added new demo movie to OP.
• 14-11-2016 - Added finite windows to the Completed Features List; this required enough testing and changes to warrant calling it a feature.
• 16-11-2016 - Plugged memory leak that was plaguing text wrapping; really just bad memory management, this is being fixed in several places now.
• 21-11-2016 - Z-Windows now restarts when a screen resolution change is detected.
• 26-11-2016 - Fixed a priority switching issue that caused incorrect overwriting of IDs if an eliminated window didn't have the highest priority.
• 26-11-2016 - Discovered that window priority switching isn't responsible for the disappearance a window when layering is adjusted, it's actually the window procedures themselves. This has been fixed by adding drawing code to message cases that previously were stubs; the same drawing code would be there eventually anyway.
• 09-06-2017 - Added noticed to OP of project abandonment.
• 16-08-2017 - Modified OP to remove notice of project abandonment.
• 22-11-2018 - Modified OP and thread title to reflect take down of Z-Windows source and template.

-----------------------------------------------------------------------------------------------------------------------

• Do Not Make Illegal Copies of Z-Windows Files
  1. Download the Z-Windows Project Template. It is an empty project, except for the demo pk3.
  2. Download GDCC, either from there or from here.
  3. Read the readme files throughout the project template; they are very short and to the point.
  4. Download the latest Z-Windows Source

-----------------------------------------------------------------------------------------------------------------------

• The Final Word on Z-Windows
  • For me, Z-Windows began as an experiment that has grown into a means to an end. Ultimately Z-Windows is for Centre-01 and meant to be a replacement for its inferior predecessor, the R.A.I.D. That interface is a procedural mess with no interaction, or capability of, between its components and could never be multi-player compatible because of the excessive globalization of variables. Z-Windows is meant to address all of that and still support and expand the advanced interface capabilities of the R.A.I.D.
    
    Finally, I'm also aware that it's been considered bad practice to spam HUDMessages to build GUIs for some time now. I'm not sure of the origin of that determination, but I'm also aware of the recent discovery by Nash regarding HUDMessages and VR headsets; the short of which is Z-Windows and Oculus are not going to play together nicely for the foreseeable future, if ever. This can't be helped and is an unfortunate limitation, but the project will go on.

-----------------------------------------------------------------------------------------------------------------------

• Current Project Status 09.06.2017

• Work on Z-Windows has ceased as of the date of this update, I am no longer actively developing this or any projects for (G)Zdoom. The Z-Windows source will remain available to anyone interested, however I suggest you use ZScript for your gui needs now. You are welcome to do as you will with the Z-Windows alpha code, use it, make it a base for something else. I do request a credit if you use my code.

• Project Status Update 16.08.2017

• While I am not currently in active development of Z-Windows, the real-life situation that caused me to abandon the project has been dealt with and I have been playing around with (G)Zdoom development again, including poking about the Z-Windows source. To reiterate, this project is no longer to be considered abandoned and as I have time I will be dedicating it to getting a version 1.0 released.

[Nash]

Three things:

1) Holy fuck an OS in ZDoom
2) ACS VM instruction limit: would it be worthwhile to just increase this upstream on ZDoom itself? ZDoom already has relatively high system requirements, GZDoom even more so, moving forward I think this would be a good idea.
3) IMO the biggest showstopper to ACS-based GUIs is that it's all running in playsim context. Many problems with this:
- locked to 35 FPS
- input is handle via GetPlayerInput which works horrible in multiplayer ("mouse" input for example will be the slowest for the host while the last player will have the fastest input)
- no ability to actually sample raw values out of your keyboard/mouse (we are basically just hacking around the player input limitations)

Don't get me wrong and take this as naysaying though, I am fucking impressed at what you've done here. I really am! It's just that I've been working on a ZDoom-based standalone for quite a few years now too and with experience I have just been jaded with the hacker mentality and workarounds we have had to come up with to make some things happen. Which is why as of late I have been more comfortable just directly adding engine features into my game and skip workarounds. A lot of these won't work (or be accepted) in a generic Doom context which is why I haven't sent them as PRs upstream but I keep my source up on Github anyway as per the GPLv3 requirement.

I have been considering so badly lately to just dump my current game's ACS UI and just code it natively in the engine... pouring over the built-in Menu subsystem's source code to try and study it.

That said, this is a fucking cool thing and I'll be watching this closely!

PS: would be cool to see the Zeta-Windows API built directly into ZDoom instead of ACS... ? ;) (just kidding)

[Nash]

Oh and 1 more thing regarding HUDMessages and VR headsets - perhaps in future if someone badly needs it, the HUDMessage drawer can be extended to draw "VR-friendly" (ie it automatically happens when a VR mode is activated... I >think< biospud mentioned doing this for the built-in crosshair drawer but don't quote me on that; I barely understand the VR stuff and he's just the best expert when it comes to VR... plus I don't even have any VR gear to test on :P)

[Sarah]

I'm personally against increasing the instruction limit upstream because of the precedent that I think it would set; I don't think I've seen many projects with such an issue but I do wonder what makes mine worth the change? I think a functional version 1.0 with such a requirement is a logical precursor to enough optimization that the requirement dies a wonderful death. A lot of the system still suffers from linear storage and searching; even though I said the system uses tabling, there's no hashing involved. Also priority-based access to stuff is guaranteed to run a search.

There are significant drawbacks to doing GUIs this way, I totally agree. The idea of proper classes has me interested, as well as proper file access too. Perhaps replace SBARINFO with Z-Windows?

P.S. IDK if you're kidding or not about just building this into the engine, it's an interesting thought, but I'm not sure how or where to start. Also vector fonts, that is all.

[mumblemumble]

i cannot tell you how much id love a system shock 2 esqe inventory system with this...

[daimon]

Incredible what (G)Zdoom can do...

Yeah, a Doom OS is a really REALLY unique feauture!

[Jaxxoon R]

This really makes me wish someone would bite the bullet and implement a modern mouse-driven UI system to replace MENUDEF. It'd potentially mean that things like DoomRPG or Doom Rougelike Arsenal's menu systems could be navigated without having to fuss around with weird keybinds all the time.

[Tormentor667]

This is sick

[Wivicer]

This is ridiculous and completely unnecessary.




I love it.

[Someone64]

This really makes me wish someone would bite the bullet and implement a modern mouse-driven UI system to replace MENUDEF. It'd potentially mean that things like DoomRPG or Doom Rougelike Arsenal's menu systems could be navigated without having to fuss around with weird keybinds all the time.

Subenji WAS working on that before he vanished. The menu system was partially done already and he was completing it but now he's gone. :/

[Sarah]

This really makes me wish someone would bite the bullet and implement a modern mouse-driven UI system to replace MENUDEF...

MENUDEF controls the main menu and its sub-menus; new game, save game, options, etc. There's already mouse support available for those menus built into ZDoom; not bashing what's there, the fact it's there is awesome, but I do think it could be better. Z-Windows adds both keybinds and some options to the game with MENUDEF but isn't going to do any more than that. My API is specifically for making HUDs and facilitating other interface abstractions; shops, custom dialogue, inventories, etc. If Z-Windows were to replace anything in the engine, I'd think it would be SBARINFO; however that currently isn't the plan.


P.S. - Mini Update
String linking is implemented, still working on wrapping logic - this is taking precedence over wider HUDMessage functionality because this job doesn't involve argument bloat throughout the system.
Fonts are now objects as well - this is an experimental solution to a part of better text wrapping; SetFont usage is likely to be taken over by a Z-Windows function.

[Ozymandias81]

Insanely useful!

[VriskaSerket]

Literally the next step in evolution.

[ZZYZX]

You can forget about the instruction limit by splitting the initialization into parts executed separately with ACS_NamedExecuteWithResult.
I think normal *WithResult calls from a script will get stacked and still run away, so you have to execute all parts for some procedure using an actor.
Another reliable way is running all initialization parts with ACS_NamedExecuteWithResult from a script and putting Delay(1) at the beginning of each script. This way the order of script execution gets preserved, they all execute at the same tic, and their instruction counters don't stack, although all this at the expense of executing it on next tic and not current.

The requirement of custom engine is really terrible.

Finally, I'm also aware that it's been considered bad practice to spam HUDMessages to build GUIs for some time now.

Also what the flying hellpig? That's not true. At most some specific person dislikes it. You can't consider something that's the only way to go "a bad practice".

[Sarah]

You can forget about the instruction limit by splitting the initialization into parts executed separately with ACS_NamedExecuteWithResult.
I think normal *WithResult calls from a script will get stacked and still run away, so you have to execute all parts for some procedure using an actor.
Another reliable way is running all initialization parts with ACS_NamedExecuteWithResult from a script and putting Delay(1) at the beginning of each script. This way the order of script execution gets preserved, they all execute at the same tic, and their instruction counters don't stack, although all this at the expense of executing it on next tic and not current.

Actual script calling in GDCC is actually exactly the same as calling a regular function. The header of the function is given extra compiler directives that flag the function as a script. It's a bit befuddling at first but it makes sense as you use it. In Z-Windows, it's wisest to push window construction off to a custom initializing function (could call it a constructor) as to contain all the data nice and orderly; with that in mind it actually makes a lot of sense to allow those functions to be scripts so as to allow for a single tic delay before proceeding. So good idea there, ZZYZX!

Also the compiler directives determine script type and Z-Windows doesn't have any restrictions regarding window constructors, so returning a value at completion is perfectly acceptable.

The requirement of custom engine is really terrible.

Finally, I'm also aware that it's been considered bad practice to spam HUDMessages to build GUIs for some time now.

Also what the flying hellpig? That's not true. At most some specific person dislikes it. You can't consider something that's the only way to go "a bad practice".

Well, like I said earlier I think I can get the code optimized enough that that won't be a problem anymore. Z-Windows started back when Nash didn't offer binaries of GZD-GPL and I've primarily geared Z-Windows towards indie devs, so I didn't think having to make a quick tweak before compiling was too big a deal. Still, it's something I want to eliminate if I can.

Finally, I'm not sure where/from who I heard that this method of GUI creation is "bad practice". I think the stigma probably stems from the lack of decent multi-player support. Nash already pointed out that the hack for creating mouse control won't work right in multi-player, along with a couple other drawbacks. Z-Windows is basically a hack-of-a-workaround so I can see where some folks wouldn't want to use it and think HUDMessage GUIs are "bad practice".


Mini Update (again) - 19/10/2016
Z-Windows fonts are now objects, buttons and strings both use what is now called a ZFONT - there's information in the object that is necessary for better text wrapping
Custom fonts are still supported, implementations will simply call a x_Manager function to create/retrieve font objects/pointers
SetFont is still available, however zFontSet is the function for using ZFONT objects with SetFont

On a related note, I plan to do a readability cleanup of the functions, code and names, before release.