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

zokum

Members
  • Content count

    199
  • Joined

  • Last visited

Everything posted by zokum

  1. Doom was basically too big. Nowadays one could create something in Linux that sets up a ram disk and downloads it, but that wasn't feasible back in the day. You might be able to make a "stripped down" version that only runs e1m1 and e1m2 or something along those lines. Remove all the unused graphics and you might just be able to squeeze it in on a floppy.
  2. zokum

    Doom challenge: Shotgun only speedrun

    Tyson runs.
  3. zokum

    Doom challenge: Shotgun only speedrun

    The Cyberdemon has 4000hp. 100 shotgun shells will do an average of 100*7*10 damage if all shots hit. So about 7000 worth of damage. This should be a fairly decent margin of error for taking out the cyber. Adjust the route to include getting a backpack and ending e2m7 with 100 shells. New run categories are really only interesting if they force you to take different routes / use different strategies. Even without a backpack, infighting lost souls should make it viable. Rocket max would be an interesting category. Allow only rocket launcher and fists, not even chainsaw. Personally I tend to prefer "weird" categories for multiple maps only. The exception being tyson. It's incredibly boring no matter how you do it. Respawn is kinda meh too.
  4. zokum

    Things about Doom you just found out

    E3m4 might have had the episode 1 tech style bars, and it looked fine back then. Maybe later the map was changed to be more hellish, and we ended up with this oddity. Who knows. E3m4 is one of the maps I think Sandy designed from the ground up, it's not a design originally started by Tom Hall judging by the look of the map.
  5. zokum

    Things about Doom you just found out

    The games have several "impossible" areas. Another good example is the bar doors on e4m3. Quake also has similar areas.
  6. zokum

    ZokumBSP development

    Figured I should post/blog a bit about my ongoing development of ZokumBSP and the proces around it. I'll mostly cover thing that are specific to ZokumBSP, but there will be the occasional post about code and algorithms that can be used in other nodebuilders. The current release version is 1.0.9. There's a beta version 1.0.10 bundled with Doombuilder X with a few more features.
  7. zokum

    ZokumBSP development

    I've been working on the partition tuning algorithm and here's some test data for e1m1 to try out. The general idea is to add some of this code to be optionally turned on in zokumbsp. Some authors might prefer their maps to be built in this manner than the standard way. I am a firm believer in giving tools to mappers and let them decide what to should be done with their creations. This is an early version and fairly hackish, and there might still be improvements to be had. It is incredibly slow due to a fair amount of brute force involved. Use slade 3 or something similar for this. I chose e1m1 since we all know it and the slime trail near the zig-zag is easy to find. It's not perfect, but it's not half bad I think. Modify the following lumps in doom.wad e1m1.wad (save it as e1m1hax.wad). NODES: 162: Partition X: 3272, Partition Y: -3352, Partition X Diff: 4020, Partition Y Diff: -5318. (non purist tweak below) VERTEXES 437: X: 3455, Y:-3494 SEGS: 438: Angle: -19128 473: Angle: -19176 Note that the angle already stored in those segs are probably a bit off due to the angle bug in DoomBSP. These are merely corrections to make it fit better with the slightly modified inserted vertex. If you're using a different editor than slade and it wants a proper unsigned BAM, just compute 65536 - angle to get the proper numbers. I think the value should probably be recomputed anyway to fix the bug. This modification doesn't HAVE to have the vertex modified. If you want to be a purist, you should probably go with these values instead: NODES: 162: 3277,-3259, 4009,-5304
  8. zokum

    ZokumBSP development

    I haven't updated here in a while, but I haven't been idle. There's a nice thread about an error with bad seg angles causing rendering errors. The best known being the star structure near the exit on map09. I am sure there are other similar errors on other maps. I made a post asking for other places things got screwed up without much of a reply apart from the map09, e1m1 ones and a vague reference to one on map30. I've been working on a tool to tweak partition lines. If i can get it work manually, I'll eventually include the code into ZokumBSP. As always it will be optional to use it or not. I've named it partition tuning. The goal is to fine tune the partition line to reduce the amount of errors. Reducing errors should result in fewer/or smaller slime trails and other oddities. The tool can't remove all slime trails, but it _might_ remove some. It should also hopefully allow for a bit of manual tweaking for the perfectionists. A given partition line might have slime trails no matter what, but with proper tuning, we might be able to change where they occur. Having a slime trail in the middle of a nice and important vantage point is a lot more annoying than having one inside a monster closet, dark area or one with similar textures leaking into eachother. Similar textures would be rendered different if they are at different heights, but it would probably be a lot less jarring. At the moment the tool can read a bunch of data from command line and compute how wrong the points are compared to the partition line. There might be some clever hacks that could reduce the chance of a slime trail in favor of slightly funky wobbly lines :D I'll see what I come up with. Since it's command line, it could be used manually on any existing map and with any existing node builder. This is not a very user friendly tool. Don't expect guis or wizards or hand holding. ./partitiontuning 3136 -3072 3990 -5370 3520 -3584 3408 -3432 3136 -3072 Partition data: 3136,-3072 | 3990,-5370 Line from: 3136,-3072 to 7126,-8442 Distance from point #1 ( 3520,-3584) to line: 2.86992630 ! Bad rounding, should have inserted a seg? Distance from point #2 ( 3408,-3432) to line: 3.62328196 ! Bad rounding, should have inserted a seg? Distance from point #3 ( 3136,-3072) to line: 0.00000000 - All good! Thi is just an early version, any automated tuning hasn't been applied.
  9. zokum

    Things about Doom you just found out

    @129thVisplane No, I was thinking of this one:
  10. I've been looking into the cause of slime trails. It seems that at least one known occurence was a different error, caused by bad angles in the SEGS data structure in the map format. Mosst known slime trails are still most likely related to integer rounding, more research is needed. A page about this new bug has been added in the Doom Wiki: https://doomwiki.org/wiki/Bad_seg_angle I coded a tool to compute new angles for me and checked out the problematic star strucure near the exit on map09 in Doom 2 and found out many of the values are wrong. You can edit this manually with SLADE with these updated values to check it for yourself, change the number from A to B for all 8 segs and play the map. seg 325: angle from 30214 to 30147 seg 327: angle from -2553 to -2621 seg 328: angle from 30203 to 30709 seg 330: angle from -2564 to -2059 seg 337 angle from -30214 to -30148 seg 338 angle from 2553 to 2620 seg 341 angle from -30203 to -30710 seg 342 angle from 2564 to 2048 This fixes two rendering errors in that area, on two sides of the star. As far as I can tell, Id software's DoomBSP tool only gets the angle wrong on segs that are split. So to fix this type of slime trails I used this recipie: Find the linedef that seems to be the problem in an editor. Verify it has been split by finding a seg with an offset other than 0 that references this linedef. Go through the list of segs in Slade, find the start and end vertices, get coordinates from the vertexes data structure. Compute all the correct angles based on the coords of the two vertices per seg. Update the segs entry with Slade or another editor with the (usually) 4 new values. More if the line has been split more than once. This will usually be two vertices that are sharded with linedefs and one that is not shared with a linedef and has a higher number. This is due to node build splitting adding new vertices at the end of the vertices list, and those naturally have higher numbers. For Linedef 616 on map09, the vertices were 496, 497 and 566. 566 is then the one added by the node builder. Almost all vertices in the original maps are on a grid of 8, except the ones added as part of the node builder process. The angle of split segs is also known to be wrong in BSP and Zennode. Many node builders are based on these two code bases and are most likely affected by this bug. ZokumBSP has a this fixed in version 1.0.10-beta11 Since this is a purely visual bug and the vertices aren't changed, I really doubt this would affect demo compatibility. The tool I used to compute this was written in C(++), here's the source code: #include <memory.h> #include <stdio.h> #include <math.h> #include <stdlib.h> #include <string.h> #define M_PI 3.14159265358979323846 // taken from BSP unsigned int ComputeAngle(int dx, int dy) { double w; w = (atan2( (double) dy , (double) dx) * (double)(65536/(M_PI*2))); if(w<0) w = (double)65536+w; return (unsigned) w; } int main ( int argc, const char *argv [] ) { if (argc != 5) { printf("Expected 4 arguments, startx starty endx endy\n"); return 1; } else { int sx = atoi(argv[1]); int sy = atoi(argv[2]); int ex = atoi(argv[3]); int ey = atoi(argv[4]); int angle = ComputeAngle(ex - sx, ey - sy); int backside = (angle + 32768) % 65536; int sladeAngle = angle; int sladeBackside = backside; if (angle > 32767) { sladeAngle = angle - 65536; } if (backside > 32767) { sladeBackside = backside - 65536; } printf("Frontside angle: %5d. Backside %5d\n", angle, backside); printf("Signed BAM: %5d. %5d\n", sladeAngle, sladeBackside); } } Compile with gcc -lm bamutil.cpp Signed BAM is the format Slade expects. Simply run it with 4 vertex coordinate numbers as input to get the front and backside angles of that line. Here's an example of what it should look like: ./a.out 1359 -259 1344 -256 Frontside angle: 30709. Backside 63477 Signed BAM: 30709. -2059
  11. As far as I understand, most ports do not use the angle field. When moving the vertex, it would be logical to assume the precomputed angle can no longer be counted on to be correct. I could be wrong, but from what I have seen so far, it seems to have been generally assumed that the angle fits the seg, not the parent linedef.
  12. zokum

    Things about Doom you just found out

    For the record, there's also a slightly smaller slime trail in the same location as the famous one on e1m1 on the other side of that ledge.
  13. ZenNode and BSP have similar errors. Most likely due to copying the behaviour of DoomBSP. The error is present on pretty much every map in the game, but whether it is noticable depends on a few factors. With a bit of tweaking, the omgiflol script in this thread can easily tell you how common this is. The error happens whenever a diagonal line is split and the intersection is not on an integer coordinate. This is a fairly common occurence, but it will only cause problems when one ends up with short segs as the rounding error is generally bigger then.
  14. Round to nearest will give the best result. A two-sided linedef like on the star structure on map09 can be viewed from both sides. So if you were able to "hide" any imperfection better on one side, you will make it more obvious when viewed from the other side (180 degrees). The precision on angles is quite good and this was only a problem on short lines. With a round to nearest int, the error is at most 0.5 / 65536. The error on the star structure were over 500 BAMs. That means the angle was off by over 1000 times the worst theoretical error when computed correctly. With longer lines the deviation would naturally be smaller and lowering the chance of bad rendering. Over a certain length the problem most likely goes away even if the angle is slightly off. A lot of lines in the game are off by 1 BAM, most likely due to rounding / different algorithms. This isn't noticable as far as I can tell, but might be on really long lines, I haven't checked. Just use lrint() with bsp's algorithm for computing angles. The one ZenNode used was a lot less readable.
  15. Recomputing all the angles would probably be nice. A lot of the id-computed angles are off by 1 BAM. I haven't looked into what is mathematically correct, but 1 BAM is a fairly low error in any case. It might be something as simple as a higher precision algorithm is used today for computing the angles than what DoomBSP had in 1993. I wonder how many other maps than map09 suffer from this error, and how many pwads. Maybe @Linguica could conjure up some stats and locations of the troublesome spots with his omgiflol script for doom.wad and doom2.wad. It shouldn't be that hard to output the sector and linedef # of an affected seg. Maybe someone could do some before and after screenshots of fixed rendering. I think segs have to be really short for this to actually matter rendering wise in an easily noticable way. Wall rendering should change slightly on many walls though, would be interesting to see if there's a noticable difference.
  16. zokum

    Announcing AJBSP

    Quake has BSP in 3d. All of the moving stuff in that game is a type of entity like players, monsters and ammo, and not part of the static bsp.
  17. The e1m1 one is a true slime trail. The map09 is a different problem as far as I can tell. True slime trails manifest as strips of the floor or ceiling texture being rendered. The problem on map09 is caused by the angle being wrong and the seg being viewed almost parallell to the player's line of sight. Since the precomputed angle is wrong, the resulting texture rendering is also wrong. This type of error needs a new name, it's not a slime trail at all. "Bad seg angle" might be an ok name for this map09 problem.
  18. Yeah, it only seems to fix one kind of slime trail. As a bonus, split segs (walls) should now be rendered more accuratly.
  19. @riderr3: It's supported in Doombuilder X. Besides, you can just rename zokumbsp.exe to zennode.exe and it should work just fine. It's backwards compatible.
  20. Yes. It seems both ZenNode, BSP and DoomBSP gets it wrong. ZokumBSP already has a fix in place, and since the "cat" is out of the bag, i'll release a public beta with the fix in place. Here it is: http://doom2.net/zokum/zokumbsp/releases/zokumbsp-1.0.10-beta11-win32-mingw.zip Please note that the previous beta 10 had a minor bug in it, leftover from some testing I did. Beta 11 should work better :)
  21. zokum

    Announcing AJBSP

    Actually, you don't really need an unsplit. You only need to store what was there before the split. It would require a bit more memory, but in the grand scheme of things, this wouldn't be that complicated. Once you have split the tree in two, you have also lowered the amount of data that needs to be stored at the next level in the bsp tree. BSP trees aren't really suited to this though, there are probably other more efficient data structures that can be used.
  22. zokum

    Announcing AJBSP

    @andrewj "Firstly, and least importantly, I disagree about in-place modification. When you run a DOOM map editor or even a text editor, you are directly modifying the same file. If the file is precious, a wise person makes regular backups of it, and AJBSP provides an option to backup each file before processing it." This is just plain wrong. Most editors and tools will load something from disk and then edit it in memory. They will only overwrite the stored data on disk when you use the save function. The file is never modified unless you the user explicitly tell the program to do so. Any program that silently overwrote what was stored on disk would be considered broken by the user. I often use the save-as function when doing something experimental on a file. If I had to use save as before I started modifying it, that would be very unintuitive. When I edited maps with Deth I usually gave the map a 4-5 letter long name and added 000 to it and increased that number every time I saved, more or less never overwriting my old file. I'd then run a bat file that built the map with the wad file as an argument, and output the data to a fixed file name which was then loaded by doom2.exe.
  23. Actually, the precision on the angle is quite good. There are 65536 different values for an angle. This will only turn problematic on really long walls that are also diagonal and using coordinates that don't map well to the angle computed. And in most cases, such walls will have a split and this will usually greatly reduce the problem. It could be possible to have a nodebuilder split very long segments and reduce the problem, but I have yet to come over a map where lack of BAM precision is a problem, but then again, I have never been looking for it. I did look into the map09 star. Turns out the angles on the split seg in there is recomputed per seg. This means that ZenNode does things differently from DoomBSP. I will be changing ZokumBSP to behave like DoomBSP, since it seems to be the correct way anyway. As for the high-quality pick near-int intersection algorithm, I think BSP already does this by adding it as another criteria for partition lines. It will rate the partition line poorly IF it leads to splits that are less than ideal precision wise. It might end up having to do that equally bad splits further down the line, it has no backtracking. I could probably add this as a 4th criteria in ZokumBSPs partition algorithm.
  24. I am working on a small project related to the computed angles stored in the segs lump for each map. My hypothesis is that using angles based on the linedef instead of the seg can cause problems when a linedef is split into several segs due to the partition line crossing the linedef. To make it a bit easier to understand. Let's assume we have a linedef going from 0,0 to 9,1. If we were to split this into two and round it to the nearest integer, we might end up with a linedef segment 1 going from 0,0 to 4,0 and segment 2 going from 4,0 to 9,1. I want to know if doomers out there could list any other slime trails other than the e1m1 and map09 ones in the original maps, Doom 2 preferably. I want to check and see if any of them are due to problematic angle values. It should be noted that most source ports have various tweaks that fixes slime trails, so this is only really possible to find in source ports that haven't modified the rendering code much. I suggest doom2.exe or Chocolate Doom. I also hope to update the wiki with a bigger list of known slime trails and maybe expanding on the article. Even if it turns out this hypothesis is false, that is important information for the wiki. The question I eventually want answered is: What should the value of the angle that is precomputed during the nodebuilding be based on? Should SEGS have their angle from the linedef, or should they have the angle from the seg line? ZokumBSP, based on ZenNode currently, uses the angle from the linedef. In 1.0.10 there will be an option to instead use the angle that corresponds to the direction of the seg. It should be noted that the "error" in the angle is usually pretty low, but that it can be quite high on short segs. I've seen errors of over 500 BAMs (binary angle measurement, doom's internal format for degrees). Doom uses 16bit precision on the angle, so an angle of 512 is about 2.8 degrees in the circle is 360 degrees system. In general longer lines get smaller errors due to there being less loss of precision when converting vertex-coordinates to integer values. The angle value of a line going from 0,0 to 1,128 will hardly change if split into a line going from say 0,0 to 0,64 and 0,64 to 1,128. As a reference for what a badly computed angle looks like I have modified zokumbsp to add 256 to every angle in the map for idmap01.wad. That error will be pretty noticable on long segments. Have a look at it and you'll see why I think there might be cases where the wrong angle might lead to slime trails. I had to rebuild the map, here's my rebuild data: Here's a link to the file. http://oppetid.no/zokum/doom/idmap01x.wad (Update: fixed permissions on the file.) If you have problems finding slime trails in this map, look at the BFG area.
  25. I haven't looked into what rounding doombsp uses. ZenNode simply calls lrint(). Rounding to the nearest integer instead of flooring is a fairly basic operation that would yield better accuracy, so I doubt Carmack screwed it up. Split segs usually share end/start points, but it isn't actually enforced in any way. The engine has no concept of a split, only segs with a non-0 texture offset.
×