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

zokum

Members
  • Content count

    165
  • Joined

  • Last visited

Everything posted by zokum

  1. zokum

    What difficulty do you play Classic Doom on?

    There are maps that are much harder than map30 on pistol start on UV. That map hardly changes if you come from map29 or play on easier difficulties. Try to get two rockets in on the way up the first time and another on the way down. Rince and repeat till you beat it. It's also one of the easier ones to beat on nightmare difficulty. Only 01, 08, 16 and 18 are easier. 27 is also dead easy if you know the trick to beating it on nightmare quickly. It should be noted that faster routes on all those maps are harder to do.
  2. zokum

    What difficulty do you play Classic Doom on?

    I mostly play on UV with the occasional nightmare run. The original maps are a lot of fun when played on nightmare. The challenge is just right.
  3. zokum

    Block Rocking Bytes

    Links and contact Web site: http://doom2.net/zokum/brb Download: http://doom2.net/zokum/brb/zokblok1-1.zip Contact: IRC zokum@EFNet,Quakenet,OFTC or the Doomworld forums. What this is A simple test wad designed to test compability in ports with regards to blockmap-related hacks, compression, special effects and optimizations. The maps are all designed for Doom 2 version 1.9, DOS / latest Chocolate Doom. This is not a map set designed to be played, it contains some very basic architecture in order to test the tweaked blockmaps quickly and reliably. As time passes and more research is done, more maps will be added with different tweaks. Version history 1.0 Initial release, zokblok1.wad 1.1 Minor updates on docs and added endoom screen, zokblok1.wad. Uploaded 28.04.2018 00:01 CEST due to pebcak errors. Tools used The maps have mostly been created with Anotak's Doombuilder X fork and then built with ZokumBSP. Some of them have then been opened in slade, had the blockmap exported and redone by hand in a hex editor before being imported back in. One of the goals of this project is also to add support for these algorithms and tweaks in upcoming releases of ZokumBSP. Maps map01 - Zero headered plus size. Uses a blockmap larger than 65536 bytes. It is 65622 bytes, 86 bytes bigger than the conventional max-size. The area with the overhanging block list is the complex stair like area. map02 - Zero header removed. map03 - Separate render and collission geometry-simplification. The affected wall is the one with alternating silver textures. Compability list for zokblok1.wad Maps will be added to the project as more techniques and discoveries are documented and testable. The end goal is a stress test wad for doom vanilla behviour compliance and documentation of algorithms doom tool writers can implement. The end result should be greater support for maps across all ports and the creation of bigger maps. No problems map01-03: Chocolate Doom, Crispy Doom, Doom Retro and Eternity Engine. map01-02: Doom Legacy and GZDoom, Edge. Minor problems map03: Doom Legacy and GZDoom - No decals on separate geometry. Critical failures map03: Edge - Rebuilt nodes causes render of more segs, z-buffer problems. Untested map01-03: Boom, MBF, PRBoom+, Zandronum, Zdaemon and Zdoom.
  4. zokum

    Block Rocking Bytes

    I'm not a hardware enginner, but here is my take on it: I think it's fairly hardware-dependant. There are two textures in the exact same space. With walls being drawn in parallell to the same z-buffer it all depends on which texture is written first to the Z-buffer. There might be some inaccuracies caused by the texel stuf manifesting as these weird patterns. All this is probably undefined bahaviour. The OpenGL standard says nothing about what to do in these cases.
  5. zokum

    Block Rocking Bytes

    I think the nodes are being rebuilt to be easily usable in OpenGL. The collission-only linedef is now generating a seg, and this leads to z-buffer-problems when there are two segs directly on top of eachother. This is a hard one to fix cleanly, but I can add some tweaks to make it easy to detect this to avoid it happening. Ideally, gl nodes should use the segs as a base, not linedefs. Thanks for testing @Coraline.
  6. zokum

    Favorite Source Port?

    #1 Doom2.exe, the original Dos port, version 1.9. #2 Chocolate Doom. #3 Eternity Engine.
  7. zokum

    Block Rocking Bytes

    On map01, check the stairs, if they work fine, it's all dandy. On map02 shoot at the stairs to check em. On map03 check that the alternating walls work ok. Legacy had problems with decals on the alternating wall. I should perhaps point this out better in the docs so people know what to look for. Map01 is basically a proof-of-concept that blockmaps larger than 65536 (64kib) are possible. There might be ports with odd alloctions or faulty blockmap tests. Thanks for the testing of Doom Retro :)
  8. Here's a tutorial I made so that we can hopefully get some better endoom screens in our wads. I made it as textmode art to showcase what is possible. This tutorial is available in ansi textmode format, or png, converted with Pablodraw. This is version 1.0. If you find any errors, omissions or improvements tell me! Hopefully I'll release an updated version, up till about version 1.9, possibly an ultimate version of the tutorial. For those of you that wanted a searchable text or an antialiased font. Tough luck. This is a png file of the tutorial, suitable for viewing in a web browser, scaled up to 200%. Original file suitable for viewing in Pablodraw and other tools: http://doom2.net/zokum/endoom/endoom-guide.ans
  9. zokum

    Endoom tutorial in ansi format

    Here's a quick endoom I made for Block Rocking Bytes. With such a long name making anything elaborate isn't very easy. It feels a bit unbalanced. Due to the height of the letters I can't push 'bytes' more to the left. That would have helped a lot. The letters are mostly from my font example, but have been tweaked to fit the overall design better. By making it a bit more jumbly, I could fit three lines in on what would normally only have room for two. The top line is left blank due to the dos prompt pushing the art upwards and the top line out of the screen. I have two more endoom screens I want to post when the projects they are in are released.
  10. zokum

    Block Rocking Bytes

    Must have been real tired, forgot to save in slade before i zipped and uploaded, and url was also wrong, i had only edited the text on the link, not the location, the forum interface is a bit wonky. Correct 1.1 uploaded 00:01 CEST 28.04.2018.
  11. zokum

    Port with Doom Alpha/Beta support?

    To be honest, this does sound more like something within the scope of Chocolate Doom. Being able to read the older data formats and play the press beta and alphas on modern systems.
  12. zokum

    Things about Doom you just found out

    I've actually submitted an update to the doomwiki. There are still some details that are missing, but it's a lot more complete and gives a better description of the format.
  13. zokum

    Block Rocking Bytes

    I've updated the doomwiki article about the blockmap lump and added a small stub article about this project. I have also received reports that all of the maps in zokblok1.wad work fine in the Eternity Engine. I have personally only tested them in Chocolate Doom.
  14. zokum

    Block Rocking Bytes

    This post used to be an indication of what the title of the project was referencing, along with a relevant Youtube video. Seing how several people got it immediatly, it's kinda redundant :)
  15. zokum

    Things about Doom you just found out

    Sorry for that, I didn't mean to be rude. I tried to give accurate and fleshed out answers. I might have been a bit terse, but I'm not too fond of adding a lot of cozy fluff :) Over a year ago non-0-header blockmaps were tested in various ports and a list was produced with compability information: The thread is fairly long and messy (171 posts) and i just assumed you'd read all of it, since you posted in it. It covers blockmaps working in doom2.exe, chocolate doom, prboom with right complevel, eternity with -vanilla parameter. Only reported completely broken ones were: geezy & queezy, zdaemon. Later there's also mention of this snippet: "Presumably the "certain someone" is Graf who has already committed a change to the GZDoom code to handle blockmaps of the type under discussion." In addition there was a coder from another port that asked me to enable doomworld mail support to communicate with me. If I'm not mistaken EE had code added that makes adding the -vanilla parameter unnecessary. We talked about this mostly on IRC. As far as I understood it, it was fairly settled that this kind of blockmap would be fairly well supported in maintained ports. Zdaemon most likely still lacks support for headerless blockmaps. Support is not mentioned in the changelog, I just checked.
  16. zokum

    Things about Doom you just found out

    I really doubt most technical people know how integeres are stored, but it could be that a sizable portion of the people in here know. You're correct about the unsigned bit, iwas impreciuse/wrong there. It's only in some (most?) ports and ZenNode that one uses unsigned ints. When I was commenting i was thinking about the way it's being referred to in the many of the wikis etc, but I didn't state that. https://zdoom.org/wiki/Blockmap and doom-wikia-com/wiki/Bløckmap clearly states that unsigned ints are used and the end character is -1, which is a bit nonsensical. The proper doom wiki is more thorough, but it does omit some information about which entries are signed in the headers etc. I should have checked with the "real" wiki. :)
  17. zokum

    Things about Doom you just found out

    Yes, I think it is the best since it allows for better compatibility. This is the only way we can get it to work in doom2.exe and all the other official ports. The later ports we have the source for, like boom and mbf are much easier to fix. Except that it DID cause problems. One couldn't play back tons of demos without this 0-entry being parsed. This led to MBF pretty quickly adding an option to include the first linedef anyway. The problem lies in the fact that these ports in many cases could handle the blockmap just fine, but it didn't automatically do it, they had to be told to do it via a complevel etc. I don't have any numbers on how often this skipping fixed a problem. It was by all accounts a fairly rare occurence from my doom 2 iwad test. There is a bug in the original source code with regards to the collission code being faulty when moving slowly. This one also affected demos a lot when I removed the 0-lines or used subset compression. The shooting bug is much more obvious than the slight 'nudge' the other bug feels like, but the nudge happens a lot more often from what I could tell. I'm a big fan of the speedrun / demo recording scene. For me this compatibility is very important. One of the goals I had was to enable the playback of 1.9 demos with a rebuilt blockmap without desynchs. Something I did manage to do, and with a severely reduced blockmap size. I'm not being hostile, I am just trying to be very precise and exact, to avoid confusion. When writing programmer specs one needs to be very clear about the functionality one wants and how it is supposed to work and why a tweak/fix/compability option could/should exist. As far as I have understood it this type of 'correct' blockmap has been discussed and handled a long time ago (over a year?), the first release of ZokumBSP was in August 2016. I've talked to several major port authors and as far as I could tell, we've come to an agreement about how to handle this. It's not really a hard thing to fix. Having the code work as it did in id's released source code is a decent way of fixing it and enables the best backwards compatibility. Ports wanting compatiblity with boom/mbf era demos need more complicated functionality. There's already a huge mess there with loads of complevels. I really don't want to touch that wasps nest. My goal has been to make it possible to have doom2.exe and chocolate doom compatible maps that allow for big maps with cool special effects. If ports aren't doom compatible, the port authors are the ones that should decide what to do about this incompatibility. Any decently compatible port should have those maps working just fine. When i wrote this code I tested it on several really long 32 map runs in order to iron out any bugs. Originally it didn't occur to me that ports could have introduced bugs that broke this fix in the tool chain.
  18. zokum

    Things about Doom you just found out

    I checked with others, as far as I can tell you're the only one who have a problem with what I am stating and the way I am saying it. Every time you've had a question, I've tried to clarify my point. I'll show you what I mean: You say: Then I respond: Notice here how I correct you when it comes to rebuilding the nodes. This is not a nodes related behaviour. I also clarify that the blockmap optimization that MBF/boom has makes many ports handle this valid data incorrectly, and due to that, I disabled it in the following version of the ZokumBSP, which has been out for like a year or so, if not more. Then you respond with: You were incorrect in stating that this would be fixed with a rebuild of the nodes. It won't. You also stated that ZokumBSP needed the right settings in order to fix this. For quite some time the default settings has produced iwad-like blockmaps. Thus the default settings are the right settings. When you state that the right settings are needed to fix this, something that might be technically correct, it implies the default settings aren't correct. To the average person you're telling them that the default settings produce problematic blockmaps. If the default settings worked ok, it would be pointless to point out that you need "the right settings", hence it logically follows you need to use the different from default settings, else you would never have told people to use the right settings. You've also mixed up several bugs here and made completely false statements, like in: The line about new ports simply isn't true. These are two separate problems. Bullets hitting invisible lines can occur for any line, not just the 0-line. I've had to correct several of your faulty assumptions. If you reread the posts earlier and do not use bad assumptions, it should be clearer what I am trying to tell you. As for old ports not handling new maps, that is a fairly nieche case and to be honest, not unexpected. We're most likely talking about maps that should run fine in doom2.exe, prboom+, 3dge, gzdoom, eternity, etc. Running vanilla designed maps in ports that aren't vanilla compatible isn't something one can reasonably expect to always work. Known bugs are known bugs. I've had to correct you so many times. can't we take this discussion on irc? I am sure the rest of the community has very little interest in this :)
  19. zokum

    Things about Doom you just found out

    It depends on the point of view. The engine doesn't recognize the 00-delimiter and having it adds nothing of value. From the engine POV the data it gets is 'wrong'. My point of view is that the doombsp/id toolchain is doing it wrong, not the engine. These things happen when you develop a game, small bugs, inefficiencies, quirks. For the iwad data it didn't cause any noticable problems during their Q&A and was never caught. The game is full of these little things. If we'd simply changed the way wadtools built blockmaps back in 1998 when it was discovered/verified, we wouldn't have had this mess. And many maps would have been bigger! I've said it before and I'll say it again. It takes a special kind of crazy to add thousands of unused headers to a severly size constrained data lump which is always discarded countless times during runtime. The code in boom was a minor speed optimization that applied to all maps built with the current tools, but broke demo compatibility and made it "impossible" to add a highly efficient size-optimization to the blockmap tools (skipping the nonsensical header). In hindsight I think we can clearly say it was a bad choice. It limited map size in favor of an extremely minor speed improvement. Building the blockmaps "properly" should give us even better performance, since you could remove the code that skips the 'header' AND not parse linedef 0 as in every block. It doesn't actually end with -1, it ends with FFFF. It just happens to be that if you specify -1 and converts that to unsigned 16bit it ends up as the value 65535 (0xFFFF). It's a programming hack that is a bit nonsensical for people that aren't aware of how integer numbers are stored in C etc. Exactly why this convention is in use here is a bit odd. If you view a wad in a hex-editor, it's obviously FF FF in those two bytes..
  20. zokum

    Things about Doom you just found out

    It should be possible to code a blockmap algorith to actually reduce/remove these to make doom2.exe play the maps better. This would be extremely nieche, but it is doable :) There are two ways of doing it. 1. Align the blockmap in such a way that long lines do not end in the middle of a block, but near / at the edge. 2. Programmatically split a linedef into two or more lines that exist only in the blockmap. Let segs be based on the existing line(s).
  21. zokum

    Jim Flynn

    Sad to hear about a doomer passing away. He did a lot for the community, those were some major contributions. A doom community tribute would be fitting!
  22. zokum

    Things about Doom you just found out

    No, it can also happen with a linedef that is inside the block and is very long. The error applies to any long linedef that is on the blocklist for that block. Since many tools added linedef 0 to all blocks, it's the common culprit if its also happens to be long.
  23. zokum

    Things about Doom you just found out

    No, I am NOT contradicting myself. I obviously meant to stop skipping the first linedef blindly. They've fixed the bad optimization. Skipping the first linedef was never a proper fix for anything, it was a dodgy speed optimization that broke demo compatibility etc. It reduced the chance of a two bugs occurring, but didn't eliminate it. You're confusing what I mean by fix, and that is why it doesn't make sense to you. Reread my posts and it should be clearer. After I fixed the tool chain, several ports have changed the code inherited from the bad mbf-optimization or is not using code similar to it anyway. I don't really see a point in having it in ports, it's fairly pointless, but if they want to optimize for a tiny amount of speed, they're free to do so. The actual bugs with regard to collissions at slow speed and the overflow is are found in two other places. Fixing them makes the first-linedef-skip a pure optimization, which can be faulty if there isn't a solid check whether to use it or not. I advocate just simplifying the code and optimizing the maps instead if need be.
  24. zokum

    Things about Doom you just found out

    As far I know, most people do NOT use a port that struggles with the no-zero-header-blockmaps. First of all, after the issue came up, several ports have already fixed the skip-first-entry-fix, or they already had a fix due to demo compatibility or has abandoned this code ages ago. It's not a problem in Eternity, Prboom+, GZDoom, 3dge, etc . In some cases a compability switch is needed. Someone made a list a while ago. It's only really affecting a few older ports that aren't maintained any more. I'm in no way suggesting people should look at the blockmap. You need to read my posts more carefully. People should look at the accompanying text file that tells people what ports are supported for a map. Newer maps require new ports sometimes. I really doubt a lot of people are using old unmaintained ports and also demanding to be able to run newer releases in ancient software. I made that point very clear. If a mapper makes a map set that he/she/zee/they/etc tests and certifies works in 4 ports, it's not really the mapper's problem if a different port doesn't handle it. Just like some projects require a minimum version of GZDoom or only works in EE or requires a limit removing port etc. If the port has the faulty skip-first-line optimization and has fixes for the various collission detection bugs, the only change reverting the faulty optimization will do is a slight slowdown when running maps with the extra entry. The skip-fix wasn't meant as a bug-fix it was meant primarily as an optimization. The real reason for the bullets hitting the air like that is an integer overflow when certain lines are long. Fixing that, something I think just about every modern bug-fixing port does, removes that error. If it works in Eternity, chocolate doom, gzdoom, prboom+, doom2.exe, 3dge, doom legacy, etc, that probably covers 99% of the single player community. As for the closed source multiplayer ports, those seem to be maintained as well. The bug was in no way discovered by me, it was known about for a long time. All I did was to add a proper fix to it. I also fixed some problems in ZenNode and added some novel algorithms to make it possible to have even smaller blockmaps.
  25. zokum

    Things about Doom you just found out

    Old ports playing new maps isn't a very compelling use case. It would be unreasonable to require all releases to conform to the bugs of old ports. The amount of people that use these old ports is near 0. If you want to play a new map, use a newer/fixed port. Nothing stops people from updating an older port with a fix anyway. I am in no position to require new maps to work in doom2.exe, nor is anyone else to require that maps that work in doom2.exe should also work in mbf, boom, etc. As for new ports playing old maps and getting the large area bug. This is a different bug. You're confusing it with this one: https://doomwiki.org/wiki/Hitscan_attacks_hit_invisible_barriers_in_large_open_areas This is most likely fixed in most modern ports as well. And this does not only affect linedef 0, it affects all linedefs in a block. It's just statistically more likely to happen with the 0-in-all-blocks style of blockmap. Modern ports should not be affected by this at all unless it's an intentional compability fix/option. The reason the 0-entry is mentioned in that article is that "empty" blocks usually contain linedef 0.
×