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


  • Content count

  • Joined

  • Last visited

About zokum

  • Rank

Recent Profile Visitors

991 profile views
  1. zokum

    Tim Willits to Leave id Software

    Let me just quote the wiki then: "4M5: They Will Repent is the fifth map of Thy Flesh Consumed in Doom. It was designed by Tim Willits, with the original layout created by his sister, Theresa Chasar." He didn't even design that map, at least not all on his own. I would speculate he took a familiar layout to get up to speed on the id tools. As for special multiplayer maps, that is obviously bullshit. I would recommend people try playing Super Mario Brothers 3 from 1988 and look at the special battle mode level there. Chances are pretty good that the people at id has played this mode. https://strategywiki.org/wiki/Super_Mario_Bros._3/Battle_Game I won't cry any tears over Willits departure, but he did create som good Quake maps, e1m2-5. His other sp maps aren't all that good. DM6 is an often played map, but it is very simplistic and from a design point of view not very interesting. DM2,3,4 are much more interesting maps and play well. DM5 is his best looking dm map, but it doesn't play very well unfortunatly. DM1 is ok, but nothing more and suffers from being a weird intro to dm map without the more powerful weapons and powerups.
  2. If there are any non-doom compatible issues with this release, I might look into it and see if things can be fixed. In some cases 1.9-limit breaking maps can be below the limits if built better. No guarantees though, and it will most likely be as a research project. For serious speed running the maps should run in 1.9 / Chocolate Doom.
  3. From facebook: John Romero‎ - to DOOM, 7 mins · Something evil this way comes. All the artifacts are now en route to Limited Run and packaging for SIGIL is imminent. Thanks, everyone, for your continued support.
  4. zokum

    Things about Doom you just found out

    A map that spans that wide will not work in Doom. You would need an updated source port that is limit removing. The biggest span you can have is about 23050*23050, height does not matter. You would also need to use oversizing to fit anything into that blockmap, or use the block span pointer area for list data. Not pretty.
  5. zokum

    Things about Doom you just found out

    How big is the blockmap, and what tools are you using to build your map with?
  6. zokum

    TAS (tool-assisted) demos: part 2

    I knew it was probably possible to do it from the "lifts", the heights of the top platform is more than high enough. The reason I suggested using the main lift is that it would be feasible in a non-TAS run, and that is a bit omre interesting to me. One player would have plenty of time to get into the right position on the way up and the other 3 would have time to find their spots as well. Maybe we'll do that one day ;)
  7. zokum

    Things about Doom you just found out

    Most likely a rounding error. The computed angle is off by a tiny amount due to limited precision. Doom has a few of these, they're usually not an issue. I doubt you would ever notice this on any of the id iwad maps.
  8. zokum

    Doom - Crysis of it's time?

    Did we play the same Quake games? GLQuake looked a ton better than what it did in software mode, and there was a lot of features people could turn on/off. Voodoo cards ran it fine in 640*480 with better fps than software 320*200. The defaults were conservative and designed around the original voodoo cards. A lot of stuff was off by default, but with better hardware / less demaninding content it could be turned on for higher quality images. Texture filtering, high-res support, reflecting textures, dynamic shadows, transparent water. GLQuake had a lot of cool stuff: https://quake.fandom.com/wiki/GLQuake
  9. zokum

    Doom - Crysis of it's time?

    You can't just look at the cpu speed here. The video card also played a big role in how fast Doom ran. The game doesn't use any hardware acceleration as we know it today, but it does benefit from a faster graphics card since it sends a lot of pixel data to the card. Same with memory and cache. And not all 386 designs are equally fast. Pentiums were released in march 1993, but weren't in common use for gaming. A P60 should run Doom comfortably. A 486 DX2/66 MHz (August 1992) should also run Doom fairly well when paired with a good graphics card etc. At least by the standards of that era. Intel had a 486 DX/4 100MHz (actually tripled 33MHz). Other manufacturers had even faster 486-like designs.
  10. Cheers. I have had some fun with this tool. I had to use gzdbbfdhaxxupdate instead of my usual editor, dbx. I have learnt a few more things during the christmas, having researched and looked into BSP technology. I will try to incorperate some of that into some of the code I am working on. Using this tool, it is a lot easier to debug the nodes generated.
  11. Nice screenshots. What tool are you using? I would love to see some of the non-split maps, like e3m1.
  12. ./zokumbsp -b- -r- -na=v wadfile.wad The 'b and 'r' are just to skip making blockmap and reject entries. The conventional algorithm is selected with a=d. I know the help output when you invoke zokumbsp has gotten a tad unwieldy with all of the things I have added. It's probably still listed as N/A, but that is due to lack of testing. I don't consider it production ready until there's been more testing done. I am currently running builds of Alien Vendetta and Scythe 2.
  13. Episode 1 and 2 of The Ultimate Doom. Some interesting numbers apart from the splitless ones are e1m1, e1m5, e1m9 and e2m3. Any map with splits is not guaranteed to be the lowest amount of splits, merely that splits HAVE to be made on that map in order to build a BSP tree. The true lower bound is somewhere from 1 up to the number of current splits. I will post some numbers from Doom 2 soon. It is possible to tweak some numbers to get better numbers for some maps, but not others. I most likely do not have the ideal numbers or formulas yet.
  14. It's 24.12.2018 and as promised, here is the new ZokumBSP release, with a vertex based nodebuilder algorithm. This algorithm uses a new way to build nodes. Instead of extending existing partition lines to create partition lines, partition lines will be computed from pairs of vertices. This increases the amount of possible partition lines enormously. Without going into the math, any other partition lines other than a vertex par is inferior as it offers no other benefit other than an additional split. As far as I can tell, no other mainstream, if any, nodebuilder has ever tried to use this approach. With some refinements, it should produce superiour BSP trees to all existing nodebuilders in the general case. Nodebuilders that do not produce BSP trees may still be superior in some cases. What are the benefits? This can produce maps without any split segs at all, or with a very low split count. Here's some data about maps that will be built with very few splits: The current version of the algorithm, an early test version, uses a more modular design when finding partition lines. Using various methods to pick a line until it finds an acceptable one, starting with the most stringent line algorithms first. This should make it easier to write good algorithms as code can be shared more easily and special cases handled much or easily. A split is when a wall is divided into two halves due to the way Doom maps are processed in order to render them quickly. It is at these splits that various problems like slime trails and straight walls no longer being straight due to rounding errors occur. Wall segments (SEGS) can only end and start on vertices with whole number coordinates. This causes problems when a diagonal line is split, or when a partition line is diagonal. What are the downsides? In general, fewer splits mean more subsectors. This apprach will often generate a lot more sub sectors, and could in some cases produce visplane overflows on maps that previously had no such problems. The build time is higher when using this algorithm, but not as high as the multi algorithm. With time and research, this should get better. As of now, I would only recommend using this approach on the final build of a map. On my system doom.wad and doom2.wad took about 96 minutes to build, instead of the usual 3-4 seconds. The algorithm is sometimes a bit weak on big maps or certain types of complex architecture. In these cases it isn't unusual for it to produce a worse result than the old HQ balanced algorithm. I know why it happens, coding a fix that prevents this from happening on the other hand is a lot more complex. Not only has this new approach let me build maps in a really interesting way, but it has also given me some insights into how I can improve the other algorithms. I believe I have found one missing factor that isn't accounted for in the older algorithms. That factor may explain why the wide algorithm works as well as it does. Project web page: http://doom2.net/zokum/zokumbsp/ Documentation: http://doom2.net/zokum/zokumbsp/documentation Direct Win 64 download link: http://www.doom2.net/zokum/zokumbsp/releases/zokumbsp-1.1-win64-mingw.zip I will try to answer any questions people might have, but with the holidays being in full swing, don't expect a quick reply.
  15. zokum

    Things about Doom you just found out

    This could be one of two bugs. Most nodebuilders do not comput the angle for split walls correctly. The problem might noe lie in the engine, but in the nodebuilder. The engine is drawing incorrect data in a correct manner. In theory, this could be used for odd special effects. I can't think of any good use atm, but these kinds of peepholes are a possibility, they can be made bigger.