Will Be Working On Chocorenderlimits 2.0

[RestlessRodent]

Hello,

I will be working on Chocorenderlimits 2.0 soon so I would like to know which features you would like to see (besides what already exists in CRL 1.0). Also any thoughts on existing ideas by others.

My ideas so far:

• There will be a menu to access different ways of seeing and doing things, those actions will also be bound via the setup utility if you need such things.
  
• Death slides at various speeds (walk, run, SR40, SR50, a rocket blast right behind you, a virtualized hit by a BFG ball) to see if something can be slid under when dead.
  
• Vile jumping including thrust by the miniature explosion it generates.
  
• Grid pillars, visible vertical lines on the screen which indicate grid of sorts like the blockmap.
  
• Visible spawn points?
  
• Disabling monsters seeing you and adding indicators on them to indicate that they would see you, same would go for sounds you make at a specific point in time. Could show the automap with indicators showing with nearby monsters would be waken up by seeing you or by a sound your weapon (or fist) makes.
  

[TimeOfDeath]

Enabled cheat codes plz.

[RestlessRodent]

TimeOfDeath said:

Enabled cheat codes plz.

I am assuming in Multiplayer/Nightmare mode?

[40oz]

GhostlyDeath said:

Visible spawn points?

Disabling monsters seeing you and adding indicators on them to indicate that they would see you, same would go for sounds you make at a specific point in time. Could show the automap with indicators showing with nearby monsters would be waken up by seeing you or by a sound your weapon (or fist) makes.
[/list]

I made something like that with dehacked if you wanted to look at it for reference.

http://www.doomworld.com/vb/doom-editing/70261-notarget-dehacked-patch/

[RestlessRodent]

40oz said:

I made something like that with dehacked if you wanted to look at it for reference.

http://www.doomworld.com/vb/doom-editing/70261-notarget-dehacked-patch/

Interesting, however naturally all of my changes would be in code. Teleport destinations and objects in general can get lines drawn around them to show their dimensions in the map and could show if any of them intersect with another object (stuck object). There could be colormap cycling to determine how well you can see in an area with specific powerups and at specific gun flash levels without worrying about the short duration that they last.

I can also put in a "hide monsters/items/decorations" kind of thing that just temporarily removes (really code skipping) said objects from the map so they cannot interact or be interacted with.

[Da Werecat]

The sky was always drawn as 1 visplane in 1.0. As far as I understand, it's not always the case.

[Xaser]

Here's a big idea for you: Would it be possible to add a "visplane screenshot" button that would dump an overhead (automap) screenshot of justt the currently-rendered lines and planes (at time of screenshot)? A lot of times I find myself headscratching at exactly what is causing so many planes to generate, and it's often unclear what's even being rendered due to stuff in the distance, etc.

Dunno how feasible this is due to the dynamic nature of visplanes, but if there's any way to extrapolate what bits of what sectors are being rendered per-plane (with lines streaking to the player, I suppose, indicating the visual separation), that'd be the best damned thing.

[TimeOfDeath]

GhostlyDeath: Sorry, I must be misremembering things. Getting old...

[traversd]

Is it feasible to activate all visible linedef actions by a hot key? Ie: press P and all linedefs set to d1 open to maximise LoS from a particular viewing area.

Activating plats like this remotely might cause no more plats limit though.

[RestlessRodent]

Xaser said:

Here's a big idea for you: Would it be possible to add a "visplane screenshot" button that would dump an overhead (automap) screenshot of justt the currently-rendered lines and planes (at time of screenshot)? A lot of times I find myself headscratching at exactly what is causing so many planes to generate, and it's often unclear what's even being rendered due to stuff in the distance, etc.

Dunno how feasible this is due to the dynamic nature of visplanes, but if there's any way to extrapolate what bits of what sectors are being rendered per-plane (with lines streaking to the player, I suppose, indicating the visual separation), that'd be the best damned thing.

This is possible but it might not appear how you think (or at least how I think you think). Visplanes are emitted from segs and may or may not actually be drawn (they could be so far away to not emit any pixels but still count). How this would work in the automap would be segs highlighted with lines from the edges casted to the viewport. Some segs can share the same visplane (convex polygon going in). I could do this by just reverse mapping and storing which segs get visplanes attached. However since this is a renderer artifact, I could have an overlayed automap to make it easier to visualize. To make it more visible I would have to project edge lines to the player with specific colors then flood fill (like flats). So the automap would look like a bunch of pizza slices overlapping each other.

As for drawing the actual pixels that are rendered, that would be limited in range (it should stop or speckle after a certain distance), and that would also require some complex reverse math in the span drawing code. It probably will not much useful compared to the pizza visplane drawer.

EDIT: Since visplanes are attached to segs, this is why when there are seg overflows and they stop drawing where you see huge slices of HOM in the distance where floors are and such.

Da Werecat said:

The sky was always drawn as 1 visplane in 1.0. As far as I understand, it's not always the case.

The sky always takes up a single visplane, whether it is on the ceiling or the floor. However if you have multiple skies in view then it will take up multiple visplanes.

EDIT:

traversd said:

Is it feasible to activate all visible linedef actions by a hot key? Ie: press P and all linedefs set to d1 open to maximise LoS from a particular viewing area.

Activating plats like this remotely might cause no more plats limit though.

Might be better just to have a toggle that acts as if all doors are opened and lifts are lowered (but not really in the game).

[Da Werecat]

GhostlyDeath said:

The sky always takes up a single visplane, whether it is on the ceiling or the floor. However if you have multiple skies in view then it will take up multiple visplanes.

And yet the counter shows 80 visplanes more:



It's even more than when the floor is regular:



It appears to me that lighting affects the sky, even though it shouldn't.

[BlueFeena]

Da Werecat said:

It appears to me that lighting affects the sky, even though it shouldn't.

Doom has always done this; identical sky planes are merged while ones with any differences -- such as with lighting, effects, or a unique floor or ceiling texture -- prohibit Doom from merging them. The latter is how sky-over-sky effects can be achieved in vanilla.

[RestlessRodent]

Da Werecat said:

And yet the counter shows 80 visplanes more:

It's even more than when the floor is regular:

It appears to me that lighting affects the sky, even though it shouldn't.

When you said "The sky was always drawn as 1 visplane in 1.0." I took that to mean that the version currently out there that the visplane counter was miscounting for skies and that every single variation of sky got merged. In my reply I was mostly thinking of simple convex sectors where skies are set.

I will have to add visplane mapping for when skies are drawn possibly so that visplanes that represent the sky can actually be seen.

[Xaser]

Regarding skies, vanilla Doom (and some ports like PrBoom and Eternity -- perhaps all non-ZDoom ports?) does not join sky sectors at all if the light level changes. This is a huge consideration if you're going for "sky portal" effects, since you can totally break the scene by adjusting the lighting in the wrong spot.

GhostlyDeath said:

This is possible but it might not appear how you think (or at least how I think you think). Visplanes are emitted from segs and may or may not actually be drawn (they could be so far away to not emit any pixels but still count). How this would work in the automap would be segs highlighted with lines from the edges casted to the viewport. Some segs can share the same visplane (convex polygon going in). I could do this by just reverse mapping and storing which segs get visplanes attached. However since this is a renderer artifact, I could have an overlayed automap to make it easier to visualize. To make it more visible I would have to project edge lines to the player with specific colors then flood fill (like flats). So the automap would look like a bunch of pizza slices overlapping each other.

That'd be boss. I'm not interested in the pixels actually being drawn, just the planes that are being "counted," since that'd do a lot to highlight areas far in the distance that are generating planes -- the fact they aren't actually visible in-map can be just verified with an in-game screenshot, I feel. The "pizza slice" method would certainly help solve the problem I keep running into about which pesky window to close. :P

Visplane mapping for the sky would be useful as well. I've in the past tried to get a count by floodfilling the sky with a regular flat, but that actually changes the plane count. Insert "quantum mapping" joke here.

[fabian]

Xaser said:

Insert "quantum mapping" joke here.

Schroedinger's Map :) *duck*

[RestlessRodent]

Currently working on it, so far there are only visplane counts and a basic menu. Instead of key binds, there will instead be a menu which can be activated to toggle things (more friendly and less memorization required, but is going to those who have muscle memory).



In the image there are 52 visplanes, 24 of the C type and 28 of the F type. C planes generated by R_CheckPlane and F planes generated by R_FindPlane. Eventually when things get colorful they will have different brightness levels so you can tell in which renderer function they were generated in.

Accessing the menu is like a normal menu and thus pauses the game, it can be opened by pressing the `~ key by default (unless it is changed).

Currently going to concentrate on Doom, then once that is all working great it will be adapted to the other games.

The repository syncs on the hour, locally.

$ fossil clone http://remood.org:8080/crl/ crl.fsl
$ mkdir crl
$ cd crl
$ fossil open ../crl.fsl
$ ./configure
$ make
$ src/chocorenderlimits-setup
$ src/chocorenderlimits-doom

Now if a moderator could change "Will Be" to "Am"...

[esselfortium]

Great to see some Chocorenderlimits news :)

The menu system sounds like a nice idea, since the FKEY toggles could get pretty unwieldy. It'd be ideal if functions could still be bound to keys via a config file or something, though, so that features that you're frequently making use of can still be accessed quickly without pausing the game and navigating a menu.

Is CRL 2.0 based on the current Chocodoom version?

A couple of things I can think of that would be useful:
- Max Drawsegs memory/warp function like there is for visplanes.
- Bindable key commands for useful testing functions like noclipping and godmode, to make them easier to quickly toggle.
- I've found that a lot of users aren't aware that showing the statusbar typically results in fewer planes being drawn. Is it possible to somehow always draw the game at full size and then optionally overlay the statusbar on top of it, maybe? It'd eliminate a lot of confusion.

[RestlessRodent]

esselfortium said:

Great to see some Chocorenderlimits news :)

The menu system sounds like a nice idea, since the FKEY toggles could get pretty unwieldy. It'd be ideal if functions could still be bound to keys via a config file or something, though, so that features that you're frequently making use of can still be accessed quickly without pausing the game and navigating a menu.

After getting base features in, I will probably add binds (once everything is in there so it does not get forgetten), they would be accessed by going into chocorenderlimits-setup keyboard options.

esselfortium said:

Is CRL 2.0 based on the current Chocodoom version?

Based on Chocolate Doom 2.1.0, which means the stuff could be ported over to Heretic, Hexen, and Strife (if they have some of the same limits). I am coding it in a way where it is engine agnostic mostly.

A couple of things I can think of that would be useful:

esselfortium said:

- Max Drawsegs memory/warp function like there is for visplanes.

I could store warp points for the highest points for all the counted types, so you could go into the menu and change which max point you want to see then execute a warp there.

esselfortium said:

- Bindable key commands for useful testing functions like noclipping and godmode, to make them easier to quickly toggle.

That could easily be done for all of the cheats.

esselfortium said:

- I've found that a lot of users aren't aware that showing the statusbar typically results in fewer planes being drawn. Is it possible to somehow always draw the game at full size and then optionally overlay the statusbar on top of it, maybe? It'd eliminate a lot of confusion.

That could be done, I would probably add another window size level so that you can still retain the original screen size when needed. Perhaps make the status bar transparent so it could still be seen but while having stuff underneath it also visible.

[Gez]

GhostlyDeath said:

In the image there are 52 visplanes, 24 of the C type and 28 of the F type. C planes generated by R_CheckPlane and F planes generated by R_FindPlane.

It's kinda unfortunate that those letters can easily be confused with Ceiling and Floor.

[MP2E]

More than a few serious bugs have been fixed in chocolate doom's master since v2.1.0, I would recommend basing changes off of that.

[RestlessRodent]

Drawing of visplanes, you will now notice that the visplanes generated by the sky are now indicated. The current draw mode is overborder (draws over everything and only draws lines on the border pixels of planes). The dark colors are find planes, while the lighter colors are check planes.

MP2E said:

More than a few serious bugs have been fixed in chocolate doom's master since v2.1.0, I would recommend basing changes off of that.

Which kind of serious bugs?

Gez said:

It's kinda unfortunate that those letters can easily be confused with Ceiling and Floor.

Changed the lettering to be more informative.

[esselfortium]

Showing the sky planes is cool :)

From a mapper's perspective, what's the distinction between check planes and find planes? Is it something that really matters?

[Foxpup]

esselfortium said:

From a mapper's perspective, what's the distinction between check planes and find planes? Is it something that really matters?

R_FindPlanes() generates a plane for each unique flat/height/light combination, and crashes with the error "no more visplanes" if there are too many. If such planes are not contiguous, R_CheckPlanes() splits them up, creating a new plane with the same properties for each split, and crashing with a visplane overflow if too many planes are created.

In terms of mapping, R_FindPlanes() is affected only by the number of flat/height/light combinations, while R_CheckPlanes() is affected by map geometry (it's a well-known fact that you can get a VPO with only two sectors with sufficiently perverse geometry).

[RestlessRodent]

esselfortium said:

Showing the sky planes is cool :)

From a mapper's perspective, what's the distinction between check planes and find planes? Is it something that really matters?

Just where they are created (and by what piece of code).

"Check" planes are created when segs are processed (if they are drawn) and they only merge when they are generated by adjacent segs. Any merges done by R_CheckPlane are based solely on X position going from the left side of the screen to the right, cases where segs go from right to left are never reached because the backsides of segs are "culled". Segs make up subsectors and thus those are how those are generated. These "check" planes are more common than find planes because they can be created in more places.

"Find" planes are created by the BSP traversal, if the surface (floor or ceiling) is visible then these planes are generated. The visplanes created here take up negative screen space (so they are not drawn). These virtual visplanes will later be changed by R_CheckPlane which will change the plane properties whens segs in the current BSP segment are traversed. So it is really just a potential cache of plane properties (height, light, and texture) before segs are processed.

If you see a "Find" plane then it is a completely unsplit visplane, however once "checks" are seen that means a visplane is being split.

EDIT: The most wasteful visplanes are of the find type, they are pretty much created for every (sub)sector that is currently in view. So if you look into the cage where the imp is near the MAP01 exit door (while the sound tunnel is not in view) you will see 4 planes are being created even though you only see 2 (the merged floors from outside into the inside of the cage, and the cage ceiling). Since find planes are always created during BSP traversal, even if no planes are in view and should ever be in view you will still get a minimum of 2 visplanes at all times. Certain BSP locations may have even higher minimum visplanes. That depends if the node you are in traverses to some other node. So the act of being in a certain sector may create pointless visplanes you cannot see anyway.

[RestlessRodent]

From working on this current feature, you can tell that the Doom renderer sucks in some areas. And if you look at the following picture...



You will see that in MAP01, that visplanes can be generated for sectors that are not even in view and are behind walls. This might just be a cause for a bad nodes builder since I do not exactly have any visplane/renderer heavy stuff (conduits does not count).

Visplanes are either generated from subsectors or segs, so the map might look strange but it will colorize anything that it thinks is creating a visplane. This works for most visplanes generated from normal segments but becomes rather unknown on the higher level BSP planes where subsectors are involved. Since the subsector planes are probably virtual the segs that make up the subsector is highlighted.

However, if this remains regardless of the nodes builder then one may have to modify an adjacent room to remove some unwanted visplane overflows.

Eventually in the future if actual subsector shaping is done (if more attempts at my polygon splicing are successful), then I would switch to that to represent subsectors rather than just using the segs (which are always aligned to walls) and would also include implicit edges created by the BSP tree.

EDIT: The visplanes generated past blockable walls are artifacts of sub optimal BSP trees, so using a poor nodes builder can result in an increase in visplanes.

[Xaser]

Wicked cool thus far! And wow, that's some really wonky node work if it's doing that... whew. :P

If you need a tester, hit me up. I'm still tinkering with vanilla stuff with DTWID-LE and NEIS, so those would be good testing grounds.

[kb1]

GhostlyDeath said:

This is possible but it might not appear how you think...

Interesting. Here's something which might be helpful:

My port counts the frame's visplanes in a variable 'num_visplanes'. As an experiment, I added a check to both the floor and ceiling in R_SubSector:

	if (num_visplanes >= 128)
		floorplane = NULL;
	else
	{
		floorplane =
			frontsector->floorheight < viewz ||
			(frontsector->heightsec != -1 &&
			sectors[frontsector->heightsec].ceilingpic == skyflatnum) ?
			R_FindPlane(frontsector->floorheight,
				frontsector->floorpic == skyflatnum &&
				frontsector->sky & PL_SKYFLAT ? frontsector->sky :
				frontsector->floorpic,
				floorlightlevel,
				frontsector->floor_xoffs,
				frontsector->floor_yoffs
			) : NULL;
	}

	if (num_visplanes >= 128)
		ceilingplane = NULL;
	else
	{
		ceilingplane =
			frontsector->ceilingheight > viewz ||
			frontsector->ceilingpic == skyflatnum ||
			(frontsector->heightsec != -1 &&
			sectors[frontsector->heightsec].floorpic == skyflatnum) ?
			R_FindPlane(frontsector->ceilingheight,
				frontsector->ceilingpic == skyflatnum &&
				frontsector->sky & PL_SKYFLAT ? frontsector->sky :
				frontsector->ceilingpic,
				ceilinglightlevel,
				frontsector->ceiling_xoffs,
				frontsector->ceiling_yoffs
			) : NULL;
	}

Also, have the standard HOM check:

// I_ClearBuffer
// [kb] Optionally flashes the screen buffer red for HOM detection,
//  or blackens the screen while no-clipping.
void I_ClearBuffer (int clearbuffer)
{
	if (gamestate == GS_LEVEL && wipegamestate == GS_LEVEL)
	{
		if (flashinghom)
		{
			// flash the frame buffer red so the HOM effect will be visible
			memset(screens[0], (gametic & 8) ? 0 : 176, SCREENWIDTH * SCREENHEIGHT);
		}
	}
#endif
}

The effect is that visplane #128 and beyond flash red. Of course, that only means that, in this frame, those planes are causing vp overflow, but, I suppose you could move around and be able to eventually know all the plane that are involved.

Benefits are that this code is easy to implement, and, as a bonus, you get HOM highlighted! You could go a step further, and change it so, after visplane #127, you set a renderer flag "draw_planes_green = true". Then, you'd have red flashing HOM, and green vp overflow planes.

What do you think?

EDIT: By the way, very nice work do far! Good job!

[RestlessRodent]

kb1 said:

Interesting. Here's something which might be helpful:

My port counts the frame's visplanes in a variable 'num_visplanes'. As an experiment, I added a check to both the floor and ceiling in R_SubSector:

Code

Also, have the standard HOM check:

Code

The effect is that visplane #128 and beyond flash red. Of course, that only means that, in this frame, those planes are causing vp overflow, but, I suppose you could move around and be able to eventually know all the plane that are involved.

Benefits are that this code is easy to implement, and, as a bonus, you get HOM highlighted! You could go a step further, and change it so, after visplane #127, you set a renderer flag "draw_planes_green = true". Then, you'd have red flashing HOM, and green vp overflow planes.

What do you think?

EDIT: By the way, very nice work do far! Good job!

NULLing out R_FindPlane in R_Subsector could create renderer issues and hide the fact that there are VPOs even if R_CheckPlane creates the planes. Because on maps with bad node builders, those R_FindPlanes that get nulled out might be areas you cannot even see despite them being generated.

Currently in CRL 2.0 I have per pixel assignment to visplanes, a bit wasteful but each drawn pixel has a specific map to something. This is done to simplify the code so that there is less duplication in all of the engines.

Instead of the old "sneak" feature (that nobody probably ever uses) I will use the automap to replace it, so if there is a VPO you can just look at the map to see what is causing the overflow and such and it is much easier to see what may be causing the overflow. In most cases you would just need simpler geometry in the surrounding area and the area you are looking through.

For color flashing, I have decided that I will do a pulse effect instead (like the slow fade in fade out light in Doom) since that would be much easier to see and to identify the different planes. Anything that is a problem (overflows, HOM, etc.) will slowly change to another color rather than just flash, since flashing bright colors quickly is riskier (health wise) than flashing dull colors.

[kb1]

GhostlyDeath said:

NULLing out R_FindPlane in R_Subsector could create renderer issues and hide the fact that there are VPOs even if R_CheckPlane creates the planes. Because on maps with bad node builders, those R_FindPlanes that get nulled out might be areas you cannot even see despite them being generated.

You would toggle the "> 128" rule on and off. The HOM indicator just ensures that you can see the difference, by clearing the screen. If toggled rapidly, it would become visually obvious which visplanes were > visplane 127.

However, you're right, other map/geometry issues would also be highlighted (which could actually be a good thing). It could be considered another tool in your arsenal, for perfecting vanilla maps.

Another idea:
1. Paint the screen black.
2. Draw the first 128 visplanes.
3. Set a renderer flag "draw_yellow = true".
4. Draw the remaining visplanes using a "draw_yellow" renderer function.

Well, that's it for my babbling. Carry on. You've got a good handle on it :)

[RestlessRodent]

Necrobump!

Worked on this some more, since the last time:

• Updated to Chocolate Doom 2.2.1.
  
• Toggleable MAXVISPLANES, either 128 or 4096. Note that if the I_Error for visplanes is reached it will just stop rendering (so the game looks as if it were a giant HOM).
  
• Added a slower faded background before each render frame to detect for HOMs and such. The super flashy magenta can be a bit seizure inducing.
  

Note that so far, the original CRL is more featureful.

As always there may be delay as to when my latest code is made visible.