Dragofer
-
Posts
2631 -
Joined
-
Last visited
-
Days Won
157
Posts posted by Dragofer
-
-
20 hours ago, MirceaKitsune said:
I haven't added many speakers yet, hopefully this won't be a major issue... I know for visuals it does improve performance. And yes, I'll bring it up there if I go further into the subject later.
I mean it became literally less than 1 fps whenever I had a large speaker (i.e. wind) crossing such visportal boxes, so it's an engine bug. I think it's still working out for you because you might be using only smaller speakers, but it might be there's a different cause. Maybe @stgatilov
has some input on what might be going wrong here? -
[quote]
I remember someone expressing interest in how I create what I called "virtual cubes" out of vis portals, to have open outdoor areas be more performance efficient. Figured I'd share this screenshot which exemplifies a part of it.
I tested this setup and can confirm it to work well: As long as the edges of portals touch accordingly you can connect them together. I haven't testing T junctures (the edge of a portal laying across the face of another portal) since that seemed inefficient, currently I divide across intersections to create two portals in this scenario... if the engine tolerates T shapes I might unify some of them to make the calculation even more simple for the computer.
[/quote]
[Continued from the "So what are you working on thread"]
How does it work when you have speakers crossing such visportal cubes? My fps hits absolute rock bottom when TDM calculates sound propagation across them.Also, if you don't mind I'd move this visportal discussion to the newbie questions thread.
-
@JackFarmer
Ah, that little thing - I was reminded of it when I saw your cool submarine in The Lost Citadel. Who knows, maybe people will see it in a FM one day? -
@MirceaKitsune
I just remembered that ai_see is only for lights. AI_USE is a string spawnarg that tells AI what kind of item something is, i.e. a door or a suspicious weapon. If the spawnarg is - it's invisible to them. You can find all the AI_USE possibilities in one of the ai scripts or maybe the wiki. -
@MirceaKitsune
Either wipe the AI_SEE spawnarg on the ragdoll or deactivate the visual stim it emits. Both should be reversible ingame. -
@JackFarmer
I can't comment on anySpoilersubmarines,
you might be thinking of one of the excellent models created by ERH+?
54 minutes ago, MirceaKitsune said:I kind of forgot the command used to check performance. My other excuse is that I allowed myself to forget because I was afraid of what I might see if I used them
In your defence, cabalistic says drawcalls aren't as important as they used to be.
-
1
-
-
@MirceaKitsune
TDM natively supports debriefing videos, but I've never noticed it mentioning text. It should in any case be possible to modify the "next" button on the success screen to show a briefing slide instead of returning to the main menu, but I doubt you can do that without modifying "forbidden" .gui files. It'd be something to suggest to @stgatilov
for his menu GUIs rework.GUI scripting also allows some very basic conditional checks, i.e. what mission is active. Maybe you can check objective states or properties on ingame entities, but I can only go as far as saying that you could use notepad++ to search through all the .gui files to find existing examples of checks. Maybe you can find how the gui decides to mark objective checkboxes?
-
4 hours ago, nbohr1more said:
Does the "forceHighQuality" material keyword still work? If so, that should be usable to force menu's etc to bypass compression.
Yes, it works here.
1 hour ago, duzenko said:I think it's good that users have a choice here. Would anyone prefer hi-quality GUI backdrops over in-game stutter and freezes? It's not just VRAM issue, but also system RAM/pagefile too.
Your particular .tga might not make a difference, but there could be dozens in other maps.
Mappers do have that choice already, and that's when they provide either .tga or .dds images. But it gets overruled by default when the .tga's are compressed to .dds at runtime. As cabalistic says this is slow for loading and driver-dependent, and mappers might not be aware it's happening.
Maybe it's still considered a poor decision for mappers to use many custom .tga's, but maybe once we have pre-compressed normalmaps there'd be enough budget left to allow any .tga's to remain as they are by default?
-
On 6/26/2021 at 9:58 AM, stgatilov said:
- I don't understand what's in the images that you posted. I see gray rectangle in the second one, and gray rectangle with some outlines in the first one.
- Almost surely this is the problem of DXT compression in OpenGL driver, since you provide non-DXT data, and engine uploads it as DXT. It is possible that the problem does not happen on drivers of other vendors. You can workaround it by forcing high quality in material, or providing DXT-compressed DDS (it should work).
- It can be related to the problem with DXT compression on AMD that you had before you turned image_useTexStorage off.
1. I’m only showing a section of the sky in this thread in order not to spoiler.
2/3. Yes, I tried opening the same FM with a .tga background on my Intel GPU PC and the compression artefacts are less severe. The quality is like when I use a .dds image.46 minutes ago, OrbWeaver said:I don't think there's any bug here. DXT is a cheap and cheerful texture compression algorithm that works OK for most images if you don't look too closely, but it doesn't handle smooth gradients very well. If you want a large and smooth background image filling the whole screen, you need to disable DXT compression.
Setting image_useCompression to 0 will work for you (although it will disable compression for all images, so might increase GPU memory usage), but it won't help other users if you are using this image as part of a released mission. If you are planning to release this image and you want it to look good for everybody, you probably need the forceHighQuality material keyword.
The real problem I believe is that I’m giving the game a .tga image in hopes of optimal quality, but it automatically gets compressed at startup. On my AMD GPU the result happens to be even worse than when I use a .dds image.
I suppose you can work around it by making a material with forceHighQuality, but it doesn’t make sense to me that TDM compresses my .tga images. If I wanted that I’d use .dds images.
-
1 hour ago, MirceaKitsune said:
Objectives are meant to appear to the player, using a hidden objective just for a trigger feels like an ugly hack to compensate for a missing implementation.
No shame in using hidden objectives to achieve scripted effects. The objective editor is like a visual scripting editor that’s often considerably easier to use than scripting by hand or setting up cascades of entities carrying script functions.
-
56 minutes ago, MirceaKitsune said:
Hmmm, I see what you mean. I could do that but it feels kinda wrong: Objectives are meant to appear to the player, using a hidden objective just for a trigger feels like an ugly hack to compensate for a missing implementation. If nothing else works I can do that I guess, I will consider if I can make that work in some form.
Can it be confirmed however that there's currently no other way? More specifically, that notes cannot trigger targets upon being read, and objectives are the only thing that can scan whether a readable was accessed and target something based on that? If yes I at least know my options for sure. Also I'll probably make a report regarding this limitation, the next TDM release could use a proper trigger for readables from what I'm seeing.
Looking at an immobile entity in DR shows that its frob_action_script is readable_immobile_frob, which notepad++ says can be found in tdm_readables.script. One of the member functions there is handleCloseEvent(). This function calls another function that triggers the entitiy specified in the spawnarg "trigger_on_close", every time it's closed.
For TDM as a whole, it’s a matter of someone setting aside the time to make sure that all spawnargs that are implemented in the scripts and source code are also documented in the entityDef so they show up in DR. Or at least tracks them somewhere, like a general bugtracker ticket of “undocumented spawnargs”.
-
1
-
-
It doesn't have to be a painting, there are other ways to include a tribute. For example, Geep created a character inspired by grayman, and you could create an ingame location with a sword stuck in something.
Regarding Zerg Rush's painting, it's not sufficient to modify a copyrighted work to make it your own. You really need to check what the author says about how you may use it.
-
6 hours ago, stgatilov said:
Parchments are not included into backgrounds.
Just saying because when I uncommented the custom_title section and changed the image path the parchment was gone.
6 hours ago, stgatilov said:Usually when someone overrides main menu background, they do the same for difficulty selection and shop too.
My reasoning for that suggestion was that I think there are 2 kinds of backgrounds:
- scenes that look good when they occupy the left half of the screen in the main menu, like in the Hidden Hands series, but not so good if most of the screen is covered by i.e. a shop.
- more uniform backgrounds i.e. blue fog like in the Shadows of Northdale series which is good at bordering any menu.
I think having a choice between 2 basic macros depending on what type of background the mapper has, where 1 macro only affects menus with enough screen space to show a scene and the other macro affects all menus, would be suitable.
A further comment is that mainmenu_background_custom.gui should have a description of how to uncomment the windowDef, especially since a different comment system is used here (setting "#if 0" to "#if 1").
-
1
-
38 minutes ago, stgatilov said:
All effects?
I thought about having single macro like MM_BACKGROUNDS_ALL instead of many individual ones, but should it replace background on success and failure screens too?
And if not, then how should it be called to avoid confusion?
Maybe something like MM_BACKGROUNDS_META_ALLBEFOREGAME ?I think the most common usage would be:
- custom background for the main menu (pregame and ingame) and its submenus: Load/Save, Settings, Select Mission.
- stock background for everything else: TDM credits, anything after Start Mission (briefing, objectives, shop), success/failure screens and so on
The 2nd macro could assign the custom background image to everything.
Also, I think the parchment overlays should be kept by default. If a mapper is engaged enough to draw a new menu box they'd probably want to use the more advanced method.
51 minutes ago, stgatilov said:File mainmenu_background_custom.gui already contains a stub of GUI window:
Ah right, my TDM install's gui .pk4 doesn't contain this file so I was deriving it from mainmenu_background.gui
-
3 hours ago, stgatilov said:
It is deprecated, and will be removed soon.
This would be a shame, I think the GUI customisation system would profit from a simple & easy way to just drop in a custom background image that instantly replaces all of the stock menu effects in one go.
The new menu customisation system looks like it's very powerful for advanced effects and complete control, but could be tricky for a mapper who's not familiar with the GUI system and only wants to make a simple change like this. In this case he'd have to find out that you can't use a custom background image directly but need to make a GUI material with an appropriate blend mode (ok, seems this is not the case, but it seemed necessary after inspecting the stock menu), a GUI window containing this material with an appropriate rect size, and replace all the stock windows of every state with this new window. I think this is a system for advanced users.
-
It's maybe a bit buried in my last post, but setting seta image_useCompression 0 actually cures the problem: no more compression artefacts.
-
46 minutes ago, duzenko said:
1. What is your image_compression cvar?
With a currently .tga background and default darkmod.cfg cvars from updating to the main menu beta:
Can't see an image_compression cvar in my darkmod.cfg, and the console doesn't seem to know it. My other seemingly compression-related cvars are:
seta s_decompressionLimit "6" > seems to be something for audio files (max uncompressed sample length), so I didn't experiment with it seta image_usePrecompressedTextures "1" > setting this to 0 has no effect on the background and turns pretty much everything else into black rectangles/screens seta image_useNormalCompression "1" > setting this to 0 has no effect seta image_useAllFormats "1" > setting this to 0 has no effect seta image_useCompression "1" > setting this to 0 cures the problem. As sharp as ingame.52 minutes ago, duzenko said:2. Tried it in the .dds format?
Yes, I tried it in .tga, .dds and .jpg and made sure I didn't have both a .tga and a .dds in valid locations simultaneously.
-
1
-
-
For some reason, my custom main menu background image has huge compression artefacts when seen in the TDM menu. I took it from an ingame location using TDM's F12 screenshotting tool, then opened it in GIMP and exported as either .tga or .dds. Also tried .jpg.
If I open one of my .jpg briefing images from the internet in GIMP and convert it to .tga, that's perfectly sharp in the TDM menu.
Definitely quite weird, since I've seen plenty other missions with reasonably sharp ingame screenshots, and my screenshot looks good while it's still in GIMP. AMD driver issue?This is a screenshot of the foggy sky in the TDM menu, which should be completely uniform:
Compared to a screenshot of the same area in GIMP:
-
Some experiences I made trying to replace the stock background with a custom background image for the first time:
-
It seems there are 2 ways to achieve this: making custom background window defs (line 61) or applying custom title graphics (line 300).
-
I found the background windowDefs method first since it's higher up, so tried that first.
- This method is more complex, considering the setup that's required outside of the custom_defs file, so it should probably be shown after the custom_title method.
- There was also trial and error with modifying the windowDefs, so it'd be useful if the GUIs automatically reloaded themselves when you switch between states, if performance allows, so that it gets easier to try out changes without restarting TDM.
-
Then I tried the custom_title method, which is much simpler but has some downsides:
- The menu parchment gets replaced too - can't see a way to change only the background, which is what I think most people who would use this simpler method want.
- When the player clicks into another menu, i.e. Options, the background is the default one again.
-
I found the background windowDefs method first since it's higher up, so tried that first.
-
It seems there are 2 ways to achieve this: making custom background window defs (line 61) or applying custom title graphics (line 300).
-
Found an edge case:
When multiple things (i.e. doors) have a common bind parent (i.e. a carriage), they all highlight together even though they don't have any direct relationship to each other. Maybe common highlighting should only be for entities that are bound to each other?
Sometimes you need to bind doors to something, for example if you want them to move on a rotated axis or if you're making a vehicle.
This happens in a test map I posted to the dev forums today ("Fog obscures transparent textures").
-
- Popular Post
- Popular Post
An encounter with some rather unsavoury types is taking shape...
-
20
-
6 minutes ago, TheUnbeholden said:
Isn't the Painters Wife now upto version 3 according to the ingame mission downloader?
Internally the downloader can only work with integers, so v1.1 = v2 and v1.2 (current) = v3.
If the archive is 175 MB instead of 500+ it's the current version.
-
@MirceaKitsune func_statics are entities, so there's no distinction there. AIs can only walk on anything that's an entity if there's some kind of solid worldspawn brushes reasonably close to the surface, i.e. MC or nodrawsolid or a solid visible texture. Brushes converted to func_static will be counted as entities.
RIT is basically so that you place central nodes (usually a path_wait with wait 0 and wait_max 0) that target multiple different nodes in a room representing various activities i.e. sit in a chair, look at a painting, warm hands at a fireplace. This means whenever the AI goes into that room it does something different, usually, from the last time so that they appear more human.
-
1
-
-
2 hours ago, Geep said:
3) Ramps of solid nodraw, which some prefabs have, to also ease player movement
Definitely this if the player is having trouble navigating the stairs or other map features, though for the player it's easier to have steps than a ramp: players need that for actual physics, while AIs only need MC ramps to tell them they're allowed to go there. Simply encase each step in a brush that reaches down to the step below.
You can keep the nodrawsolid steps as worldspawn, then you won't need to MC the steps anymore.
-
2
-
Newbie DarkRadiant Questions
in TDM Editors Guild
Posted
The LOD system doesn't seem to support toggling lights, at least that's what came of an earlier discussion on Discord. Even if it did, the best you could probably do with lights is setting them to noshadows after a certain distance, but you can just as well set that on the models being lit up by the light. Switching the light itself off would probably require very long distances, since something like a streetlamp emits a lot of light that'll make the LOD very obvious.
Really, the best thing you can do for performance is preventing such long sight lines in the first place by designing your architecture such that it naturally obstructs them. Not only does this perform far better, it also feels realistic in the sense of a medieval city where everyone builds wherever they can get a few bricks in, and it should make for more interesting gameplay when the player can navigate through and around buildings (like Life of the Party) rather than walking on level ground most of the time.
Melan has made an interesting guide on how to quickly layout and build convoluted city streets in his behind the scenes thread for Talbot 3: Fiasco at Fauchard Street, maybe you'll find it helpful?