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

Please help, I have a strange crash bug in my large vanilla map

Recommended Posts

Hello fellow Doomworld-ers.

 

I'm making an advanced vanilla map for a collaboration vanilla project. The map is right now about 1.32 mb large, and the other day I ran into a strange crash bug, the map only seem to crash in Chocolate Doom and Chocorenderlimits, it works fine in PRBoom+. There are no unclosed sectors. So far the map crashes in three rooms, when I walk around in one of the room in specific areas, or if I fire a weapon inside any of these rooms. In other parts of the map, there are no issues at all. When Chocorenderlimits crashes, it doesn't show any error message at all. There are no problems with HOM's or VPO's. 

 

What could possibly be causing this? Could it be a blockmap or sidedef limit issue? Or something else?

 

I'd be very grateful for help. If anyone needs to have the map as well as the resource wad I'll send it via PM.

Share this post


Link to post

This might not help you at all but here goes.

 

I use Doombuilder 2 (but it doesn't really matter which editor you use). There's a map analysis mode.

In DB2 this checks the following:

  • Check closed sectors
  • Check stuck things
  • Check line references
  • Check overlapping lines
  • Check missing textures
  • Check unknown flats
  • Check unknown textures

Since it systematically checks everything in the map it can be helpful to do a blanket scan.

Some of my maps have weird behaviours on purpose so I avoid auto-correcting options but it can help as a pointer.

 

I'm sure all editors have something equivalent. You don't have to let the editor fix the issues if you're worried about it becoming non-vanilla. You can still fix them manually.

 

Sometimes DB2 doesn't find the error I want so I actually go back to DB1 which has some other checks DB2 doesn't have.

In DB1 it's called: Find map errors.

  • Player start Things
  • Missing textures
  • Invalid textures
  • Zero-length lines
  • Line errors (sides, overlappings)
  • Vertex errors (overlappings)
  • Unclosed sectors
  • Things warnings (stucked, outside)

Another way I look for errors is checking the console in Doom after loading the error. I know you're using Vanilla but if you don't have a console it might be worth using a simple port to get it to check for basic things.

 

The console will often report any issues like zero-length lines and invalid textures. These you can then fix manually or let the editor do it for you. Anyway, if all of that is a waste of time at least it eliminates all the normal errors that can cause problems so people can focus on unusual causes.

 

Final thought. Check out the sectors within player line of sight at the point of crash. Make sure each sector's line indexes point to the sectors you expect them to. Editors can miss these mismatches even if they pass error checks. Some effects exploit these mismatches but exploits that work in one Doom game might not work in another.

 

Final final thought. In my editor it backs up the previous map when saving (up to three times). That means I have the 3 previous maps saved in the map directory. This is a final fallback if you get an unfindable error but are willing to lose a little work to go back to a previous map. Also, even if you're not willing to go back to a previous map it can help you narrow down exactly which edit introduced the problem. Then you can simply redo it or do it a different way.

Edited by alowe

Share this post


Link to post

Hey, 

 

The problem is now fixed, I had overrun the vanilla 64k blockmap limit. From now on, I will use ZokumBSP as my main vanilla node builder, because this builder can compress the blockmap amongst many other things.

 

But thanks for the help anyways, you wrote some helpful stuff! I might switch to Doom Builder X since that's still in development. And if I run into other issues, GZDoom has a nice console as well. Cheers!

Share this post


Link to post
45 minutes ago, waverider said:

Hey, 

 

The problem is now fixed, I had overrun the vanilla 64k blockmap limit. From now on, I will use ZokumBSP as my main vanilla node builder, because this builder can compress the blockmap amongst many other things.

 

But thanks for the help anyways, you wrote some helpful stuff! I might switch to Doom Builder X since that's still in development. And if I run into other issues, GZDoom has a nice console as well. Cheers!

One last thing I thought of after posting was this:

Since you're doing a collaboration the problem might not even be introduced by something you edited, so it's doubly important for everyone in the project to automatically back up (and keep) their saves. Then if an problem gets introduced everyone needs to not only backtrack to the edit that introduced it, but whether it was their edit that introduced it. The more complex and work a map takes, the more this precaution pays dividends.

Share this post


Link to post

Yeah I agree, good points!

 

Since it's just me who makes this particular map, I'm pretty much responsible for this 1.33mb behemoth. :) But yeah, good stuff you pointed out.

Share this post


Link to post
21 hours ago, waverider said:

Hey, 

 

The problem is now fixed, I had overrun the vanilla 64k blockmap limit. From now on, I will use ZokumBSP as my main vanilla node builder, because this builder can compress the blockmap amongst many other things.

 

But thanks for the help anyways, you wrote some helpful stuff! I might switch to Doom Builder X since that's still in development. And if I run into other issues, GZDoom has a nice console as well. Cheers!

Something you can do about overrunning the blockmap limit:

 

Imagine drawing a box around your map that just barely doesn't touch any lines on your map. Calling it a bounding box, cause it shows the horizontal and vertical bounds of your map. Making the entire width and height of your map smaller (so this imaginary bounding box can be smaller) will reduce the blockmap requirements.

 

ZokumBSP is an awesome tool that works hard to reduce these requirements too. But it can only do so much. Good luck!

Share this post


Link to post

It is possible for a vanilla blockmap to be above 64kib, 65536 bytes. Currently no tool support making such blockmaps. It is one of the things I would like to do some research into. I have two techniques I'd like to try out.

Share this post


Link to post
23 hours ago, kb1 said:

Something you can do about overrunning the blockmap limit:

 

Imagine drawing a box around your map that just barely doesn't touch any lines on your map. Calling it a bounding box, cause it shows the horizontal and vertical bounds of your map. Making the entire width and height of your map smaller (so this imaginary bounding box can be smaller) will reduce the blockmap requirements.

 

ZokumBSP is an awesome tool that works hard to reduce these requirements too. But it can only do so much. Good luck!

 

Yeah the blockmap is about the vertical and horizontal boundaries, and also about the number of linedefs in the map. I do have a tendency to make quite large maps often, and with quite a lot of detail. But yeah, I should try to make maps that more looks like a ball somewhat than well, how they often look like now. :P  At least in Vanilla. :)  The coordinates of the map in question ranges from about -9000 in the west to about 6000 in the north. 

Share this post


Link to post
5 hours ago, waverider said:

 

Yeah the blockmap is about the vertical and horizontal boundaries, and also about the number of linedefs in the map. I do have a tendency to make quite large maps often, and with quite a lot of detail. But yeah, I should try to make maps that more looks like a ball somewhat than well, how they often look like now. :P  At least in Vanilla. :)  The coordinates of the map in question ranges from about -9000 in the west to about 6000 in the north. 

You can also make maps appear bigger by using more of the z-axis that isn't limited in this way. I've noticed that when using ZDoom (not sure about others) that the z-axis is limited from about -9000 to +9000. That's a lot of free real estate with little to no negative consequences. Add a few false floors and you can have caverns 9,000 units below the surface reuse the same space. This for me is part of the fun of designing a map, how to overcome the limitations.

 

There are other ways to reduce space like designing areas to share more sectors with identical properties that can be joined. I've found some maps can have their size halved by that method alone without any perceivable difference from the player's perspective. Another thing is the number of vertices in curves. When I started mapping I just drew curves with no consideration for the map size. Since then I've discovered that a curve with as little as 4 vertices is just as effective as a curve with 40 vertices. So, the question is, why bloat the vertice table 10 times for no benefit?

Edited by alowe

Share this post


Link to post

The vertices table is rarely a problem. You usually run into SEGS and BLOCKMAP problems before VERTICES overflows. ZokumBSP has a fix for high-detail curves. You can make a nice rounded curve, then make a much cruder curve and have that one be used as the collision detection curve. Tag the rendered smooth ones with the linedef type for excluding it from the blockmap and the crude collision one with the linedef type for excluding it from being rendered.

It requires a bit of manual work, but it should certainly be possible. ZokumBSP also have switches for combining several linedefs that are headed in the same direction. Think of map01 in doom2. There are loads of 64 length walls segments in the central green corridors in order to change texture. What ZokumBSP can do is find these, mark them as non-blockmap and add a 'virtual' linedef the spans the length of all of them and have that one be the only one in the blockmap.

Activate this by adding "-gs=2". You do this at your own risk, it works in vanilla / chocolate doom. I have no idea what will happen in ports, especially GL/hardware accelerated ports.

Share this post


Link to post

Ha, just like to point out that my efficiency savings are all done manually. Not because I'm particularly concerned about the final wad size. I'm not, because these days they can be compressed down to something miniscule, internet bandwidth is trending towards being free and hard drives and removable media are so freakishly huge even Terry wads gigs in size are peanuts to these storage monsters. It's not like the good old days when we had to figure out how to squeeze a game onto a 780kb floppy disk. I guess considering website server limits is important but I'm guessing that wouldn't be a problem unless you tried to make it like a Terry bloater.

 

The reason I try to keep my maps efficient is because I'm using an ancient piece of crap laptop that is prone to crashing if I push the limits too much. So, if a level gets over about 3.3megs it simply fails to load or glitches ingame.

 

Having said that, I have a level called Necronomicon where I artificially increased the size a few kb to 666kb just for added evilness :D

Edited by alowe

Share this post


Link to post

To be honest the main reason a lot of people want 'compressed' wads/maps is that they will run in doom2.exe and chocolate doom etc. And there's also an art aspect to it. The idea of making something cool within size limits is impressive. Just look at the demoscene and 64k and 4k intros they produce.

I was at the Solskogen demoparty last summer, where Fairlight released a great 4k intro. That means the executable, visuals, music, code, etc takes up 4096 bytes or less.

 

Share this post


Link to post

Very nice demo. I imagine only possible because graphics cards do a lot of the work for you like shading so you'd just need to store the geometry. Very impressive though. No way you could pull that off in 4kb on an 8bit.

 

The cliffs at the end look like they're fractal. I really like the dystopian art and atmosphere.

 

By comparison here's what was possible with 40kb on an Amiga in 1998. Worth it just for the music.

 

 

And the limited colours suit Doom lol

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
×