zokum

Members
  • Content count

    74
  • Joined

  • Last visited

3 Followers

About zokum

  • Rank
    Mini-Member

Recent Profile Visitors

239 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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/
  5. 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!
  6. You're free to compare whatever you want, but it might not always be the best comparisons :D
  7. I think it all depends on what we precisely mean by the various term. I've always thought of it as Doom, Doom 2, Final Doom as one branch. Heretic and Hexen as another, Strife as a third and chex quest, hacx etc as other branches. I agree that Hexen has a lot of changes, but it is a sequel set in the same universe, by the same developer, using an updated engine based on the previous game, just like Doom 2 and Final Doom etc. I think it's a bit arbitrary to allow for the inclusion of all the 3 games in the original Doom trilogy and disallow Hexen. And like many have pointed out, Doom 2 does have a slight mission pack feel to it, and Final Doom even more, but they are still standalone games with a lot of new content, and more maps than the original games had. As for flaws in Heretic, there's substantially less artwork in the game compared to Doom. The color scheme is a bit too colorful and cartoony for my taste. It often feels like it's doom, with a twist, which isn't always an improvement over the original. To me the gameplay was slow, it lacked the speed and instant feedback you had with chainguns and shotguns. I find the overall theme in Doom to be more interesting. And by the time Heretic was out, id had released a sequel that had much better deathmatching and much grander and bigger maps than the original game had. The original Doom didn't really ship with any good deathmatch maps, Doom 2 did. Heretic was for me always more of a single player game, which is fine. They really refined the fantasy in a 3D engine-concept with Hexen. I have barely played Heretic and Hexen, The Doom games I have played on and off since the mid 90s. I think one of the main reasons Doom has a lot more artwork is that it is often based on retouched photographs, instead of having to painfully slowly draw everything from the ground up. This made it possible to quickly get a lot of quality artwork into the game. Heretic does suffer a bit from that, having much less varied scenery and a less realistic feel to what is in the game. Heretic is a more whimsical and humor-filled game, with it's bright sprites and powerups that turn monsters into chickens. That doesn't appeal as well to me, I prefer the more serious tone found in Doom. That is one of the reasons why I dislike Duke Nukem 3d, Redneck Rampage etc. I can laugh at things in Doom, but that is from funny situations that emerge from serious settings, not a more canned laughter approach of turning monsters into chickens.
  8. Because Doom and Doom 2 are different games. Original and sequel. Hexen is the sequel to Heretic. The games diversified from the original source, the Doom engine. Heretic added some things, Doom 2 other things. Hexen added more to the Heretic engine. Why do we allow for Doom's sequel to be considered the same, but not Heretic's sequel? The topic says Doom, not Doom 2 or the original Doom trilogy. John Romero was the producer of Heretic and he most likely wanted the games to go in different directions. Some ideas went into Doom 2, some into Heretic. After the success of Heretic, they further refined the concept, just as with Doom to Doom 2, and made Hexen. He clearly didn't want a simple fantasy reskin of Doom. Heretic is much more interesting evolution of the Doom engine than Doom 2 was. Some of the potentially coolest bits like horisontal doors just didn't work. As for Doom 2 VS Doom, Doom 2 also lost a lot of stuff that Doom originally had. Episodes, progression map, left and right views in v1.0 etc. Doom 2 is a much more bare bones experience than Doom, with focus on good abstract levels and a larger cast of monsters and textures. I'd say Raven's definitive 'Doom engine' is the Hexen engine, not Heretic. I'm not a big fan of Heretic myself, but the engine is a nice twist on the Doom engine. The gameplay and design just isn't quite my cup of tea.
  9. I haven't read every post in this somewhat odd thread. If you're comparing Heretic to Doom, compare it to Doom, not Doom 2 or The Ultimate Doom or Final Doom etc. If you're gonna throw in the sequels, you should also add Hexen to the feature set of Heretic. Hexen is quite a bit more advanced when it comes to linedefs than any of the original Doom trilogy games. As for linedefs, Heretic inherited Doom's, and did some minor tweaks. Doom 2 added a whole load of new ones, and those are also used in some of the episode 4 stuff in The Ultimate Doom. The "non door" switches in Doom 2 are merely doors with a different message. Just go check the yellow-skull switch on e4m2.
  10. Reminds me, when it comes to vertex pair algorithms, it could be between any two vertices in the map. A nice good-enough optimization would be to only check between those in the same sectors as it is highly unlikely that vertices far away from eachother would make for better split lines without passing through vertices in the same sector anyway. It's on my list of things to research into, but I wanted to get my wider search working first, and there are still some bugs that need fixing, but I got a bit of progress tonight.
  11. I've been looking into different metrics, and I found that going for a secondary characteristic sometimes hurt the primary characteristic. I had initially set it up so that if the metric was subsectors, it would take a line with fewer splits if it existed as long as the amount of subsectors was the same. That turned out to end up with more subsectors in the end due to favoring unbalanced trees. I have considered researching into the root node split (and maybe 1-2 levels more) to favour a good balance over pretty much anything else for a big map in order to greatly reduce the amount of bad divisions in later data. There are cases where a split line might actually be quite unbalanced, but be alongside a line that splits the map neatly into two parts without adding anything in the way of segs or subsectors. So in those cases, cutting off a "perfect" part of the map might look really unbalanced, but would make the remaining areas simpler, thus simplifying the original split. A map like map32 has some of those charateristics. Splitting the map into two alongside the door near the start should not lead to any more sub sectors or segs as far as I can tell, but would be a very badly balanced tree. A perfect uneven split, a split that reduces complexity without adding any complexity in the form of new ssectors or segs. With a vertex pair algorithm, I think a lot of map designs might have many of these. The map01 example i posted a while ago is a good example, and they most likely exist on many other maps, or at least occur often in sub trees.
  12. Yeah, I thought about that as well, at least for the initial splits until you're left with just a few lines. ZokumBSP has code to favour non-diagonal lines over diagonal lines. If all else is equal, it will go for the vertical or horisontal lines :).
  13. Well, if you start with a good set of convex sub sectors, you will end up with the smallest possible amount of splits, possibly none. You could then apply your idea on top of that and end up with the sub sectors created early on.
  14. Scifista42: I still want to do it from top to bottom, but I'd want the end result to be a very good set of sub sectors. Having no splits is all nice and dandy, but fewer subsectors could mean less vis planes. And too many vis planes is a much more serious problem than too many split segs unless one is aiming for a 32kib seg map.
  15. To be honest, a bigger tree might not be that much worse if you have to render fewer segs, store fewer segs, vertices etc. A split free algorithm could start by dividing sectors into convex subsectors with a near optimal layout, there are algorithms for that, and then construct the tree based on that, insead of segs.