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

zokum

Members
  • Content count

    291
  • Joined

  • Last visited

Everything posted by zokum

  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. Nice screenshots. What tool are you using? I would love to see some of the non-split maps, like e3m1.
  7. ./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.
  8. 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.
  9. 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.
  10. 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.
  11. zokum

    ZokumBSP development

    Surprise 25 year anniversary release. http://doom2.net/zokum/zokumbsp/fetch Mostly speed optimizations and better debugging output.
  12. zokum

    Chocolate Doom

    This shouldn't be a problem. Just start up whatever registers keypresses and mouse movement as soon as the game starts, and let the player have all of the rest of the loading to "quickstart" some movement. A minimum load sequence of say 2 seconds would be nice as the load process would probably become pretty instant on a modern system, making it hard to get the key presses done in time for the gameplay start. Extremely fast starts is probably a problem with vanilla Doom as well, but you could always mitigate this with stupid solutions like putting the game on a slow network drive or a slow usb stick and have cache turned off etc.
  13. zokum

    Chocolate Doom

    This won't affect demo playback I think. The bug is that Chocolate Doom doesn't properly register all key presses very early in the game. Choco handles the movement instructions just fine internally, it plays back demos correctly. It just doesn't register that these keys have been pressed. The problem might lie elsewhere in the stack of how keypresses are handled, outside of Chocolate Doom and inside a library.
  14. zokum

    Chocolate Doom

    It would be interesting to see if this regression is something that exists in the non-source Linux versions of the game. Does this problem exist in the the early source ports based on the 1.10 source? Maybe the DOS versions have this minor advantage over the Linux ports? If this is the case, this minor gameplay change would be an interesting find to document in the wiki.
  15. zokum

    Chocolate Doom

    From the first tic I think. If you look at the screenshot, SL40 is missing from the first two ticks, but the turn and move forward are registered correctly.
  16. zokum

    Things about Doom you just found out

    That piece of code is there to make the boss monster audible no matter where you are. I think this tweak makes the most sense on e2m8, where there's a high chance you will wakup up the cyber by first attacking the lost souls and the boss will be far away. On the other maps it isn't all that important. It got carried over into Doom 2, so map08 has that slightly different audio model as well. The game just checks if it's map 8, regardless of what episode, and Doom 2 has one episode internally.
  17. zokum

    Chocolate Doom

    IPX support is a very cool addition. A doom port with some sort of API could finally allow for some decent client side bots to play against with the original executable on relevant hardware :) Something I have always wanted since i tried similar things with Quake in the mid 90s. Client bots "cheat" a lot less, they don't do voodoo stuff like picking up weapons from afar, shoot too fast etc like the Reaper bot in Quake did. I think I have a 2xP150 machine with 128 meg somewhere. That would make for a great retro machine. Very unusual config, but it should be able to run a lot of games, although some games would probably choke on the amount of memory.
  18. zokum

    ZokumBSP development

    I've been ill for a week so development has crawled to a halt. Any spare brain cycles I have had has been used to watch the chess world championship. Here's what I plan to do for the next version: * Add new linedef pseudo-types. * Add parameter-linedef type. * Dummy sector support. * Fix 32bit blockmap support and use it internally for reject without optimizations to avoid problems. * Mystery features that are fairly pointless. * A few 24bit color tweaks to better colorize the output. * Better "quiet" output settings for use from tools that do not display the text output anyway, like Doombuilder etc.
  19. As always, this is also a test wad for port developers. Ideally all the data should be handled just like doom2.exe handles it, or better. I don't think this will be troublesome for ports, but experience has taught me that ports can have some odd code changes and optimizations.
  20. Warning: This is a technique for Doom compatible maps. If you're mapping for Boom, Eternity, 3dge, (insert favourite port here), etc, you might not need this. This has only been tested in Chocolate Doom. Block Rocking Bytes, version 1.2 update! http://doom2.net/zokum/brb/zokblok1-2.zip Map01 to map03 information The maps have not changed since the last release. Map 04 information The term oversized map has been coined for maps that would generate a too big blockmap with conventional techniques. The term outside in this context refers to the area outside the normal play area where the players and monsters roam. In this case the map spans such a big area that the entire map would make the blockmap size about 111kilobyte. This is far larger than the conventional limit of about 65k with current tools. This map has a blockmap of less than 9 kilobytes, despite being about 20000 by 20000 game units big. The map is so large and open that in a few places you can reach max drawing distance limits. This can be fixed by making a more interesting map design where you can't stand in the southwest corner and see all the way up to the far northeast corner of the map etc. I am sure someone can build something way nicer than the 5-10 minutes I spent on making this and trimming it down so that draw distance problems weren't too bad. This is a technical concept map, not an architecture map. You get this oversized effect by tagging the outside architecture linedefs with the tag 999. This excludes these lines from the blockmap and also from the area the blockmap spans. There will be a linedef type added for this at some point to make it easier to remember and use in editors. If you look at the map, the blockmap only spans and has full collission detection for small earth area in the center of the map. Outside of this the collission detection should work fine vs floors and ceilings, but not walls. Care has to be taken when designing maps to avoid this becoming an immersion breaking problem. For an outer wall, you should be able to tag the outside edge, it's enough that the inner edges are collidable by being on the blockmap. ZokumBSP doesn't quite build reject maps for such large maps correctly, so for the time being just build with -rz, I will try to fix this. There is a very minor bug in the latest released ZokumBSP where it uses vertex 0 as the base values for leftmost, rightmost, topmost, bottom vertex. This can create a larger blockmap if vertex 0 is only used for excluded outside walls. This can be circumvented by having vertex 0 in the main play area of a map. This is already fixed in the source on GitHub. The command line i used was: zokumbsp -rz overs001.wad -o testing.wad This is something that I've been researching for only a few hours after having thought about it now and then for a few days, so there might be some problems that show up with this approach. Hopefully people can safely play around with this a bit and create som really great vistas in their maps.
  21. zokum

    ZokumBSP development

    Here's what it looks like in 16 color mode: As for speed: ./zokumbsp -b- -r- -na=mw=2m=b doom2.wad map11 This build previously took 2 minutes and 36 seconds for the BSP part, and now takes less than 23 seconds.
  22. zokum

    ZokumBSP development

    I've been busy coding, I think there will be a new release soon. Nothing exciting, but some important stuff and quality of life fixes. *Sped up the bsp multi-algorithm a fair bit, 5-6 times at least. *Big speedup of the default bsp algorithm, especially on the bigger maps. *I have decided to turn on -nu as a default option. This fixes a lot of problems with invisible floors. *There's been output fixes to make it easier to see how close many of the entries are near the limits. * Many minor fixes and tweaks to the output. Hopefull this will work fine on both Linux and Windows. *Better summary when using -sm (m=multiple). *Switch to show all entry stats except totals, -sa (a=all). *Minor color tweaks when using -c on Linux.
  23. Id outsourced some of the soundstuff and aparently also the first version of the networking code. By doing this, they could concentrate on some of the more interesting features they had planned for the game. I'm not sure about Wolfenstein 3d, but it is aparently very picky about the soundblaster support. Many cards with sb emulation do not work with this game, so having a card that works in wolfenstein 3d is aparently a gold standard of emulation. If this was the case, it would seem very reasonable to just outsource the soundcard support and get it to run with well-tested code that worked with many soundcards. The DMX library didn't quite live up to what they had envisioned, but newer versions of the game did get support for more soundcards like the Pro Audio Spectrum and AWE 32 etc. I would also say that the OPL midi instruments that come with this library are quite decent, even if the implementation is a bit buggy if one tries to make different sounds. This stuff is well documented in another thread here on doomworld. All in all it seems id tried to outsource a fair bit of stuff and use well-tested components instead of doing everything on their own so they could spend more time on features, testing and innovative code solutions.
  24. The problem with VLB was that it ran at the same frequency as the bus. A 50MHz cpu that wasn't clock doubled would mean a VLB gfx card and other things ran at that speed as well. Many cards couldn't handle this, and there were issues with stability and image degradation. That is why the 486 DX2 66MHz runs at a double of 33, the 75MHz at 33MHz * 3 and the 100MHz at 33*3. Doubling a 50MHz bus to run a 100MHz cpu would have led to the same problems you had with your 50MHz system. Thhere were 80MHz systems that are 2x40MHz and a lot of other variations, but these were non-intel cpus. Other vendors produced a slew of 486-compatible chips with various speeds and enhancements. The VLB was a simple solution while they were waiting for the PCI standard, it was tightly tied to the 486 CPU. Before this one basically had ISA at ~8MHz and at most 16bit. PCI was a much more cozy 32bit 33MHz interface, and with amuch better form factor and the way it worked behind the scenes was better. I am keeping EISA and MCA out of the picture due to costs. For home consumers though, VLB was the preferred choice. DirectX was an ok way to standardize things like video modes, but the VESA group had mostly fixed this, check out things like scitech display doctor. The main thing about DirectX was that it did this for video, sound, modems, mice, keyboards, joysticks, netowrking etc. One unified interface instead of having to test tons of configurations, support weird and badly documented hardware. Early versions of DX weren't the best, but after a few versions things started to work well enough for it to be a usable standard. DX also opened up the market for smaller vendors, since things like Soundblaster emulation was no longer a required standard for soundcards etc. Games could have midi support without a ton of work. Doom was released 4-5 years before this was a working standard, so it relied on supporting the most common configuration. A few soundcards, a basic vga mode and a non-fpu cpu. A notable exclusion of the Doom soundcard support is the lack of support for the Roland MT32. It would have been interesting to hear the soundtrack optimized for an MT32, with new samples and custom instruments and all that jazz that the MT32 supported. Dune 2 had a soundtrack written especially for the MT32, try listening to that one compared to the GM version.
  25. The Pentium 60 and 66 MHz were introduced in March 1993. I think they could run the game at 35 fps at least some of the time. These were at that time extremely highend machines, and I doubt they were a platform id targetted. They're more Final Doom and Quake platforms. As for Mode X, it's not really one specific resolution, it's a set of different resolutions that require a bit of manual fiddling to set up. As for the hi-color mode, here's a fair bit of documentation with screenshots from version 0.4:
×