-
Posts
81 -
Joined
-
Last visited
-
Days Won
2
Everything posted by covert_caedes
-
Please test this and let us know if anything looks worse than before, or doesn't look better when you would expect it to Note that I adjusted the TDM core GUIs, but not any FMs, so if a FM ships a custom GUI it might still look stretched in wider or narrower resolutions. (But might also look fine if it extends TDM GUIs in the intended ways, @stgatilov put a lot of work into that in the past which really helped with my changes). Report issues either way, I'll try to figure out if the problem is in the mission or the core GUIs or my code
- 1 reply
-
- 2
-
-
Yes, theoretically that should be possible, by having different windowdefs for different aspectratios and using something like visible "gui::cstAspectRatio" < 1.6 in one and visible "gui::cstAspectRatio" >= 1.6 in the other. Maybe it could even be done by setting the rect's width based on one of the new variables? Feel free to experiment No idea how those are created and distributed, but so far my changes are not in the SVN repo but just my private git repo (for the code) or those zip files (for the .guis). I'll commit them to the SVN repo once someone from the team gives their ok (should probably be a coder who can decide whether they want all my changes to the engine or not). Yes you do So far the menus were optimized for 16:9 and looked stretched at other aspect ratios, especially if they're very different (16:10 still looked ok, 4:3 or 21:9 not so much). The main goal here was to make sure they look good at any aspect ratio instead of visibly stretching or squeezing text and icons. The only thing that's still stretched is that "noisy" part of the background in the main menu - I don't think it matters, it doesn't have a real shape anyway. But background images like those figures or the skull on the death screen now preserve their aspect ratio - so them looking the same at 16:9 is expected There may be some exceptions for things that looked like they were meant for 4:3 and looked stretched at 16:9 (like the shop menu and credits, I think?) - those should now look like in 4:3 at any aspect ratio incl. 16:9. (Caveat for "not stretching/squeezing": Some things are still squeezed for aspect ratios between 4:3 and 16:9, because menus with two "pages" on them like the missions list I posted above often just don't fit into narrower resolutions - but that's at least not worse than before. And for wider aspect ratios those menus now look like at 16:9 instead of being stretched.)
-
screenshots of the main part of the main menu, here I took extra care to move the left and right parts closer to each other for narrower aspect ratios. In the mission list above the menu is just squeezed when narrower than 16:9, because it was too hard to get both parts to fit into 4:3 in their original width, but here it was possible because cutting off parts of the background figure doesn't hurt Update: just realized the screenshots I posted here were outdated, replaced them with new ones
-
There's a new build at https://github.com/DanielGibson/thedarkmod-mirror/pull/1 and also updated GUIs - I think all relevant GUIs are done now? Needs testing of course, please let me know if anything looks weird or otherwise misbehaves Examples of a menu in different screen aspect ratios (that number was just for debugging and shows the current aspect ratio, e.g. 16:9 is 16/9 = 1.777..)
-
Doom3/TDM GUIs use a 640x480 coordinate system and assume that the player uses a 4:3 resolution, otherwise they'll look stretched. Most TDM GUIs assume that they will be stretched to 16:9, i.e. pixels aren't square (which makes writing GUIs pretty painful, I guess) and when using a non-16:9-resolution things look stretched. TDM added the forcescreenaspect window variable that will prevent a windowDef from being stretched when used with hcenter that can be used to have something undistorted on the center of the screen, but it's still pretty limited (and barely used) - and as far as I can tell child-windowDefs of that will still be stretched. Anyway, CstDoom3 2.0 introduced Anchored GUIs which allow anchoring windowDefs to a corner or center of the screen and prevents them (and everything contained in them) from being stretched. Those anchored windowDefs are mostly limited to 640x480 virtual pixels (scaled to screensize, as much as possible while keeping the aspect ratio), so regardless of the window's resolution, they will remain unstretched (well, except for those anchor cases that explicitly stretch in one direction, like anchoring just to the top instead of top center or top left or whatever). This allows for example to anchor the weapon_display windowdef to the lower left corner of the screen, the lightgem to the lower center of the screen and the current item to the lower right corner of the screen. No matter how wide or tall the window is, they will remain there, unstretched. I think these screenshots illustrate it pretty well: For dhewm3 1.5.5 I ported them to dhewm3 and greatly improved them, for example they can now also be used for regular (interactive) menus, while in CstDoom3 they only worked with noninteractive fullscreen GUIs like the HUD (mouse positions weren't calculated correctly). This feature is documented in detail at https://github.com/dhewm/dhewm3/blob/master/docs/GUIs.md#aspect-ratio-independent-guis-covering-the-whole-screen-with-cstdoom3s-anchors Now I ported that to The Dark Mod, with just two little changes: There is no scaling of menus to 4:3 with letterboxing, so the window variable scaleto43 is not needed or even supported Most of TDM's GUIs assume that they'll be stretched to 16:9, even though using the 640x480 4:3 coordinate system. To accommodate this, I added the cstAssumes16_9 window variable. cstAssumes16_9 1 will cause the anchored windowDef, that would normally have a 4:3 aspect ratio, to be stretched by factor 1.333 (in width), just like it would when stretching to a 16:9 resolution. So when porting existing GUIs to this system, you don't have to recalculate the coordinates - if they were meant to be stretched, add a "cstAssumes16_9 1" line to the windowDef (and "cstAnchor CST_ANCHOR_BOTTOM_LEFT" line or similar, of course) and it should work in most cases. By the way, this is completely backwards-compatible, so if your .gui doesn't use cstAnchor, it will continue to work just like before. At https://github.com/DanielGibson/thedarkmod-mirror/pull/1 you can find a testbuild for Windows with this enabled, some ported GUIs, more information and the code changes. Currently this is an experimental patch, I don't know when or if it will be merged to the official TDM source. Please check it out and play around with this feature and let me know how you like it and if you run into problems! I've ported most of the HUD, but there's still a lot of GUIs that would benefit from being ported, like the inventory menu, the main menu and more. TBH those seem pretty complex so I'd appreciate help from someone who's familiar with their code
-
Same TBH. And I don't think perspective looks bad in TDM in general. Yeah, the moon looks weird on those screenshots on the first page, but I think that's more of a problem with skyboxes and not so much with geometry in general? Maybe skybox code could be improved, or maybe just the material settings, or maybe a portalsky with a moon model would look better? But before seeing those screenshots I never even noticed that the moon looks stretched when it happens to be in an upper corner of the screen - I usually don't look that closely at the corners, especially if the only thing shown there is part of the skybox and nothing immediately important (like enemies or cameras) So with panini the center of the screen, where you look at most of the time, looks bent/distorted (especially when moving), while with standard projection the screen edges (that you don't look at so much) are a bit stretched. I think the latter is the better tradeoff
-
Sad news, we lost another one of our own - Mircea Kitsune
covert_caedes replied to Bikerdude's topic in Off-Topic
The post by her friend linked above said so, and so does her furaffinity profile page. But even ignoring that, "not saying" does not mean "male" - just avoid using any pronouns then (like Bikerdude did) or use the generic they/them (like you just did). So everything we know (both from those furaffinity posts and the "not telling" gender here) indicates that Mircea Kitsune did not prefer male pronouns - we should respect that, especially in a topic that mourns this tragic death. (Side-Note: In case the comment in my initial post seemed a bit over the top, please keep in mind that there was at least one very disrespectful post there that has thankfully been deleted since) -
Sad news, we lost another one of our own - Mircea Kitsune
covert_caedes replied to Bikerdude's topic in Off-Topic
This fucking sucks, she seemed like a great person (and her FMs were fun) May she Rest in Power. Misgendering her (esp. when done intentionally) even after she killed herself because she apparently didn't feel accepted by the world is extremely disrespectful and IMHO completely unacceptable. -
TDM running on the Raspberry Pi 5 - is it possible?
covert_caedes replied to HairlessHeBald's topic in The Dark Mod
Does it have playable performance? By the way, you might be able to build TDM natively from source (https://github.com/stgatilov/darkmod_src), which should decrease CPU overhead (no translation from x86 to ARM). No idea if TDM works (or even builds) on ARM though. -
TDM running on the Raspberry Pi 5 - is it possible?
covert_caedes replied to HairlessHeBald's topic in The Dark Mod
Does glxgears work? If it does, what does glxgears -info print to the console? -
I thought the Linux users build it themselves But I forgot that building TDM isn't as straightforward as building dhewm3 due to the dependencies.. Anyway, updated the Github post with a Link to a Linux build, created on (X)Ubuntu 24.04, hope it will work on your system as well
-
Doom3 GPL contained most of the source of the script debugger that used to be part of Quake4. Harrie van Ginneken fixed it for dhewm3 by implementing the missing parts and we further improved it together (I maintain dhewm3). I ported that to TDM. It allows you to set breakpoints in script functions (by clicking to the left of the line number, where that red dot appears then), so when those lines are executed the game is paused and you can inspect variables in the debugger, or continue running the script line-wise (with those little buttons with the arrows at the top, or F11/F10/Shift-F11, see also the "Debug" menu. To continue running the game (until it hits the next breakpoint), click that ▶︎ button at the top. You can download a testbuild and read some more information at https://github.com/stgatilov/darkmod_src/pull/6 - it should work with the latest 2.14 Beta gamedata. Note that this is currently not officially part of The Dark Mod and I don't know when (or if) it will be merged. Might be after 2.14 if the changes are considered too risky or too much to review or whatever.