Chocorenderlimits link?

Is there no official download link anymore? Last time I needed it I had to go on some ghetto IRC thingy and ask random people.

Short answer? Yes.

(Take the bus to OFTC irc and ask for "shifty dew", he'll fix you up.)

Here's a freshly compiled version. I have put up a post on the DRDTeam forum so that it won't get lost again.

http://forum.drdteam.org/download/file.php?id=3245

Note that this will not work on Windows XP, the code had some dependencies that are incompatible with the XP toolset of recent Microsoft compilers.

I've mirrored it up on my own host as well:

http://static.angryscience.net/pub/hosted/Chocorenderlimits.zip

The trick now is figuring out how to distribute the links to folks who are looking for 'em. Doomwiki is a start.

Hmm, well here is a version that works on my Windows XP machine: http://www.doomshack.org/uploads/CHOCOREN.zip

Is there any reason not to put a build on /idgames?

Not that I know of.
Of course the XP-compatible version should be used then.
BTW, how did you build this? The source I had used a header that's not present in the XP toolset for Visual Studio 2015 and the code did not compile as a result.

It looks like memfis found what you were looking for, OP

Based on the file dates, I'd guess that he only rezipped a directory he already had.

That being said, it still compiles well enough with mingw-w64, and that'll give a XP-compatible build.

It's a shame that chocorenderlimits doesn't seem to be properly maintained. I think GhostlyDeath is still nominally the maintainer but he doesn't seem to have posted in the past half-year, keeps the code in some weird version control system nobody's ever heard of, and doesn't appear to be distributing any binaries. Given that the project looks abandoned I'd encourage someone else to fork the project and start maintaining it.

Just keeping it in sync with Chocolate Doom HEAD and building binaries / doing releases would be worthwhile. For example, a chocorenderlimits release to match each Chocolate Doom release would be nice. But I bet if you go and talk to some of the vanilla mappers out there you'll probably find some worthwhile feature requests.

fraggle said:

It's a shame that chocorenderlimits doesn't seem to be properly maintained. I think GhostlyDeath is still nominally the maintainer but he doesn't seem to have posted in the past half-year, keeps the code in some weird version control system nobody's ever heard of, and doesn't appear to be distributing any binaries. Given that the project looks abandoned I'd encourage someone else to fork the project and start maintaining it.

Just keeping it in sync with Chocolate Doom HEAD and building binaries / doing releases would be worthwhile. For example, a chocorenderlimits release to match each Chocolate Doom release would be nice. But I bet if you go and talk to some of the vanilla mappers out there you'll probably find some worthwhile feature requests.

I performed a basic conversion to Git which is available at http://github.com/GhostlyDeath/ChocoRenderLimits, the branch is called chocorenderlimits. The revision builds and runs (at least on my Linux system).

I will agree that someone else take over the project and become the maintainer of it. This would be far better than creating pull requests/patches because it would likely be awhile before I notice and apply them. I would not be against a fork and new maintainership since that is one of the powers of open source software.

Chocorenderlimits 2.0 is not feature complete although it does have some changes and some basic infrastructure needed to write the remainder of it. Right now only visplanes are drawn. I would recommend that the advanced menu system be kept in place along with the way settings are used since using a menu is far easier than having keybinds for the functionality (more verbose and you do not have to remember keys or have fights with your bindings).

GhostlyDeath said:

I will agree that someone else take over the project and become the maintainer of it.

Thanks! I won't be taking it on myself but hopefully someone will volunteer.

So are you also going to abandon fossil completely and convert remood to use github as well?

fraggle said:

But I bet if you go and talk to some of the vanilla mappers out there you'll probably find some worthwhile feature requests.

Since it's been brought up, I'd love to see those durn X,Y,Z coordinates go away (or at least move to the bottom). They're pretty obstructive:


Worse still, when you enable "overflows only" mode, the fraggin' coordinates still show up. D:


It's a fantastic tool despite said gripe, so thanks to GhostlyDeath while he's magically present. :P

I think there should be a mode where visplanes are displayed as ammo and segs - as armor. Or something. All other stuff is usually completely irrelevant and there is no need for any text to obstruct the view when you have the status bar.

Danfun64 said:

So are you also going to abandon fossil completely and convert remood to use github as well?

No. Personally I prefer Fossil much more than Git since it has a built-in version controlled ticket tracking system, is stored within a single file (easier to work with), and the web UI feature is pretty nice and consistent.

I just converted Chocorenderlimits to Git (in a lazy fashion) because Chocolate Doom itself is in Git and it is easier to pull in contributions without requiring a conversion step (which Fossil can perform though). Plus, I would say that it is easier for others to contribute also without worrying about Fossil.

If someone makes some code, they can create a pull request and notify me for bringing it in. I am very busy and my interests are currently elsewhere (what keeps me busy is quite interesting) so ReMooD and Chocorenderlimits do not have my full attention.

Xaser said:

Since it's been brought up, I'd love to see those durn X,Y,Z coordinates go away (or at least move to the bottom). They're pretty obstructive:
http://i.imgur.com/YOmMjKO.png

Worse still, when you enable "overflows only" mode, the fraggin' coordinates still show up. D:
http://i.imgur.com/Ir4b1Nx.png

It's a fantastic tool despite said gripe, so thanks to GhostlyDeath while he's magically present. :P

That is actually the old version of Chocorenderlimits which is based on Chocolate Doom 1, while Chocorenderlimits 2 is based on Chocolate Doom 2. Chocorenderlimits 2 does not have the coordinate drawing, but currently only has visplanes.

Thanks.

Memfis said:

I think there should be a mode where visplanes are displayed as ammo and segs - as armor. Or something. All other stuff is usually completely irrelevant and there is no need for any text to obstruct the view when you have the status bar.

I want to avoid bringing in unneeded resources or adding complexity to certain parts of the code (such as the status bar). At best, the status bar would just become a solid gray box with text on it. But then again, you can always just increase the screen size.

Memfis said:

I think there should be a mode where visplanes are displayed as ammo and segs - as armor. Or something. All other stuff is usually completely irrelevant and there is no need for any text to obstruct the view when you have the status bar.

How about putting them on the general ammo count? Platforms, sprites, segments, and planes could replace bullets, shells, rockets, and cells.

Does ChocoRenderLimits sound the alarm or log something to disk if you encounter a visplane overflow? There's always the possibility that you run so fast through a level that you miss a single fatal tic when the visplane buffer is overrun.

It keeps the maximum value and there's a key to return to the position where it was hit.

Semi-offtopic, posting here before I forget. Render limits is made for testing. There should be another bindable key for +use that opens doors, lifts without returning them. Internally, repeatable actions should function as single use. Then another key that resets them.

Precise VPO hunting can be tricky if two doors need to be open and player needs perfect positioning. May need to open a door or two as fast as possible and spend 1/4 of a second looking for VPO positions. If auto-resetting features act as single use, then player has more than enough time to VPO hunt.

That's a good point. Going by chocorenderlimits' output, blinky sectors mess with the visplane count in quite an unpredictable pattern. One has to stand in a position and observe how high the maximum goes. Constantly closing doors and raising lifts obviously make this process mroe annoying. On the other hand, I'm not sure all the action-wait-action logic can be translated into one time actions easily.

I can imagine it working if the player had 3 separate use buttons: One regular, one "begin/end line special", and one "end sector special" (the last one applying to the sector that the player is currently standing in). For example, he'd press a lift action linedef by "begin/end line special", which would call a lift down, and it'd stay down, until he either uses the same linedef again by "begin/end line special", or steps away from the linedef and uses "end sector special" while standing in the lift sector, both of which would make the lift raise into its original height. Similarly with doors.

Quick solution or option. "Open all" triggers all actions in a map.

Not sure whether this helps but I got sick an tired of map authors designing levels with the switch that operates a lift or opens a door positioned a long way from the item in question necessitating a frantic dash before the lift/door closes again.
So my port has a built in cheat whereby holding down the ` key pauses the countdown for these actions.
May be able to do something similar here.

Catoptromancy said:

Quick solution or option. "Open all" triggers all actions in a map.

Will that really help? Some actions may actually close a line of sight - and opening everything at once may create situations that are unrealistic.

Feature request for any perspective devs: choco recently introduced enforcing vanilla's lump count per file limit. It would be nice if CRL gave a warning about this, but ran the game anyway. Internal builds of BtSX are fat.

Basing a new CRL on Crispy Doom seems appropriate to me. It removes limits, but you can still implement warnings about going over them.

chungy said:

Basing a new CRL on Crispy Doom seems appropriate to me. It removes limits, but you can still implement warnings about going over them.

What would it actually buy you? Most of the nice features of crispy are pretty pointless when VPO hunting surely

Perhaps it would just be best to base on Chocolate while adding Crispy's limit removing features and nothing else. I'm sure some features (increased resolution, additional features) would be more of a hindrance than a help...

chungy said:

Basing a new CRL on Crispy Doom seems appropriate to me. It removes limits, but you can still implement warnings about going over them.

Danfun64 said:

Perhaps it would just be best to base on Chocolate while adding Crispy's limit removing features and nothing else. I'm sure some features (increased resolution, additional features) would be more of a hindrance than a help...

Using a higher game resolution or using a tweaked design will essentially change how and where visplane overflows occur (if they occur at all). Also, increasing even the limits affects how things are drawn which may add or remove VPOs or change other aspects of how levels appear. For example, you can increase the number of visible segs, but that would have the side effect of also allowing more visplanes to be drawn. Thus an area will falsely appear to have a VPO even when it does not in the Vanilla engine. Also additionally, increased segs means that more of the level is drawn instead of just being one giant HOM in the distance.

Classic ChocoRenderLimits increases the limits, but ChocoRenderLimits 2 does not (it uses cheap exception handling via longjmp/setjmp to jump out of the renderer and not render anything after a VPO for a given frame, since skipping part of the rendering process is not fatal).

So no, if you want to know where these things happen in Vanilla you must keep the renderer the way it is for the most part.