ChocoRenderLimits Thread

[RestlessRodent]

This is a thread for ChocoRenderLimits.

Repository: https://github.com/RestlessRodent/ChocoRenderLimits
IRC: irc://irc.oftc.net/remood
Synchronization Target: sdl2-branch.

[dew]

Yay, great to see you getting back to CRL. I'll repeat my annoying feature requests then.

Obviously, CRL shouldn't enforce choco's new anti-BtSX limit for lump count per file, heh. Maybe just throw a warning.

And here's a more complex idea: blinking sectors generate fluctuating visplane counts. This means testing a complex scenery that involves blinking requires a lot of standing around and watching them blink from various angles and distances. Is there any way of freezing such an effect in a state that generates the highest visplane count so the tester can do a few laps around it and check all suspect angles before "releasing" it again?

[fraggle]

GhostlyDeath said:

Synchronized To: Chocolate Doom 2.3.0 (SDL2).

2.3.0 isn't based on SDL2.

[RestlessRodent]

fraggle said:

2.3.0 isn't based on SDL2.

I am following the

sdl2-branch

branch and I use whichever version is used there, which is actually 2.3.1, so I corrected it

[dew]

Following the short discussion here, I believe it would be nice if the log output that's now handled by pressing F4 was automated. Maybe every new VPO maximum could be stored, so player needs to erase the max if they want new lower peaks logged... or maybe it doesn't have to be a VPO but a configured value. Mappers may want to know when people hit over, say, 120 visplanes, because that means the scenery can contain a spot that will go even higher.

[RestlessRodent]

dew said:

Obviously, CRL shouldn't enforce choco's new anti-BtSX limit for lump count per file, heh. Maybe just throw a warning.

Removed the limitation and just warned instead.

[fraggle]

GhostlyDeath said:

I am following the sdl2-branch branch

Then please just say you are synchronized to sdl2-branch; saying you're synced to 2.3.0 is misleading. The branch has diverged a lot from the master branch used for the current stable releases. Also, there is no 2.3.1, so I'm very confused as to where you're getting that from.

[RestlessRodent]

fraggle said:

Then please just say you are synchronized to sdl2-branch; saying you're synced to 2.3.0 is misleading. The branch has diverged a lot from the master branch used for the current stable releases. Also, there is no 2.3.1, so I'm very confused as to where you're getting that from.

Done

[RestlessRodent]

So I implemented logging, and since I cannot seem to find conduits I just had an option to cut the visplanes to 32 so that it fails on MAP01. The log format is a bit verbose, but it contains a bunch of information such as the player position, angle, game tic, and which visplanes were visible on the screen and their number (along with their properties such as how they were created and the seg/subsector/sector they emit from, if they are floor or ceiling visplanes). So an editor for example could open the CRL log (or maybe someone can write a new utility) which can point to in a way which sectors caused VPOs and from which direction. I am quite busy so maybe someone can write a basic utility in Java or something. But, assuming the map is not modified, from a given point I can imagine that a 3D mode is created which then shows what was captured in the renderer (the player view height) along with rainbowized floors, ceilings, and walls according to the subsector.

Using the much more limited max of 32 visplanes, this is what the log looks like:

Report gt=462
	X x=018cf4d1 f=396.956
	Y x=03fba5c6 f=1019.65
	Z x=005b2a80 f=91.166
	A x=e2400000 f=318.164
	VISCOUNT num=32 chk=9 fnd=23
	VISPLANE num=0 id=0 type=FND seg=38034317 ssub=53 sect=1 what=F
	VISPLANE num=1 id=1 type=FND seg=38034317 ssub=53 sect=1 what=C
	VISPLANE num=2 id=2 type=FND seg=38034317 ssub=47 sect=18 what=F
	VISPLANE num=3 id=3 type=FND seg=38034317 ssub=47 sect=18 what=C
	VISPLANE num=4 id=4 type=FND seg=38034317 ssub=49 sect=19 what=F
	VISPLANE num=5 id=5 type=FND seg=38034317 ssub=49 sect=19 what=C
	VISPLANE num=6 id=6 type=FND seg=38034317 ssub=52 sect=20 what=F
	VISPLANE num=7 id=7 type=FND seg=38034317 ssub=52 sect=20 what=C
	VISPLANE num=8 id=8 type=CHK seg=142 ssub=46 sect=19 what=F
	VISPLANE num=9 id=9 type=CHK seg=137 ssub=44 sect=18 what=F
	VISPLANE num=10 id=10 type=FND seg=38034317 ssub=63 sect=23 what=F
	VISPLANE num=11 id=11 type=FND seg=38034317 ssub=63 sect=23 what=C
	VISPLANE num=12 id=12 type=CHK seg=180 ssub=57 sect=18 what=F
	VISPLANE num=13 id=13 type=CHK seg=199 ssub=67 sect=19 what=F
	VISPLANE num=14 id=14 type=CHK seg=204 ssub=68 sect=18 what=C
	VISPLANE num=15 id=15 type=CHK seg=204 ssub=68 sect=18 what=F
	VISPLANE num=16 id=16 type=FND seg=38034317 ssub=137 sect=36 what=F
	VISPLANE num=17 id=17 type=FND seg=38034317 ssub=137 sect=36 what=C
	VISPLANE num=18 id=18 type=CHK seg=250 ssub=90 sect=23 what=C
	VISPLANE num=19 id=19 type=CHK seg=250 ssub=90 sect=23 what=F
	VISPLANE num=20 id=20 type=CHK seg=251 ssub=91 sect=23 what=F
	VISPLANE num=21 id=21 type=FND seg=38034317 ssub=92 sect=25 what=F
	VISPLANE num=22 id=22 type=FND seg=38034317 ssub=92 sect=25 what=C
	VISPLANE num=23 id=23 type=FND seg=38034317 ssub=97 sect=27 what=C
	VISPLANE num=24 id=24 type=FND seg=38034317 ssub=94 sect=24 what=F
	VISPLANE num=25 id=25 type=FND seg=38034317 ssub=94 sect=24 what=F
	VISPLANE num=26 id=26 type=FND seg=38034317 ssub=96 sect=26 what=F
	VISPLANE num=27 id=27 type=FND seg=38034317 ssub=93 sect=17 what=F
	VISPLANE num=28 id=28 type=FND seg=38034317 ssub=116 sect=31 what=F
	VISPLANE num=29 id=29 type=FND seg=38034317 ssub=114 sect=30 what=F
	VISPLANE num=30 id=30 type=FND seg=38034317 ssub=114 sect=30 what=C
	VISPLANE num=31 id=31 type=FND seg=38034317 ssub=74 sect=14 what=F

On an unrelated note, if you mix tabs and spaces, GCC warns you:

r_plane.c:274:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
r_plane.c:278:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’

But my tab size is 4 and Chocolate Doom uses 4 spaces.

[Graf Zahl]

RestlessRodent said:

On an unrelated note, if you mix tabs and spaces, GCC warns you:

r_plane.c:274:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
r_plane.c:278:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’

But my tab size is 4 and Chocolate Doom uses 4 spaces.

Sometimes I wonder: Is there any warning that's retarded enough for GCC not to implement?

[RestlessRodent]

Graf Zahl said:

Sometimes I wonder: Is there any warning that's retarded enough for GCC not to implement?

I believe Clang implemented it first actually, a number of people I have talked to said they switched to Clang because they had these style warnings, then GCC implemented them also.

However it is annoying when you use -Werror and then these kinds of warnings pop up when you upgrade your GCC version or you compile some really ancient program. Maybe next GCC will detect emacs modelines and check if you are consistently using the right indentation type (tabs vs spaces).

[dew]

That's great effort, Ghostly..Rodent! But does the log really dump characteristics of all the visplanes? Wouldn't that look monstrous with the 128 visplanes limit? Probably good for some automated editor interpretation as you say, but maybe some -v flag to turn on the verbose mode would be handy. Mappers mostly get everything they need to know from just the position/direction where to look and all that extra stuff is too technical for casual use.

[Use]

Just wanted to say thanks for the effort and work put into this port. It's a godsend for us vanilla stalwarts that has opened a lot of opportunity for enjoying the mapping process and not being inundated with guesswork and annoyances of the engine. :)

[RestlessRodent]

dew said:

But does the log really dump characteristics of all the visplanes?

It does.

dew said:

Wouldn't that look monstrous with the 128 visplanes limit?

It would. I also plan to dump information such as drawsegs and perhaps things too. So that essentially what is printed is a snapshot of what was visible on the screen, technically speaking. Also possibly thought of an automated screenshot which is also stored in the file so one can see what was actually on the screen at the time.

dew said:

Probably good for some automated editor interpretation as you say, but maybe some -v flag to turn on the verbose mode would be handy. Mappers mostly get everything they need to know from just the position/direction where to look and all that extra stuff is too technical for casual use.

I thought about this, but I believe it would be best to keep the information. In a plain text editor, you can just search for "X" for the position and use it that way, or on UNIX there is grep. It would suck if you wanted the details and had to run it twice. So once you learn how to read the details or have a tool, then one would always run with verbose enabled.

My hope is that some kind of automated tool comes into place where some tool or editor can parse the file and shows the information visually. There is time information encoded also and the format is a bit simpler for a computer to parse compared to the previous format (which was kind of ad hoc). I was also thinking of some kind of TCP stream that an editor can receive so it gets a live view of overflows as the player runs around the level.

I would have to poke the developers of the current editors (when I find out who they are) to see if they would be interested in implementing such things.

Use3D said:

Just wanted to say thanks for the effort and work put into this port. It's a godsend for us vanilla stalwarts that has opened a lot of opportunity for enjoying the mapping process and not being inundated with guesswork and annoyances of the engine. :)

Thanks for using it.

dew said:

That's great effort, Ghostly..Rodent!

Thanks.

[chungy]

Graf Zahl said:

Sometimes I wonder: Is there any warning that's retarded enough for GCC not to implement?

This particular warning is part of a reaction against the goto fail, where code indentation made an extra "goto" statement appear to be inside an if block, when it really wasn't.

When mixing tabs and spaces, there's no way for the compiler to really know how big your tab stops are. Just do all-spaces or all-tabs, don't mix them.

Or I guess you can disable the misleading-indentation warning.

[RestlessRodent]

chungy said:

This particular warning is part of a reaction against the goto fail, where code indentation made an extra "goto" statement appear to be inside an if block, when it really wasn't.

Could have been prevented if sequence points such as logical OR were used, rather than duplicating goto fail like that.

[RestlessRodent]

I implemented a free spectate mode, currently as of this writing you cannot raise or lower your view height. You can use it to look around the level without bringing your clunky human body around. Note that you cannot interact with anything in this mode and your player body is left soulless until you return.

Also made the colors of the visplanes more consistent based on what generated it, when possible. This means that as you walk around, most visplane colors will remain the same (for example, no matter from which angle you are viewing at, the starting alcove in MAP01 is always light green and the dark hallway a dark blue). Note that visplanes do merge, so there is potential for the colors to shift as the viewpoint changes.

This should help a bit.

EDIT: Also added colorblindness simulation (which is probably wrong since it seems the formulas are hard to find).

[RestlessRodent]

Seeing that ChocoRenderLimits is used by map developers and such, would it be possible to get this stickied?

[RestlessRodent]

Once Chocolate Doom 3 is released, Chocorenderlimits will only be following major releases of Chocolate Doom 3 rather than developmental code.

[MinerOfWorlds]

Sorry for the bump but how do i setup ChocoRenderLimits?

[scifista42]

The same way like any other Doom source port: Unpack its zip into a new folder and put copies of your IWADs into that folder.

[MinerOfWorlds]

I guess i got the wrong file then because there was no .exe to run anyway i got it working thanks.

[Szymanski]

Is an updated exe available? couldn't see one in the repository. I'm getting an odd crash with linedef action 37, works fine in chocolate Doom

 

[Redneckerz]

19 minutes ago, Szymanski said:

Is an updated exe available? couldn't see one in the repository. I'm getting an odd crash with linedef action 37, works fine in chocolate Doom

 

Why are you bumping a 3 year old thread for this?

 

DoomWiki lists an SDL2 compatible version of Chocorenderlimits which works mighty fine.

[plums]

50 minutes ago, Szymanski said:

I'm getting an odd crash with linedef action 37, works fine in chocolate Doom

Sounds like something possibly related to https://doomwiki.org/wiki/Stairs_create_unknown_sector_types. Is it consistently reproducible?

[Szymanski]

4 minutes ago, plums said:

Sounds like something possibly related to https://doomwiki.org/wiki/Stairs_create_unknown_sector_types. Is it consistently reproducible?

Thanks, never seen this error before then it happens multiple times in a row

[plums]

7 minutes ago, Szymanski said:

Thanks, never seen this error before then it happens multiple times in a row

In case you weren't aware, linedef type 37 changes the texture and type of the target sector using the numeric model. If it's always happening in the same place, it might be something to do with the numeric model for getting the new sector type not working the way you intend it to, or having some interaction with another linedef type in your map, or something.

[Szymanski]

I'll switch the type, there doesn't seem to be a way to design against it