Jump to content
The Dark Mod Forums

Recommended Posts

  • stgatilov changed the title to [2.10] Entity limit removed
Posted (edited)

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 Guest
Posted (edited)

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
Posted

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.

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

Posted

Like I suspected that is way more complicated than I thought but I will try it none the less but to tell the truth, I don't think I will ever need such large amounts of entities.

Posted
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
  • Dragofer pinned and featured this topic
  • Dragofer unpinned this topic
  • 3 months later...
Posted
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.

Posted
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

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.

  • Recent Status Updates

    • JackFarmer

      "The Year of the Rat." 
      😄

      Al Stewart must be proud of you!
      Happy testing!
      @MirceaKitsune
      · 1 reply
    • datiswous

      I posted about it before, but I think the default tdm logo video looks outdated. For a (i.m.o.) better looking version, you can download the pk4 attached to this post and plonk it in your tdm root folder. Every mission that starts with the tdm logo then starts with the better looking one. Try for example mission COS1 Pearls and Swine.
      tdm_logo_video.pk4
      · 2 replies
    • JackFarmer

      Kill the bots! (see the "Who is online" bar)
      · 3 replies
    • STiFU

      I finished DOOM - The Dark Ages the other day. It is a decent shooter, but not as great as its predecessors, especially because of the soundtrack.
      · 5 replies
    • JackFarmer

      What do you know about a 40 degree day?
      @demagogue
      · 4 replies
×
×
  • Create New...