Small Doom Builder release for major new plugin

When I ran 2.1.2.1545 immediately after installing it, I got this:

Errors and Warnings said:

Unable to load the game configuration file "Skulltag_DoomHexen.cfg". Error in file "C:/Program Files (x86)/Doom Builder 2\Configurations\Skulltag_DoomHexen.cfg" near line 51: Invalid assignment. Missing a previous terminator symbol?

When I looked in said config file, I saw this:

Line 51 in Skulltag_DoomHexen.cfg said:

makedoorflags = { 512; }      // see linedefflags, as string, CSV

Compare this to the other Hexen-format config files:

Line 51 in Hexen.cfg said:

makedoorflags { 512; }      // see linedefflags, as string, CSV

Line 51 in ZDoom_DoomHexen.cfg (and other ZDoom_(game)Hexen.cfg files) said:

makedoorflags { 512; }      // see linedefflags

These are the files that are put in the directory by the installer and have not been modified in any way.

Apart from that, kudos on getting Visplane Explorer usable in Doom Builder. It'll be quite useful for vanilla authors.

You can blame me for that typo in the config. Fixed in r1547. Meanwhile you can just remove the = and it will work again.

This version crashes every time when Checking for errors in Map Analysis Mode. I've notice over on the DoomBuilder Forums that stuck things in each other bug is supposed to be fixed. DB2 only crashes when "check for stuck things" is ticked.

Using WinXP SP3.

I'll mention this over on the DB forum too.

Ok obviously that could have been tested better. I will make a patch release today.

Great, all new problems introduced are my fault :(

CodeImp said:

Ok obviously that could have been tested better.

Definitely. That it worked with my test map isn't much of an excuse.

A new version (2.1.2.1553) has just been released which patches the bugs we discovered. Sorry for any inconvenience.

Thanks, awesome stuff.

I tested out the Visplane Explorer and it froze up my quad core computer. It's now completely unresponsive. YAY!

The Visplane Explorer plugin also makes my computer's CPU shoot through the roof.

It's an i7. Any way to make this single-core-affine or have it only redraw to a specific resolution? I get the feeling that it's constantly recalculating every viewpoint even when nothing changes on the screen.

It's nice, otherwise.

Visplane Explorer also maxes out my CPU, but my PC stays responsive so that's not a big deal.

Mista_T said:

It's an i7. Any way to make this single-core-affine

Why would anyone write multithreaded code and then restrict it to one core? Makes no sense. Of course the calculation threads should run with lower priority so that they don't stall the system.

Graf Zahl said:

Why would anyone write multithreaded code and then restrict it to one core? Makes no sense. Of course the calculation threads should run with lower priority so that they don't stall the system.

Probably because I don't want my system locking up or burning unnecessary CPU cycles re-drawing the same heatmap over and over again without a change in the rendered map. As long as there's code that knows when to stop the render, then this is not an issue, but there isn't, and that needs fixing.

It's still an amazing bit of code, don't get me wrong.

It's probably not drawing the same heatmap over and over, rather it's adding more and more detail to it. It looks like CodeImp's plugin starts at a size of 16x16, then refines those blocks (e.g. 8x8 blocks, then 4x4 blocks, etc etc). It takes a very long time to create the heatmap for every single pixel.

I get that it's doing that, but could there perhaps be a setting to limit the resolution of the map? Maybe to a resolution relative to "map pixels"? Or is there one and I missed it?

In my experience it already seems to miss some possible overflows, so I think reducing the precision any further would make it pretty much impossible to rely on as ever accurate.

I see some clarification is in order here, because there seem to be some misconceptions.

My plugin starts at 64x64, just like andrewj's. It even uses the same dithering algorithm (andrewj lovely called this a 'butterfly' algorithm, that sounds sweet :) but since it is multitreaded it goes a lot faster and on small maps you may not even get to see the 64x64 blocks in the first frames.

The plugins spawns the same number of threads as the number of logical cores your CPU has and assigns each thread to one core. You want this, because you want your results as soon as possible (no?). The threads have a 'below normal' priority, which means they give up any and all CPU resources that any normal program would like to use.

My plugin focuses its effort on the area that is currently in view. So if you zoom in, the area you are viewing (in mappixels) will be smaller and you will get the details sooner. You can zooming normally, or by dragging a rectangle. The plugin will continue to increase resolution until 1x1 mappixels. After the current view is completely computed at that resolution, it will continue with the entire map (when you change view again, it will again try to compute inside the view first). In contrast with andrewj's VE, my plugin does not forget the data outside your view, so when you zoom back out (hint: press HOME for instant overview) you will still see what was computed there.

Bucket: Never noticed that. But I uploaded a new version of the plugin shortly after the DB2 patched version, so (although I didn't fix anything that could cause your machine to lock up) you could try downloading it again, who knows, maybe it downloads better this time :P

The plugin doesn't seem to work with Hexen. Keeps crashing whenever I try to switch to visplane explorer mode.

Maybe it's dependent on map format? Then it wouldn't work in Hexen, UDMF, or Doom64 format.

I haven't tried but does it work for zdoom hexen format?

It only works with classic Doom map format.