[ck3D]

Hi, so since MAXSPRITESONSCREEN was cut from 4096 to 2560 in 2017, that had the side effect of causing a lot of user maps released 2013-2017 to look off in new builds, but it was just brought to my attention that the value could still be modded in .con (by calling setu .maxspritesonscreen 4096). I've been trying calling that from all kinds of events, and setting all kinds of values for it but this has no effect as apparently the value dictated by the engine persists with overriding it. Reaper_Man has been trying to help out there and realized maxspritesonscreen wasn't the only exception either. I'm trying to bump MAXSPRITESONSCREEN back up to 4096 so that the more open levels in my latest release can function in the latest builds just as well as they do in pre-2017 and can do without including a specific Eduke build with it which is terrible practice and blocks the player base from all the further Eduke build advancements. But in general I suspect it would be a pretty important thorn off most mappers and modders' side if this value could in fact be modded. Is that even possible to implement, though? Or am I clueless about so much really? Thanks in advance.

[Reaper_Man]

I poked around the source code and did some tests in CON, it seems like .maxspritesonscreen is read-only (or at least behaves read-only). For comparison, there's several other userdefs that also appear read-only, such as .user_map which returns 1 if the player is playing a usermap and 0 if they're playing a campaign map. The userdef .maxspritesonscreen behaves similarly and always returns the value of MAXSPRITESONSCREEN.

I don't know if this is intentional behavior, or if .maxspritesonscreen is meant to override the default value of MAXSPRITESONSCREEN to (for example) restore pre-2017 sprite rendering limits. I had assumed that was the case based on what few references to it are here on the forum, but looking at the source I don't know if that's true or if this was an oversight.

[Mblackwell]

I believe this would need to be set from DISPLAYROOMS. In Ion Fury we force each skybox to only draw up to 1024 sprites, which keeps the main camera view from having disappearing sprites. It gets set in DISPLAYROOMS before each showview. Not sure what other uses it has, but that's why it was first implemented however long ago.

[ck3D]

I just tested using EVENT_DISPLAYROOMS and in my situation at least, nope, no visible change (which makes sense if there is something weird on the engine side regardless). Maybe that only works when setting the value to something below the 2560 cap (but I'm not going to try that).

[Reaper_Man]

No dice here. Code:

onevent EVENT_DISPLAYROOMS
{
	getu .maxspritesonscreen TEMP
	addlogvar TEMP

	setu .maxspritesonscreen 4096

	getu .maxspritesonscreen TEMP
	addlogvar TEMP
}
endevent

Output:

 6.0491s INFO| EDUKE.CON:6: addlog TEMP = 2560
 6.0491s INFO| EDUKE.CON:11: addlog TEMP = 2560

I tried a handful of other DISPLAY events with the same results.

Then I tried lowering it to 1024 per your example from Ion Fury, and that did work. So it looks like you can in fact lower it from MAXSPRITESONSCREEN, but can't exceed it.

[oasiz]

I think it clamps it to MAXSPRITESONSCREEN which is set to 2560 in build.h (engine side)
case USERDEFS_MAXSPRITESONSCREEN: maxspritesonscreen = clamp(iSet, MAXSPRITESONSCREEN>>2, MAXSPRITESONSCREEN); break;

[Reaper_Man]

In that case, could the upper bound instead be MAXSPRITES or MAXSPRITES>>2 or something like that? The default value could remain 2560 relatively safely, as a modder has to really go out of their way to change this, and probably wouldn't need to in 99% of situations, but still remain an option for maps/mods that require the pre-2017 behavior.

[Aleks]

I had no idea this was possible as just "a regular" option that could have been unlocked from the engine side, always thought this was entangled into some spaghetti code similar to how the sectors/walls/sprites resources are. In fact I've only recently found out that the older builds had 4096 sprites while helping ck3D test some stuff for Blast Radius, but it already seems like a much more reasonable number considering what kind of maps people are making right now (though ideally I'd have this only limited by the framerate, leaving the choice completely to the modder).

Another option would be (from what I've discussed with Oasiz, something similar was implemented in IF) some kind of possibility to set a rendering priority flag on sprites, to at least avoid situations where monsters glitch in and out of view or large parts of buildings randomly disappearing. It would probably be better than just increasing the max number of displayed sprites due to optimizing the framerate, without compromising the visuals/gameplay of the map, similarly to how more modern games are doing it (so e.g. having parts of buildings etc. made of sprites prioritized over small details that won't be seenable from distance).

The problem is that rendering seems to all happen on sector level, and only thing blocking sectors/sprites from rendering are non-existing spaces drawn with white walls.

[Reaper_Man]

Regarding Blast Radius, yes in theory ck could compile a current version of the engine with the MAXSPRITESONSCREEN variable set back to previous amounts, and assuming no other compatibility changes between 2017 and 2023 would affect the mod, it should run fine.

In mainline, I don't know if it really is as easy as changing the clamp upper bounds to a higher value (even to the original 4096 limit) and allowing mods to use userdefs to change that when necessary. Or that there aren't other side effects from changing this that might occur or would need to be considered. But if it is that easy, I would hope we could see that change in a future update so that these maps/mods taking advantage of higher sprite counts could run on current engine versions and not need to rely on distributing older and outdated ones.

I know basically nothing about the renderer side of things, and I can only guess as to the hurdles involved in optimizing how sprites are rendered. I don't know if the engine is doing sprite batching, or batch rendering, or frustum culling, and/or how any of that plays into what sprites are rendered or considered to be rendered. Previously I did some testing and verified that sprites are marked as rendered even if a white wall blocks their view, as long as the sector they are in is set to be rendered. Note that in this case, "rendered" means "inserted into the gotpic array", which means the sprite was at least *attempted to* be rendered. It's entirely possible that "considered to be rendered" doesn't mean "was actually drawn" and this is all a moot point. Again I really know nothing about how that side of things works.

All of this to say: Unfortunately it's not as simple as sticking a white wall between some sprites in order to get them not to render, which may very likely be playing into the MAXSPRITESONSCREEN problems. White walls stop *sectors*, not sprites, from being drawn or considered to be drawn, but if that sector is drawn, all sprites within it (and within the player's field of view, regardless if walls block line-of-sight) are drawn as well.

[Danukem]

Reaper_Man, on 17 February 2023 - 09:30 AM, said:

Previously I did some testing and verified that sprites are marked as rendered even if a white wall blocks their view, as long as the sector they are in is set to be rendered.

This is an important point because it highlights that the practical limit of sprites rendered may be far less than the official 2560 number depending on the context. This tracks with my observations that sprites that should be visible will often flicker or disappear even when the number of visible sprites is far less than the official limit.

So even if it's true that it would be bad mapping practice to make 4096 sprites all visible to the player at once, it does not follow that the max rendered limit should be less than 4096.

[Reaper_Man]

Right, when talking about rendering issues, it's important to make the distinction between what the game engine considers to draw any given frame, versus "things I see on my computer screen". The player could stand in front of a white wall and still have thousands of sprites being drawn, but it's not really the fault of the engine that the mapper poorly designed this space and is causing performance or drawing issues. And I would personally consider a space like that poorly designed, and not that the engine / renderer isn't doing something that it should be doing, and that just because the mapper could physically build that space doesn't mean they should or that they shouldn't have done it differently. (Not saying ck did this, I haven't played Blast Radius yet!) Understanding how BUILD calculates and draws sectors is one of those mapping practices we've had to consider basically from the start. And I am pretty sure the engine has never occluded sprite drawing behind white walls, so this isn't an EDuke thing. I think perhaps this may be something getting lost as computing power can overtake or negate poorly designed spaces. It's not unique to BUILD either, every game engine has it's weaknesses and it's possible to (intentionally or unintentionally) make a space that the engine struggles with. A lot of my experience is in the Source engine, and you have to understand how BSP cuts brush faces, the way visibility sets work and how to manipulate them for performance reasons, and learning to optimize in Source was one of my favorite challenges.

But on the other hand, one of the major benefits of a port like EDuke is the "limit removing"-ness of it and being able to push the engine. I think it makes sense for the engine to have built-in limitations for performance reasons, which I assume is the purpose of MAXSPRITESONSCREEN in the first place, and should be sufficient for all of the retail games as I doubt they ever hit a fraction of the 2560 limit. But also it would be great for mods to be able to "proceed at your own risk" and push past those limits.

[ck3D]

Thanks everyone for all the info. As of today's EDuke32 revision, this is all a non-issue (and an obsolete problem) by now as MAXSPRITESONSCREEN was just bumped back up to 4096 and the rendering even tweaked to allow for more practical leeway, all courtesy of TerminX - thank you! I believe this will be important for EDuke32 content development.