• Content count

  • Joined

  • Last visited


About zokum

  • Rank

Recent Profile Visitors

284 profile views
  1. Sorry for necro bumping, but I just finished a new ENDOOM screen for a project. You'll hopefully be able to see it "soon" :) I spent maybe 8-10 hours on it.
  2. There's an article about av map 01, 03 and 20 on my ZokumBSP project site: http://doom2.net/zokum/zokumbsp/case-av TLDR for av map20: *MAP20 : BLOCKMAP - 51408/65114 (78.95%) Compressed: 84.85%288.083 secs Two things should be noted. This is done with an older version than what is on GitHub, so the output is harder to read and I am aware of techniques that can make this go even further down, but these have a few drawbacks. :)
  3. E - strafeleft R - strafe right W - move left, strafe on A or F - use (sp) space - move back, use (dm) Mouse handles move forward and shoot as well as turning and glide moves. If a Doom port doesn't support this, it's inherently broken and not usable for serious play.
  4. One of the reasons I made ZokumBSP was to enable the construction of bigger vanilla-compatible maps. It should be possible to make even more complex maps than previously possible. AV map20 is a good example of a near-limit-map that with better tools is much more comfortably below the limits. The BTSX guys are aware of my fork of ZenNode, and they might have to use it on some maps. I am working on some other tweaks to the code, but it's currently not working like I hoped it would. Once I get it to work, building even bigger maps could be possible due to better optimizations of the node tree. We're nowhere near the theoretical limit for vanilla-compatible maps, there's been far too little research done in this field.
  5. Doom uses palette 0, 2-8 and 10-13. 1 and 9 are unused. There's also an error in the palette format. The format is 24 bpp, but vga only supports 18bpp so there could be some rounding down. The two unused ones should lower it by about 500. The rounding error is a bit harder to calculate properly.
  6. I don't think you have removed all the duplicates.
  7. For a good demonstration what can be done with color cylcing and palette swaps, take a look at: http://www.effectgames.com/demos/canvascycle/?sound=0 Try looking at the same image with different palette versions. the image is the same, only the colors change. It should be possible to make a doom wad with a custom palette where you would only see certain details when you're wearing a rad suit or taking damage. A very simple demonstration of this would be to map a few colors to all black in the default palette, but when you're wearing the raid suit the colors map to different shades, allowing you to see hidden writing. Step it up a notch and you could hide demonic messages and pentagrams that only show up when you take damage...
  8. The duplicate entries are because id screwed up, I don't remember the exact number. The palette is less than optimal. It's a lot better than Wolfenstein 3d, which uses the default colors from Deluxe Paint, this explains the slightly odd color scheme in that game. The 18 bit stuff is part of how some VGA mode(s) work. Doom tells the graphics card which colors each index is mapped to. So when you get hit in Doom by a bullet, pick up an item, wear a rad suit etc, all it does is upload a new palette and draw with this palette instead of the default one until it swaps to another palette again. This technique is called palette swapping and is very common in many games of the era. Doom doesn't really tell the gfx card to render something in red or dark red, it tells it to render that pixel with the color in palette position X. Change the palettes and you change the color of the entire game. Storing each color as 18 bits would probably be easier on the hardware they had at the time and would use less memory. Since you can only use 256 different colors at once anyway, there wouldn't be much added fidelity in going from 6 to 8 bits per channel. If I'm not mistaken older versions of doom use mode 13h while later uses a 'mode x'. Read up on Abrash Black Book for more information about this, it's freely available as pdf.
  9. If I'm not mistaken Doom has up to about 250 different colors on the screen at any time, most/all the different palettes contain duplicate entries. The colors are chosen from a 18 bit color space, 6bits per color. So 262144 different colors to choose from. If one adds all the colors from all the palettes it uses and remove duplicates I reckon Doom has somewhere between 1200 and 1500 different colors. Regular + green tint + pickup tints + blood tints. It would be interesting to see if anyone could parse the wad file color palette entries and give us the exact result.
  10. I'll check if this applies to ZokumBSP, and if so, try to fix it. Nice info!
  11. I would have to look at the source, this is pure speculation, but it would be an awesome hack to allow for much larger maps. If we have a map that covers say 64*64 blocks, could we then define the blockmap to be 256*320? Put the actual play are at the upper right corner of this area, from blocks X: 192-256 and Y: 256-320 and shove all the lookup lists in the first ~65k bytes (minus header etc). This could lead to crashes / problems IF there are objects outside the normal play area. Actual numbers will vary, but we can use these as a rough estimate. Care would have to be taken to handle all the wraparounds of 16 bit data. If this works, a maps could easily be much bigger, since it would mean that only the linedef lists have to be kept within the ~65k limit. There would have to be some tweaking of coordinates, translating them to a different location to fit all of this, but a blockmap rebuilder could in theory do all that automatically. This would of course mean that some of the lookup pointers are "garbage" since they're really list data. As long as there is a FF end marker at the end of the blockmap, we'd hopefully have a worst case of slow lookups when travelling outside the 'playable map area'. There's also the idea of interleaving the data in such a way that the lookup offsets also happen to be valid lists, putting end markers outside the normal play area or relying on a header that is valid to parse. This would mean the blockmap builder would rearrange the linedefs numbers etc. You'd start by putting as much data inside the lookup lists as possible, and only fall back to putting lists in the list area when there's no good positions left in the offset area.
  12. I am well aware of the thread. My point is that the optimizations are all theoretical while ZokumBSP does some of those things, and stuff not mentioned in that thread.
  13. I got to clarify some errors here. The 256 block width problem isn't as far as I know related to the blockmap. It is caused by the data types not handling values bigger than 128*256, 32768, something that was mentioned earlier. The blockmap on disk limit is roughly 64kib. It can be bigger, but no "offset" kan point to data over this limit. The first element in the list has to be within that 64kib range. Ports that generate blockmaps internally can screw up special effects and will ruin demo compatibility in many cases. ZokumBSP has code to produce more efficient blockmaps than ZenNode due to fixing errors and using various optimization techniques. Further compression can also be done by removing non-collidable lines, skipping the 0-header and by manually excluding lines from the blockmap from the map editor by using special linedef types. This allows one to in many cases greatly decrease the blockmap size and speed up the game. A clever mapper could easily hand-edit a map to reduce the blockmap by using tricks such as removing the linedef of door backsides if the door has a stay open type and is only approachable from one side etc (exit doors etc). Many decorative elements also have lines one cannot collide with. A good example here would be some of the sides of the bars on the Doom 2 map06 elevator. It's very unlikely that you can collide with those facing the wall. If I had to choose between the wad crashing the game and not colliding with those lines, I know what I would choose. Johnsen also pointed out to me that a lot of maps have details in the ceiling but not the floor, to avoid affecting gameplay. Such lines can in many cases also be removed from the blockmap.
  14. The amount of segs have to do with the architecture on your map, diagonal lines do not inherently cause more splits. Splits on diagonal lines are however more problematic, since they might lead to slime trails. It's generally easier to avoid splits IF you have no diagonal lines OR all lines are diagonal and only heading along two directions, being offset 90" to eachother. Basically a non-diagonal map rotated. ZokumBSP has code to reduce visplane causing subsectors OR segs. The user can optionally tweak which parameter to go for. If the map is close to the SEGS limit, using that metric could help you reduce the SEGS count. The latest tweaks aren't out as a beta or rc, but source is available at GitHub. For more info contact me on irc and read the docs and info at http://doom2.net/zokum/zokumbsp/
  15. The best thing about this thread is the myriad of ways I am learning about how to be an asshole to people using ports that break the gameplay in Doom. Loads of things in this thread will come in handy when I work on vanilla maps. :) Keep the ideas and findings coming, I'm loving it!