Will Be Working On Chocorenderlimits 2.0

[fraggle]

I'd like to see a limits detection feature, where you can run the game automatically from the command line. CRL will render the screen automatically from thousands of different positions throughout the level and angles, and exit with an error status if any of the Vanilla limits are exceeded while rendering.

Obviously the normal game loop should be bypassed; the test should run as quickly as possible and not be limited to 35fps (modern CPUs can render Doom's screen at thousands of fps). It's not even necessary to draw the result to the screen, though the ability to occasionally see a frame might be nice.

Choosing positions to test might be the trickiest part. Maybe try every eg. 8x8 grid position and write code to detect if you're inside a wall.

[Linguica]

fraggle said:

I'd like to see a limits detection feature, where you can run the game automatically from the command line. CRL will render the screen automatically from thousands of different positions throughout the level and angles, and exit with an error status if any of the Vanilla limits are exceeded while rendering.

Obviously the normal game loop should be bypassed; the test should run as quickly as possible and not be limited to 35fps (modern CPUs can render Doom's screen at thousands of fps). It's not even necessary to draw the result to the screen, though the ability to occasionally see a frame might be nice.

Choosing positions to test might be the trickiest part. Maybe try every eg. 8x8 grid position and write code to detect if you're inside a wall.

Isn't this basically exactly what Visplane Explorer does? http://eureka-editor.sourceforge.net/?n=VisExp.Main

[dew]

A few issues with such approach: if you just dump coordinates of limit exceeding locations, it's going to be less user-friendly and comprehensive than when you actually see it ingame or in the editor. You also need to test for various combinations of floor, door, bar, lift and sector blink states. The biggest hurdle is imo (archvile) jumping. When you thrust yourself off a tall cliff or you get launched into the air by an archvile, your set of possible VPO locations grows. On the other hand reporting ALL overflows including the z-axis might be an overkill, because players can never reach them. BtSX has quite a lot of these "dormant" VPOs (don't tell anyone), but establishing their danger takes some human decision making. Dumping all such "false positives" into a log or something could flood the truly critical ones. (This is why we asked for the archvile jump function back in the day.)

[fraggle]

Linguica said:

Isn't this basically exactly what Visplane Explorer does? http://eureka-editor.sourceforge.net/?n=VisExp.Main

Probably! I haven't used it.

Context is that Freedoom is changing to be Vanilla compatible - I want something that can run from the command line and automatically scan every single level to check for overflows.

If that's what VPE does then ignore my request.

[RestlessRodent]

fraggle said:

I'd like to see a limits detection feature, where you can run the game automatically from the command line. CRL will render the screen automatically from thousands of different positions throughout the level and angles, and exit with an error status if any of the Vanilla limits are exceeded while rendering.

Obviously the normal game loop should be bypassed; the test should run as quickly as possible and not be limited to 35fps (modern CPUs can render Doom's screen at thousands of fps). It's not even necessary to draw the result to the screen, though the ability to occasionally see a frame might be nice.

Choosing positions to test might be the trickiest part. Maybe try every eg. 8x8 grid position and write code to detect if you're inside a wall.

Chocorenderlimits 1.0 already does this exactly how you request it except for erroring on an overflow. I do plan on bringing in the feature for 2.0.

Checking if inside a wall is just an added simple check with a slightly modified R_PointInSubsector.

CRL outputs an image (PPM or PNG?) instead of raw data.

Chocorenderlimits and Visplane Explorer pretty much came around at the same time, although I believe Chocorenderlimits is a bit older. CodeImp chose Visplane Explorer integration into Doom Builder instead because it was lighter and did not include a fully playable engine.

[fraggle]

Cool. It would be nice to have something that runs completely automated. The screenshots of VPE suggest it's a GUI app to find the hotspots in your levels. I want something that can just from the command line, or a makefile rule, and just report "success" or "failure"

[andrewj]

fraggle said:

Context is that Freedoom is changing to be Vanilla compatible - I want something that can run from the command line and automatically scan every single level to check for overflows.

Visplane Explorer cannot do this, it is a GUI program only.

However it is pretty quick to visually scan maps (CTRL-N loads the next map), especially with heat mode and open doors mode.

A tool like you suggest can't actually work, since there are places where VPO is ok to exist because the player can never get there (especially in border areas outside of the normal gameplay area of a map).

[Da Werecat]

Well, you can fix all VPOs, but it'll leave you with unnecessarily simplified maps.

[fraggle]

andrewj said:

A tool like you suggest can't actually work, since there are places where VPO is ok to exist because the player can never get there (especially in border areas outside of the normal gameplay area of a map).

Do you mean inside walls? Not sure I follow.

[RestlessRodent]

fraggle said:

Do you mean inside walls? Not sure I follow.

He means this:

I am sure you played conduits.wad, with the few thousand tiny boxes everywhere.

Imagine a 3 section map: 1) The center being very flat with a single sector, 2) A donut around the sector with a very high floor, 3) The conduits like area outside of the donut.

Suppose in normal gameplay you can never jump over the wall or see anything outside of it. When playing in Vanilla, the game never VPOs because the outside areas are never visible at all (let us assume that planes added due to the BSP are not considered). However, if checking is done at a specific height then VPOs will be encountered because they see over the donut. Also consider that the floor is high enough to not cause a VPO, but there is also an arch-vile running around. The boost given from the arch-vile is high enough to cause a VPO.

Since Doom is 3D, the areas which are most render active vary by heights.

Chocorenderlimits 1.0 and Visplane Explorer treat the data as 2D for the most part (CRL 1.0 gives the max of floor, mid, ceiling). To best represent data a 3D image format would be required, which can get quite large depending on the granularity and the size of the map.

Navigation meshes could make things a bit easier by only considering areas the player can walk, drop down to, or arch-vile jump, using likely view height levels. However, there must be calculations performed with nearby subsectors to determine if a player in one subsector can land on a distant subsector across a gap of a lower height level.

fraggle said:

Cool. It would be nice to have something that runs completely automated. The screenshots of VPE suggest it's a GUI app to find the hotspots in your levels. I want something that can just from the command line, or a makefile rule, and just report "success" or "failure"

In order for success to be obtained (assuming it is precise enough), ALL areas of the map must not visplane overflow.

My latest code is at http://remood.org:8080/crl/doc/ckout/fossil.wiki which is updated in an odd hourly cycle (I push to my local network repos, which syncs with remood.org, which syncs some more).

[boris]

andrewj said:

Visplane Explorer cannot do this, it is a GUI program only.

But the GUI just utilizes the VPO lib, doesn't it? So it should be possible to write a command line tool that uses this lib, right?

fraggle said:

Do you mean inside walls? Not sure I follow.

Look at this screenshot of Freedoom MAP08:



Red means more than 128 visplanes. But the three squares to the right are pillars the player can't stand on.

[dew]

That's why I said I don't think you can really automate the process. If the player is persistent enough, they may for example lead an archvile to a completely different area where you thought you were safe. Or worse, lead one archvile to another archvile and now it's possible to jump higher.

But then the mapper should make a reality check and consider how plausible such a scenario is. Is there perhaps something like a shortcut that would provoke the players into ever experimenting like that? Or is it okay to let it slip, because screw whoever's that hellbent on breaking the map in a no-gain situation?

Ending the check with any error found is too strict.

[andrewj]

fraggle said:

Do you mean inside walls? Not sure I follow.

Another example is the first level of BTSX 2 : the map is surrounded by large outdoor watery area which the player can never get to, it is all just decorative. But there lot of visplane overflows in those areas.

As GhostlyDeath says, you could have a mechanism to mark sectors that the player should never get into and exclude those from an automated test -- but unless the mechanism is part of the map itself (e.g. a special range of tag numbers) then it is going to be excessively burdensome to create and maintain it.

dew said:

Or is it okay to let it slip, because screw whoever's that hellbent on breaking the map in a no-gain situation?

Any player who IDCLIPs can reach a bad area and crash the game. If that is an issue, we could use DEHACKED to disable those cheats.

In the case of Archviles in Vanilla mapping, I think mappers need to be carefully restrict them to map areas where they can't make players jump into the wrong areas, and be much more conservative with the visplane budget of areas containing archviles.