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


  • Content count

  • Joined

  • Last visited


About zokum

  • Rank
    Junior Member

Recent Profile Visitors

558 profile views
  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

    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
  7. 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.
  8. zokum

    Things about Doom you just found out

    @129thVisplane No, I was thinking of this one:
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.