Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Days Won


greebo last won the day on April 9

greebo had the most liked content!


321 Legendary

About greebo

  • Birthday 11/26/1979

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    conduction band
  • Interests
    Physics, Sports, Guitar, Coding

Recent Profile Visitors

17019 profile views
  1. Oh man. Can you share that map with me, and does it happen every time?
  2. 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.
  3. 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
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. New pre4 build is available in the first post, with more fixes to the things mentioned in this thread.
  9. 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
  10. 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.
  11. Problem is solved in source, the next pre-release build will include that fix.
  12. 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.
  13. 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.
  14. 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.
  • Create New...