Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Memfis

Chocorenderlimits link?

Recommended Posts

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.

Share this post


Link to post

Short answer? Yes.

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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).

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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

Share this post


Link to post

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...

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×