Search the Community

OK here is a mockup: zzzz_subdark.pk4 It currently doesn't work as an overlay to movies or purely gui elements ( probably need to toggle back to the simple behavior on those )... but it works to prevent background lights from making the text illegible. Try it out

the definition is just using backcolor set to all black with 50% alpha should be able to create a material with a translucent filter effect and replace backcolor with background /material/path

All the space we need is already available in this screenshot: Leave ~two pixels top and bottom for the text. Move the widget up by a pixel or two. Forget about this for the moment. Just leave the widget outside of any backgrounds (if you aren't sure how to create a dedicated background for it). Does it? Probably I mixed up things at some point, I don't know. My current white is ok. Added to the list of things to check in the future.

I gather you're looking to shorten the backing fields, to improve world viewing. Reasonable. Certainly I could put a translucent box behind the widget, much as you have shown. Except, for reasons discussed above, I can't spare that many pixels vertically. So the widget top edge would be at the box top edge, and the widget bottom edge would still be close to the top of the text chars. Probably a tight fit on the sides would look better in that case. EDIT: Maybe the widget can jut more into the gap between fields, so a few pixels can be stolen. I don't think I can get the gui itself to draw a translucent background in an oval, instead of a rectangle. The widget image itself could have a translucent background within the oval, but it would be hard to match alpha'ing with the text backing field. Alternatively, as mentioned before, you could forgo a widget background and just have an opaque widget interior. Maybe 2 shades of gray to denote the sector. BTW, I noticed your white widget had a yellow center dot. Was that on purpose, or just an artifact of making a yellow version?

If you like the above idea, and since you are used to working with the gui, can you make it so that only the text is surrounded by the background and the bottom of the widget is almost touching the top of the background?

How about we proceed next with something like this? If done right the widget can have its own background, and blocks will naturally stand out from one another. Please note the above pic comes from a quick an dirty hack to illustrate the idea so I won't share any code. Backgrounds can eventually be replaced with images with round corners or whatever.

I know this is semi on-topic and likely guaranteed to never happen. But I still can't help dreaming of TDM someday getting a cinematic dialogue system like in DeusEx: If you get close to or frob an important character that has something to say, movement is blocked and you go into a third person view staring you both down while the music changes, every few lines the angle shifts so you see yourselves from a different direction as you talk to each other. The most awesome thing would be dialogue options still, those I'd dream of seeing even more. Imagine being able to tell different things to a character in a prompt, changing some choices based on what you say! Could be used both as a simple store for street corner vendors... or to tell friendly AI to take different actions like waiting or following you or fleeing, I know TDM doesn't go for those types of missions but I still see it as a worthy possibility. Technically both could be done with a script. So if I ever need it I might put together such a dialogue system myself in a custom entity. Would definitely be fun to see someone else experiment with this through the new subtitles though.

Hmm... the background image seems to be doing a naive relative attenuation. I wonder if we could configure a shader with a max rgb that is always some percentage darker than the text color min ( value, ( textcolor * 0.7 )) I'll see if I can locate where the behavior is defined.

I just recently became aware of this feature: https://wiki.thedarkmod.com/index.php?title=Particle_collisions_and_cutoff Unfortunately I completely missed it, as when I went to create weather effects in my FMs I just followed this (which doesn't mention it): https://wiki.thedarkmod.com/index.php?title=A_-_Z_Beginner_Full_Guide_Page_3#Rain_and_Snow The point of this thread is to a) make people aware of it and b) gather feedback from any mappers that have used it so we can get some mapper-focused documentation in the Wiki. The page above is great for background information about how it works, but as a mapper I really just want to know: What are the limitations of this (i.e. when should it be used and when shouldn't it be used)? Why isn't it the default behaviour? Why all this work to get it into the map? What built-in support for it exists (particle definitions, materials, etc). Do I need to create all this stuff myself? Texture layout vs. Linear layout: what's the difference in the end, pros/cons, why would I use one over the other... Why does it need a separate command (runParticle)? Can this just not be bundled in with dmap? A clear, step-by-step instruction on how to implement it in a map from beginning to end using a simple use case. Tagging some users who have relevant experience with this: @stgatilov @Goldwell @Amadeus

Creating a new thread for this as it was being discussed in an old beta-testing thread starting here: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/&do=findComment&comment=490751 I suppose the main questions are: when should this spawnarg be used, if at all? why was it introduced in the first place? Can we get it documented properly on the Wiki so misuse isn't propagated? @stgatilov @Dragofer

I think the positioning circle should be part of the subtitle block, not positioned above it. There should be enough space left above the subtitle block with background to include it.

The widget needs a background or a shadow or outline otherwise it cannot be seen in some situations. I am not sure how to deal with this. At this point, I think you are leaning to: The existing background and background color (but from your code that includes a narrower background for barks) Original white text color Newest widget in white color closer to the text it belongs to, similar to the original More centered text

Tested it and it doesn't look as good. Similar to v3. Sure. Settle on an style first please (background and color). Overlapping elements is what looks bad. I think players should also be able to toggle the situational graphic off and on. It is well executed but it draws too much attention. I rather not focus on it but on the text and my surroundings. Personally, regular subs is all I need but hey, that's just me.

I wonder if you could test 9x versus 4x-diagonals and 4x-non-diagonals? Maybe the extra 5 renders don't add much. There probably is some minor performance effect. I think you're still showing the widget too high, so it seems to be associated with the wrong subtitle. I prefer @stgatilov's original vertical positioning, even though it pushes the widget's lower edge against the top of the caption lettering. I wasn't sure what you where trying to point out as a problem... was it the word wrap? Yeah, the automatic word wrap with centered text can look ugly at times. An FM author can choose to insert a manual line break in that case. I do that routinely all the time for barks. Since padding is part of the background box, sure. It occurs to me now that maybe, to improve the appearance of text centering, the background box should also have equal-size padding on the left. That is, the location and size of the inner box is unchanged, but the outer box is wider and its origin shifted left, so the inner box is centered horizontally within. The padding can certainly be made smaller. I imagine the seed value of 17px was for a worse-case character like "W", that was then rounded up to 20. We could shrink it by: - choosing the seed character as the widest that might actually be at the end of a line followed by space to cause word wrap. Probably "w" or "A". - not rounding up - scaling by the compression aspect ratio I'll try to come up with a new number. No problem here with having the background by default. But recognize there's a compromise between world visibility and text readability. Can't we make it possible to turn the background off for people who hate it so much that they avoid using subtitles because of it? "...visible in all circumstances" may be too high a bar. The simple implementation would be a single CVar that toggles the background on/off and possibly, conversely toggles fake drop shadows off/on.

Padding on the right is necessary because text rendering engine allows one-character overflow. And trying to fix it breaks many readables in many missions. So unless background is disabled, padding will stay. As for how large it is, I think it was minimum plausible at some moment. But then the font was changed and maybe it can be reduced now --- history digging is required here. I believe background will stay by default. There is no other simple way to make sure text is visible in all circumstances. As for size and spacing, I doubt you'll be able to reduce anything without making font even smaller and potentially less readable (especially in Windowed mode).

And here is v4 "Geep", based on your code from four posts above. Background enabled Text centered New graphic White color (let me know if you want to test other colors) Choose between any v3 or v4. We will take your choice to @stgatilov for a sanity check afterwards. EDIT: Download removed. Check this post for the latest version.

I will take a look this coming week. In my heart of hearts, I'd rather make "background or not" a user choice. The simple version of that wouldn't be too hard: just a CVar settng the backing field visibility. The more sophisticated version, where no-background implies fake-drop-shadows, requires more thought to make it live with the backing field code.

Ok, no problem. We shall request @stgatilov's assistance in due time. I need you to evaluate yes background or no background and have a final word for 2.12. Take your time, please.

Zip re-uploaded in the above post. I forgot to remove the background.

Sorry I don't know if you mean whether yellow have a positive or negative edge in that case. Without a proper thick outline issues will always popup here and there regardless of the color, white with newspapers, yellow with books or scrolls... Having a background is the safest bet, but for small recurrent pieces of text such as barks, the current background if off-putting.

Yellow have an edge, yes. We definitely can't go wrong with white. Other than the graphic, which I think I cannot innovate further, I wanted @Geep to experience his work without backgrounds. To background or not to background, a tough call for different reasons explained. Fortunately this can be modded to an extent. I provided working samples. Download a zip, unzip it and place the "gui" folder in your TDM root. Delete the "gui" folder when you are done. No, I merely print the same text three times: 1x black a tad top-left, 1x black a tad bottom-right, 1x light grey centered. I think you better experience it for yourself, and draw your own conclusions.

I guess added sector is enough to drop the idea of more thickness on lower half of the ellipse. It is possible to expose colors of background and text to cvars. If the location ring image is black-and-white with varying alpha, then I suppose it should be possible to expose its color too (by modulating configurable color).

Thanks, @Wellingtoncrab. Yes, @Geep, @stgatilov and @datiswous are doing a great job with the subs. Having no background to rely on one may argue yellow is the worst choice since yellows are supposed to be more common in the TDM world however, from my limited testing, I detected occasional interferences with both white and yellow colors. White feels colder and yellow feels warmer. I, for some reason, find yellow more welcoming and less out of place. We could try with different shades of yellow. Find below v3 in white color for completeness sake. EDIT: Download removed. Check this post for the latest version.

There can be up to three blocks and each block can contain up to two lines of text, right? Plus the graphic at the top when appropriate, correct? If that's so then the new sample attached should be ok. I take the assumption that it is not possible to measure the length of each character and have a background that fits the the length of the text and as such, I once again removed the background but now added a kind of outline (fake drop shadow). Unfortunately the current font is sometimes thick and sometimes thin and the outline would be more effective if we had a typeface with a more consistent, thick outline. Subs are displayed by limited time and the more clear the font the faster we scan the text. I know you want the background because you are concerned some words cannot be read in some situations but my main concern is about those players that wouldn't mind having subs but end up disabling them simply because they find the whole approach too obtrusive. In my sample I went from pure white text to a light grey shade. Yellow color works quite well too for the subs. I understood what you were going for but it didn't land here. I haven't thought of alternatives for the graphic but I am impressed with some of @MirceaKitsune's gui/hud work so perhaps he can come up with different ideas. EDIT: Download removed. Check this post for the latest version.

I was searching for the music name and saw the file name `vic_echo_bathroom.ogg` mentioned here. Tried shazam but found nothing