Jump to content

[2.10] Entity limit removed


stgatilov
 Share

Recommended Posts

  • stgatilov changed the title to [2.10] Entity limit removed

Holy shit, fuck yeah! Finally! :D

Edit: All in all, it's a balancing act. While having thousands of tiny models in your visleaf will be bad, combining everything into large models can hurt performance too. If the model is bigger than what you can see in your POV, and there are lights hitting it and casting shadows, those addidional DCs and shadows will impact your performance, even if you don't see such lights.

Edited by peter_spy
Link to comment
Share on other sites

stgatilov I'm right to assume that to increase the entity limit to 65536 is just the case of setting the GENTITYNUM_BITS  to 16? There's no need to change anything else in the engine to support that amount of entities? I want to do it on my version of the dewm3 engine if is not too complicated for me. 

Edited by HMart
Link to comment
Share on other sites

Nice to see this limit go so that the size of an FM is defined by an author's ambition and not some technical limitation.

  • Like 1

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

8 hours ago, HMart said:

stgatilov I'm right to assume that to increase the entity limit to 65536 is just the case of setting the GENTITYNUM_BITS  to 16? There's no need to change anything else in the engine to support that amount of entities? I want to do it on my version of the dewm3 engine if is not too complicated for me. 

TDM may be more susceptible to more fragility around entities due to some of our more complex designs and alterations to the base game.

stgatilov made a number of infrastructural changes to handle the additional overhead that increasing entities can incur.

This tracker has a history of the work:

https://bugs.thedarkmod.com/view.php?id=5439

and you can compare that to the git revision history here:

https://github.com/fholger/thedarkmod/commits/master

  • Like 1
  • Thanks 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

9 hours ago, HMart said:

stgatilov I'm right to assume that to increase the entity limit to 65536 is just the case of setting the GENTITYNUM_BITS  to 16? There's no need to change anything else in the engine to support that amount of entities? I want to do it on my version of the dewm3 engine if is not too complicated for me. 

You can try: it will probably work.

I would say it's better to do r9167 about EntityPtr, since otherwise it will be hard-limited by 32768 or 65536 (two entity indices stored in one 32-bit number).

Most of the other changes are about optimization: the original code often creates local array with NUM_GENTITIES elements, which is not very good for performance if you raise it to 64K. But perhaps it's not so critical, since all these arrays are left uninitialized: it's only stack caching performance that's lost. That's the reason behind the largest commit r9158.
Without commit r9156 the map with many entities will shutdown slowly.

You will also need to port the interaction table from TDM, because the original [Enum x Lnum] matrix will eat awful amount of memory, also hard-capping the number of entities at something like 16K.

Network code will probably give some headache. In TDM it is partly removed, but there were some large arrays, like with 32 * NUM_GENTITIES elements. Note sure how they are used, but keep an eye on multiplayer performance in case there are many entities.

  • Like 2
Link to comment
Share on other sites

  • Dragofer pinned and featured this topic
  • Dragofer unpinned this topic
  • 3 months later...
On 3/2/2021 at 9:52 AM, stgatilov said:

You should never inline entities --- that's a very bad idea!

Could you expound a bit on why this is true? For one of my planned wiki articles. Thanks.

Link to comment
Share on other sites

7 hours ago, Geep said:

Could you expound a bit on why this is true? For one of my planned wiki articles. Thanks.

Because inlined geometry of a model goes through dmap processing.
The more such models you have, the longer dmap takes. Chance of complicated geometric algorithms failing also increases.

Are there any benefits of inlining?
One less entity is not a reason any more (and probably combining close models into one is better than inlining models). Yes, dmap can remove some invisible geometry and precompute stencil shadows. But with the costs outlined above.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recent Status Updates

    • nbohr1more

      Anyone have any luck with light.setShader( string ) ? It seems to make whichever light you apply it to full-bright on the initial invoke?
      · 0 replies
    • thebigh

      I'm starting to think we need another mapping contest.
      · 9 replies
    • kano

      Don't you hate it when there's a quality discussion on a forum somewhere online about something, but then two disagreeing users derail and transform it into a back-and-forth poo slinging competition at one another?
      · 9 replies
    • Diego

      Oh look the status updates are back! 
      · 2 replies
    • JackFarmer

      After watching the first three and a half episodes of "The Sandman" last night, I realize once again that overly imaginative narratives are not for me. Also, the main actor looks like he has a toothache.
      Which makes me wonder, is there a Dark Mod mission with a medieval dentist?
      · 4 replies
×
×
  • Create New...