Jump to content
The Dark Mod Forums

duzenko

Active Developer
  • Posts

    4149
  • Joined

  • Last visited

  • Days Won

    50

Posts posted by duzenko

  1. 49 minutes ago, MirceaKitsune said:

    https://bugs.thedarkmod.com/view.php?id=5668

    Is there no chance that we could get hide_distance working for lights as well? My FM's have a slightly more open design which I didn't wish to sacrifice, and to keep performance okay I need to use hide_distance on some meshes with many func_portal ents to close all doors and windows at a distance. This still doesn't help enough, which is why I preemptively set a hiding distance on small lights too in case we're lucky and this will be fixed.

    I don't know the code but lights can already be turned on / off by triggers. Is there no easy way for the engine to use the same system to disable a light source based on distance, same way it disables rendering a mesh? I hope this can be looked into in some form.

    Lights don't draw anything by themselves

    If there's an entity touching the light it will still emit all its surfaces for e.g. depth pass, ambient pass, etc

    I understand your idea but IMHO hiding entities (or replacing them with billboards) is more beneficial overall

    You would have to produce a test map where distant lights is a major performance problem for me to investigate this any further

  2. The emitter entities being the focus of my effort right now, I can see that then emitter itself gets 'hidden' properly

    The next stop is where its surfaces are emitted by the frontend

    EDIT

    The render entity is removed, but instantly re-added from idFuncEmitter::Present. I'm not sure if we need to check for visibility in this code, or it's better done in some other place. E.g. if the emitter should be rather inactivated, etc.

  3. 1 hour ago, stgatilov said:

    Regarding the error that @duzenko got.

    The way "image_preload 0" works makes no sense for CPU-resident textures.
    I suppose if image is CPU-resident, then it must be loaded immediately even if someone has enabled not-officially-supported on-demand texture loading.

    Of course, I will fix that tomorrow unless someone beats me to it

    • Like 1
  4. 1 minute ago, kingsal said:

    @peter_spyReally? Thats great. Do you have an example of that material set up? I swore I read somewhere that doom can't do alpha blends, maybe that get patched into TDM at some point.. I dunno.

    @nbohr1more @duzenko I can throw in some lights and other func statics in the test map so we can test stuff like that.

    Here's a quick draft by biker if you're interested

    https://cdn.discordapp.com/attachments/792307226399604746/865627549782114305/dkotest.map

    It's being discussed on Discord as well

    The biker's version does not load for me on svn due to @stgatilov's ongoing work in that area

  5. 1 hour ago, kingsal said:

    @nbohr1more @duzenkoI could probably cook up a simple test map this weekend. I imagine we want func_emitters, SEEDs,  and maybe a couple various func statics.

    Side note: We do not have fade in/out capabilities currently. Maybe because the engine can't do alpha blends? Having that would prevent a lot of that annoying popping in and out on hide. Is it possible to add this to the list of things to explore? 

     

    At least have a look at it, maybe we can kill more than one sparrow with one cannon

  6. I think the time has come to "do something" with the console text layout, prompted by user feedback on discord

    I suppose since the original console was designed for 17` 4:3 screens, it does looks weird to modern eyes. What is the common setup these days - 24' 16:9? With increasing share of even wider and bigger screens.

    As always, I'm willing to minimize the changes in the code (unless the change is deletion, which I can never have enough of ;))

    Unless someone else wants to step up, I'd like to make the following changes

    • configurable console line length (text buffer width), which would automatically make symbols narrower (or, quite unlikely, wider)
    • configurable number of lines to show in the console -> make lines more dense or sparse
    • maybe also allow the console to take 1/3, 2/3, etc vertical space when dealing with large amounts of text info
    • unicode?
    • Like 3
  7. 11 hours ago, geegee said:

    @duzenko

    1.  opening TDM, prior to mission loading:  GPU 1 - copy (nvidia)

        after mission loaded:  GPU 1 - 3D (nvidia)

    2.  laptop:  1920x1080

         desktop:  3840x2160  (a cheap LG TV - good for my failing eyesight, esp. when mapping, but looks like washed out crap compared to the crisp clear color of the laptop)

    nvidia control panel can allow me to choose "preferred graphics processor" but ignores that when loading games.

    Thanks

    The same build that fails on the laptop still works OK on the desktop, right?

    Laptop is running Windows?

    I could try my nVidia laptop later this weekend, but can you try the latest drivers from Intel, nVidia, and Asus website in the meantime?

    Ah, and also try changing the r_glCoreProfile to 0 in the .cfg

  8. 5 hours ago, stgatilov said:

    Given that the engine works only with 8-bit encodings, it is almost certain that no matter what you do, some paths won't work.

    It's a little more complicated than that

    If we fully supported 8-bit ANSI encodings, then file paths in local user locale would still work. But they don't which implies that TDM uses a fixed encoding conflicting with the system encoding

  9. 2 hours ago, freyk said:

    Using appdata as folder for the fm and saves, the data will not be placed in the documents folder. That data will be placed in c:\users\username\appdata. When you open that location, you see that other applications place there profile data too. 

    Users will not notice any differences, because they dont see the fm folder.

    I dont want to see a "my tdm" (or any) folder in my homefolder. That is placed in a hidden folder in my homefolder. that is the conventional location. (Also in other OS'ses)

    Tdm will use "all folders in one directory", because the fm folder is referenced in the config.

    And where i expect it to go wrong, is during the use of the applications outside TDM. Like in the updater, installing/updating the three standard missions. Or in DR.

    But both can be solved by using/changing referrences.

     

    AFAIK the windows standard is to put the save games in user\[documents\]savedgames\gamename

    https://docs.microsoft.com/en-us/windows/win32/shell/knownfolderid

    Quote

    Btw Who uses a username with spaces? To me, that was always asking for technical problems in the early days, when some applications didnt used environment variables.

    It's not just spaces, it's all non-ASCII symbols too

  10. 1 hour ago, stgatilov said:

    You mean installer does not accept such directory name?

    Well, this installer check can be disabled in principle.
    Although we will probably get a bunch of bugs due to such installation path...

    Unfortunately the installer accepts the invalid paths but the game fails to load IIRC

    I posted in the installer thread not long ago

  11. 1 hour ago, stgatilov said:

    Pretty sure you will meet more problems if you continue playing.

    If you want to have separate TDM installations for several users, then you can simply install it into individual users' home directories.
    That will fully comply with Windows location conventions.
    In fact, Python installer does exactly that, unless you choose system-wide installation.

    That's what I tried actually but it simply won't work for user names with spaces and non-ASCII characters

  12. 9 minutes ago, Springheel said:

    The dev build probably includes things that are specifically excluded in the release build packaging process, which might explain things.

    Could you elaborate on that? Do we have textures in release builds that don't exist in assets svn?

×
×
  • Create New...