Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited


About anotak

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. anotak

    PNAMES/TEXTURE1/2 sucks.

    so it uses a hashing function (Murmur2 in particular) to get filenames to be represented by 64 bits i thought about doing this before. i originally just discarded the idea because there is no real way of handling a hash collision (within DB's existing architecture, i mean). i didn't think about the fact that maybe a collision is so unlikely that it's not worth worrying about too much? but i'm not sure i love that approach. after doing quite a bit of math myself and then finally remembering enough about probability to come up with the right search terms, i found the correct answers. so, like, if you have 6100 textures your probability of a collision is 10 to the -12th. and the consequences of a collision are unclear? i'm not sure i want to unleash a hard-to-track-down bug that has a chance to wreck someone's map with a 1 in some near-trillionish chance? and that's assuming the Murmur2 hash used produces entirely uniform values. which, this is quite a bit outside my area of expertise, but i suspect it does not (?). in which case the probability of a collision goes up? maybe? how much? i don't really know? a quick google gives this stackoverflow answer, but unfortunately it is about the 32bit version of Murmur2, which is unhelpful. there's stuff like this, which might affect things? apparently there's a Murmur3, which fixes that particular flaw. and if the probability is much higher, how easy would it be to debug the resulting problems? seems like a nasty can of worms there's also just the whole, calculating-a-hash-thing isn't free, and one of my goals with DBX has always been performance. i haven't measured how this affects things at all though, and my instinct says it's "almost free", but i know better than to trust my instincts on this kind of thing, it must be measured. idk, i'll have to think on this. i really don't love the idea of "bad things happen but only this tiny percent of the time, and that's fine and we accept it". edit: and yes, hash collisions are a solvable problem, but i have to fight other conflicting aspects here (the Plugin API, my own time/effort put in, etc). i'd have to rewrite a loooot of stuff it seems. as far as i can tell, MAX-ED just didn't worry about it in GZDB.
  2. anotak

    PNAMES/TEXTURE1/2 sucks.

    if this doesnt turn into a bikeshedding festival by tomorrow if theres some solution, i could probably do the work on dbx to support any option that isnt horrible (or would be cool w maintaining it if someone else implements it) however having texture names be longer than 8 characters would be a clusterfuck to support in the doom builder 2 family of editors (and probably other software). a lot of stuff relies on being able to treat the texture names like unique 64-bit numbers (because that's what 8 characters is, actually). that intersects with with the whole maintaining-compatibility-with-the-existing-plugin-api-thing. i know this sounds silly, but, it's by far the most infeasible thing in your post. edit: fuck it here's my anti-bikeshedding measure if u can get me to agree about a standard with one (1) person who will actually implement it into a non-zdoom port (so 2 total people, counting me) then i will implement it into dbx
  3. anotak

    Doom builder 2.3 crash/Object error

    ok thanks, the logfile helped me figure out what's happening. it should be fixed in the next version. before then, as a work-around for you: it should work fine if you go into the regular sectors mode (default hotkey: S) instead of the "make sectors" mode sorry for any inconvenience
  4. anotak

    GZDoombuilder slow down on big maps

    hey, this may not solve your problem with GZDB, but you could try a different editor like DBX? (full disclosure: i'm the maintainer of DBX). DBX has less features, so it may not be able to do what you want, but it tends to run faster than GZDB at many things. But it has a similar interface to GZDB, since they are both based on DB2. link here:
  5. less features mostly, but much more responsive, less RAM usage, UI requires less clicks dbx is basically db2 but with bugfixes, less crashes, and lots of optimizations metaphorically, gzdb is one of those swiss army knives that's got everything on it, like a can opener and stuff. dbx is better at just being the knife, but it doesn't have a can opener. there are mappers who use both, depending on the situation.
  6. hey, sorry, i really need to update that error message, it was accurate when it was first written by CodeImp like 10 years ago, lol. https://www.microsoft.com/en-us/download/details.aspx?id=35 you need DirectX 9.0c, because 11 isn't backwards compatible, and 9.0c isn't included in windows (you can have both 9.0c and 11 installed at the same time, just fine).
  7. new version coming in the next few weeks hopefully the big news is be the lua scripting plugin i've been working on that will hopefully let people easily design their own tools and do all sorts of fun things
  8. anotak

    Doom builder 2.3 crash/Object error

    hi, i'm the dev of doom builder x. i'm sorry, this looks like a bug, i'll try to get to work on fixing it. i have some questions to help me with that, if you're okay with answering: what format map are you working on (Doom 2, Boom, Eternity (Doom-UDMF), Zdoom (Doom in Hexen), etc)? when you say "name" the sector, do you mean tag or something else? did you only have 1 sector selected or many? do you do anything else beforehand, or does this just happen every time? would you be okay with sharing the wad file? can you share the C:\Users\richardh\AppData\Local\Doom Builder\BuilderX-lastcrash.log file it mentions
  9. anotak

    Which monster do you neglect when mapping?

  10. anotak

    Post Your Doom Picture (Part 2)

    (level geometry is an_mutt's port glacia)
  11. anotak

    Post Your Doom Picture (Part 2)

  12. anotak

    Post Your Doom Picture (Part 2)

    more doom builder plugin progress
  13. anotak

    Post Your Doom Picture (Part 2)

    another hint at my in-progress doombuilder plugin also another another hint
  14. anotak

    Announcing AJBSP

    fwiw doom builder 2 & children always automatically make several backups. during saving, the initial write is also to a temporary file which is only copied over the original upon successful completion of all operations. you never answered this question