Moderator: GZDoom Developers
gdm413229 wrote:If a native Linux port of GZDB is in the works, you should pack data that's normally packed into the Windows executable (except the icon) into a .wad file, which is beneficial to achieving platform independence. Not sure how nice Vulkan plays with Mono. A Vulkan renderer could be a nice thing to have for a Linux fork of GZDB alongside the OpenGL 1/2/3 backends.
gdm413229 wrote:To remove DirectX's grasp, all you have to do is get the SlimDX source code, creating a new branch and substituting EVERY Direct3D 9 draw call for OpenGL 3.x/Vulkan equivalent calls. (e.g. OMSetBlendState gets morphed into glBlendFunc and SlimDX is open source)
gdm413229 wrote:ScintillaNET could be replaced with code that launches an external editor e.g. Vim or GNU nano, and will inject the script into the map to be saved once the external editor process disappears from the process table.
gdm413229 wrote:When running GZDB's first .NET 5.x version, the font that's otherwise selected as MS Sans Serif will be chosen as "fixed" in Linux, just so GZDB's future Linux installation process acts more conservatively on the bandwidth usage. Don't forget to give the Linux users their own set of icons, preferably based on KDE's Breeze or GNOME's Adwaita icon sets. (to minimize icon-set clash with other Linux GUI applications)
gdm413229 wrote:The font differences are to ensure that the application doesn't crash with a "font not found" error when picking a font for the editor's 2D view. (that font is used to show additional sector properties, linedef lengths among other things.)
gdm413229 wrote:Not sure if static models could be done using display lists. One of the big downsides to display lists is you can't change the geometry without regenerating the entire display list. (for static models, use display lists and for animated models, use vertex arrays or VBOs.)
gdm413229 wrote:The entire map's 2D and 3D representations could be in the form of VBOs and/or vertex arrays, not display lists. Regenerating display lists are laborious (and they are a performance sink!) when you have a big and/or detailed map on the architect's table.
Return to Hall of Unpleasantness
Users browsing this forum: No registered users and 0 guests