Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16540
  • Joined

  • Days Won

    31

Everything posted by greebo

  1. Oh man. Can you share that map with me, and does it happen every time?
  2. I'm not familiar with this bug. Can anyone confirm this behaviour?
  3. New pre6 release is available in the first post. The playerstart visibility is fixed, and I could finally resolve that bug causing the weirdly stretched geometry in the render views.
  4. I can't reproduce this. I'm using the portable version linked in the first post to make sure my local build is not different than the uploads, but the player start is not disappearing. I run DarkRadiant.exe, right-click to create a player start, and it's there. Pointfiles are working too for me. Can anyone try this and provide more feedback, please? @Frost_Salamander Is this something that is only happening in pre5, or are earlier pre-release builds affected too? Link to pre4 portable, just in case: https://drive.google.com/file/d/11WJIyLq8LOB2RqF0daH8HidBpytYJtcs/view?usp=sharing
  5. Yes, I've noticed those too, but couldn't pinpoint it yet. Information about reproduction would be appreciated, I'd like to fix that as well. There must be one sequence of entity selection operations that triggers this, and which I obviously haven't covered in the unit tests.
  6. Next build (pre5) is available in the first post. This should be better now, I reduced the frame buffer count from 3 to 1. I'll get back to this in case the front end render pass is ever going to be multi-threaded, but for now it's safe. This new build has reduced map loading times (by 10-20%) and front-end render times (by another 10%). I still haven't been able to track down the geometry issues (stray diagonal lines messing up the view). They can appear right after map loading as well as in the middle of editing - I'm grateful for any insight on how this can be reproduced. I had it happen on me, but I couldn't find the reason so far.
  7. DR is using triple frame buffers, and this is indeed quite expensive. I'll try to see if this can be reduced without compromising performance. It was set up this way to be able to support threaded rendering, but as there's no threading yet in the renderer, I might as well get rid of the triple buffer, and reduce it to one. This should save a few GB of system memory in large maps.
  8. I think this must be DR's current limitation to 6 shadowcasting lights. If more than 6 lights are shadowcasting in a view, DR will choose the 6 nearest lights. I assume when changing the camera angle, a nearer light comes into the view and another one stops casting shadows. I can either try to get more lights to cast shadows, with some rearrangement of the shadow map texture, or try to choose the 6 lights in a better way. Can you maybe share the map and camera position of those screens? I'd like to check these out. Not broken, just not supported yet. There are quite a few renderer features that haven't made it into DR yet. Maybe next release, it all comes down to free time and motivation.
  9. New pre4 build is available in the first post, with more fixes to the things mentioned in this thread.
  10. I could reproduce that problem now, with my Github account. I'll see what I can do to fix it. Entry: https://bugs.thedarkmod.com/view.php?id=5947
  11. I have to test this on another machine some time, one that doesn't have credentials saved at all, to have any chance of seeing what's going on. Obviously there is something saved in the credstore, DR is retrieving non-empty strings for username/password, otherwise the message wouldn't be there.
  12. Problem is solved in source, the next pre-release build will include that fix.
  13. No, the changes should and will only affect brushes that have duplicated planes on them, which can happen only when loading legacy maps. DR never created or saved brushes like this. I didn't even know that this was possible until I encountered this brush in alphalabs. It's also curious that DoomEdit doesn't correct the problematic faces when changing or saving the map (it continues to complain about it when manipulating the brush), so it just preserves the duplicated planes. It's relying on the engine code to weed them out during dmap.
  14. When loading that brush, DoomEdit just spits out this in the console and continues: The game loader deals with brushes on several occasions, for instance the dmap code will send another warning, removing the second duplicate: if ( sides[i].planenum == sides[j].planenum ) { common->Printf("Entity %i, Brush %i: duplicate plane\n", b->entitynum, b->brushnum); // remove the second duplicate for ( k = i + 1 ; k < b->numsides ; k++ ) { sides[k-1] = sides[k]; } b->numsides--; i--; break; } DarkRadiant's brush BREP code will reject the brush, and the code doing that is very old, I'm pretty sure it has already been in place when we forked GtkRadiant. I'll try to adjust DarkRadiant to not remove the brush and to treat it the same way as the game code.
  15. Yes, I can confirm the problem in alphalabs1.map, the brush that is missing in this screenshot is primitive 9447. It is a brush with 9 faces, but 3 of these face planes are redundant. Obviously the brushDef3 is still valid for DoomEdit, but DR regards it as degenerate. I'll see what I can do.
  16. I'll try to check it out some time, I have to find the D3 files first. I'll create a bugtracker entry: https://bugs.thedarkmod.com/view.php?id=5942
  17. It's been over a decade since I last tried to open a vanilla map, but it used to work. I don't even have the original game PK4s at hand anymore on this laptop, I'm afraid I can't even test this here. Is there anything written in the console about missing resources or similar? Are the project settings defined correctly?
  18. A new 3.0.0pre3 build is available with a couple of fixes, see first post.
  19. I just tried with MFA enabled on my own Github account. It doesn't prompt me for anything whatsoever, I assume that's because the locally stored auth token is sufficient for pushing content. It's difficult to see what's going on between git and the remote server without debugging or seeing the network traffic. Not sure if I can do anything here. Do you happen to have a gitlab repository, perhaps, to see if it's working for you there?
  20. I am familiar with this problem, but I haven't been able to track it down. It definitely has to be fixed before release, it's corrupting the view. I assume it's a problem in the synchronisation code that is managing the geometry data stored in the GPU buffer. At some point, things can go out of sync and those stretched geometry appears - it disappears once the map is reloaded. Everytime of the few times it happened on me, I tried to repro it but I failed, so if anybody can give me any insight on repro steps, I'd be grateful.
  21. Ambient lights are working now, this will be part of the next pre3 build.
  22. Can you please show me the log file when that happens? Maybe I can spot something.
  23. I downloaded Down by the Riverside and had King of Diamonds downloaded earlier, opening these maps to reproduce the problem. I tried with my recent build and with the pre2, and while DR does eat a lot of RAM (it shows 5.6 GB in Task Manager) when switching to lighting mode and shadows turned on, it stays that way and doesn't kill the process. Memory figures stay at 5.6 GB wherever I fly around in the level, regardless whether I'm in lighting mode or the regular fullbright mode. Can somebody confirm / try doing the same? Open DR pre2 with the project setup pointing to "river" or "kingofdiamonds". Then File > Open Map from Project... and pick the kod.map or the river.map, respectively. When moving around 3D view it stutters a bit as new things come into view, RAM is increasing, but as soon as DR has "seen" everything, memory consumption should stay constant at about 5-6 GB (at least for me).
  24. While some lags when zooming out and bringing previously unrendered things into view might be explicable, it shouldn't eat up your RAM completely, so this sounds rather severe. I'll try to look into that.
  25. Usually Git for Windows will store the credentials of the remote in the windows credential store, something like git:https://github.com. If DR can find that entry, it will use the credentials from there. But maybe your git client is not storing anything in there? Anyways, the authentication entry box needs to be implemented some day.
×
×
  • Create New...