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

Deus Vult in Doomsday

Recommended Posts

I'm currently working on map loading in Doomsday and am using Deus Vult as a test case (since to my knowledge MAP05 is the single largest DOOM-format map in existence) and have hit on a problem which I need help with.

First of all, that map is loading just fine if I force a runtime blockmap rebuild. However, when I instead try to use the BLOCKMAP lump from the WAD by sending it through our convertor; loading fails.

Is there anything abnormal about the format of DV.wad::MAP05::BLOCKMAP? Has there been a "new" development in BLOCKMAP formats I don't know about?

I'm already aware of the zero extending of line list offsets and our convertor supports that.

Share this post


Link to post

Much better a new thread than a mega-bump. The problem is that people start responding to posts made years ago and the whole thing becomes a godawful mess.

So split.

Share this post


Link to post

The most likely explanation is that the pre-built blockmap is corrupt due to overflows. If the generated data is larger than 128kb there is absolutely no way to store it in the WAD.

Share this post


Link to post

I've never heard of "zero extending of line list offsets" before, what is it?

You are no doubt aware that blockmaps can be compressed (two or more offsets pointing to the same list).

I reckon not much is gained by loading the BLOCKMAP in the wad (instead of generating it internally every time). About the only trick that can be done is making a normally solid wall walk-through-able or shoot-through-able (remove it from the blockmap), and I doubt there is more than a handful of wads that utilise such a trick.

Share this post


Link to post

On closer inspection, that zero extending is supposed to be done to the linedef indices in the line lists and not the offsets to the line lists, since they are already unsigned (doh!). I'll try that.

The most likely explanation is that the pre-built blockmap is corrupt due to overflows.

Hmm. So there is a possibilty that its simply truncated :(

You are no doubt aware that blockmaps can be compressed (two or more offsets pointing to the same list).

Yes, I'm aware.

I'd like to continue to support BLOCKMAP editing tricks so I might look at reading what I can and comparing with one generated at runtime. Obviously I wouldn't actually use the "borked" one, I'd convert the tricks to explicitly coded logic.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×