Teeworlds - bridge

currently every time an entity is marked for destruction CGameWorld::RemoveEntity is called twice, once in RemoveEntites explicitly and once through ~CEntity()

16:31

This isn't a problem when you have a single gameworld, but when working with multiple gameworlds, the gameworld reference is already invalid as soon as the entity is removed from a world, which causes a null pointer dereference

huh, where should it be destructed then?

Well either explicitly RemoveEntity, or let the destructor do RemoveEntity. With ddnet I stopped letting entities self-insert/remove to/from worlds so I explicitly insert/remove the entities I create/destroy

destructor samantically better

letting the destructor do it is a little dangerous when you can override the destructor though

and you can't override an yothe rmethod?

17:22

RemoveEntity for example

RemoveEntity is a method of the game world

overridable?

17:23

it's the same argument that doesn't say anything

17:24

if you can break your leg by walking, you should not walk is what I see here as an argument

First of all, it's much more common to inherit from CEntity then CGameWorld

semantically a destructor removes an object properly and cleans up afterwards

Second, RemoveEntity is indeed not a virtual method, so if you are trying to override it you are obviously doing something wrong

well, then keep it as is

Third, CGameWorld is a "container" an item of the container affecting it's container is hardly great encapsulation, items don't remove themselves from linked lists

17:27

As is you are calling RemoveEntity twice. If you are okay with that, knock yourselves out, just wanted to point out a problem I encountered during development

usually the destructor should be called in reverse order by inheritance(if I'm not off here), thus you don't override it, but overshadow, I guess implementing the entity destruction for every class in the base class CEntity would make sense and not care about inheriting classes

17:28

actually doing anything about the removal from the World class

17:29

short, implement in CEntity destructor and let inheriting classes not care about the removal from the world object

just put that in RemoveEntity and call it a day

Which is what is done currently, but you are also calling RemoveEntity from CGameWorld::RemoveEntities, which is the double call I'm talking about...

17:33

If you are letting the entities handle the removal from the world, fine, be consistent about it

mind linking the code lines?

grepr removeentitysrc/game/server/gameworld.cpp:85:void CGameWorld::RemoveEntity(CEntity *pEnt)

the problem lines

gameworld.cpp#157 is the extra call I'm talking about

17:39

But the problem is there is no guarantee that Destroy() will lead to a RemoveEntity() as Destroy is a virtual method. I'd just get rid of destroy and delete the entity there and let the destructor chain handle it

I find the Destroy() function rather weird.

But then CCharacter doesn't actually destruct itself on Destroy() so that'd break that

17:41

Which is one of the reasons why I took the other approach

17:41

More flexible and in my case allows me to easily move entities between gameworlds

nice, so CCharacter inherits the weird Destroy funcrtion and overshadows it with a newly implementation that doesn't contain the code of the inherited destroy function from CEntity

Which is intended by the way, characters aren't destroyed, they are set not alive and set alive when spawned

calling both functions the same is imo bad

17:48

would prefer if the "delete this" war removed, but might break a lot of stuff

17:48

was*

There are a handful of places where Destroy is called, it's not too hard to rework

also funny: CCharacter has a reset function, that calls Destroy, then why not use Reset instead of Destroy

17:49

as both do the same

also funny: nothing ever should be calling Destroy on a CCharacter anyway

17:49

except itself

publicly accessible

17:50

should at leats be protected for inheritance purposes.. ,Destroy is bad imo

17:51

CEntity::Destroy

It's the only natural solution if you want to delete entities but also want entities that can't be deleted

I wonder if that will mess up mods that merge without being aware enough of what's going on

17:53

only those with several worlds are affected I imagine

Just removing the RemoveEntity on L157 shouldn't change anything, only entity that behaves differently is CCharacter and that is never supposed to be deleted anyway let alone marked for destruction

mind elaborate on that, ccharacters cannot be deleted as you said? but rest can?

@jxsl3 they can be deleted ofc, they just never are

17:55

Destroy for CCharacter is never called except if CCharacter calls it, so it's pointless anyway

why is delete pEnt not a feasible solution on line 158 instead of pEnt->Destroy()?

17:57

delete pEnt;

17:58

hm, character

"I could fix it right, or I simply use smartpointer"

teeworlds = anti stl

STL = pure garbage*

17:59

C++ committee member

@jxsl3 A character is never to be marked for destruction as far as I can see

(and because dune hates stl)

Dune: STL has a couple useful things, smart pointers are pretty nice

(and I don't know how bit the commitee is, so I cannot evaluate your value as one person there)

Oh yeah, STL has a lot of useful things

big*

Only the implementation of containers is systematically garbage

18:00

If you don't care about performance, STL is fine. And it's really stable!

don't hate on vector, even tho it's naming is garbage

smartpointer are the best thing to make bad software at least have less mermory leaks

@jxsl13: the implementation of vector in STL is terrible, because it is decades old, and the standard locks one implementation

I never benched it myself but iirc vector can be 0 overhead, no?

even the smallvector of LLVM was benched to give better results on LARGE vectors than the std::vector

18:02

I like the ideas of smart pointers though :) but only where necessary

Eh, the standard sticking it's nose into implementation is not good

It's good for only one thing: performance predictability

for performance I usually go away from vectors and use either single linked lists or stacks or heaps, trees, stuff

I only tested it on tw level and compared to a c array with 64 players it was kinda worse by a factor of 4 ._.

@Assa as long as you use it from a recent library vectors can be fine

guess rust is the way to go ._.

just use a c++ lib

18:03

or make your own baselib

I'd rather shoot myself then link with boost...

I know :D but there are nice alternatives now

what do you use for signals?

if you wanna use an external lib for every little shit in c++, what's the worth of c++ then -> 0

Oh don't say that, C++ has a nice inheritence system

theoretically you could use QT for everything

RTTI is not half bad either

well, wow xD one of many features

18:05

RAII is nice

18:05

that's about it, then

C++ is pretty decent to use without it's STL

@jxsl13 c++ is fine, the implementation of the standard lib enforced by the standards is garbage

if you look on java, it's not better: you add an external lib to your pom for everything

production cycle is bad, as you'd need to implement everything from scratch yourself

you can write your own naive containers and they will have better performance

or search for libs

@Dune do you have some links or evidence for the "stl is garbage" statement btw?

that might not be supported

I kinda nuked the entirety of IGameController to make it into an actual interface

tw needs to be refactored from scratch anyway ._.

do they have better performance because they can't accept every combination of throwing move/copy/whatever constructors that the STL containers must support?

ohi @heinrich5991, mind taking a quick look at my last pr while you are around, promise it'll just be like 5 min tops

can't wait for teeworlds 2.0

link?

you be ded by then, @Assa

18:08

xD

www.imaginary-content.com

hm hm

@heinrich5991 https://github.com/ddnet/ddnet/pull/1939

Always try extracting map before fail. Fix #1886 by Learath2 · Pu...

I think we should also store the SHA256 in the demo, but I'm not sure how to upgrade the demo format. I also stored the SHA256 in the demo, but is this the right way to do it? I smell endia...

Am I allowed to do my own teeworlds 2.0 with Vulcan, beer and hookers?

that looked hard to review

18:09

but okay, I'll take a look

@heinrich5991 you already reviewed the thing, I just need an ok for the last commit :P

rip vulkan, 2k lines of initialization code

i want an easy to use graphics library

18:10

but i probably end with unity then

beer and hookers are approved

heinrich5991 looking for one but I'm afraid not, it was a live thing

18:12

cf. chandler carruth

18:12

every small implementation detail of STL containers was put in the standard, so they cannot move anymore

Dune: iirc std::vector was 0 overhead if you preallocated the memory, so it atleast won't perform worse then an array if you know the size beforehand :P

let's pray for c++23 to throw away the C compatibility

possible but then just use a static array if you know the size

18:13

EASTL is a good lightweight alternative iirc

D

If not for the C standard holding the C++ commitee down, they'd have turned the entire language into some meta language of templates

as far as I know, stuff like std::vector, std::unique_ptr, std::shared_ptr are fine

18:13

@Dune

+1 Learath2

18:14

std::vector is not the worst iirc

and maybe cut off the 40 year olsd stuff that's still being supported

The STL has absurd implementation standards for performance predictability that prevent better implementations

can you name concrete things that affect std::vector? I can't imagine any

@jxsl3 any particular C things that you don't want in your C++?

18:14

@heinrich5991 a bad reallocation strategy?

trying to find the LLVM benches that show their vector designed for small sizes performs better than vector even on huge arrays

true. I don't think it's specified by the standard, but let's check

what was it called again, the Binary Application Interface of C is fully supported and not above that, thus preventing features?

as far as implementation details go, I remember hashmaps has something that enforces that the pointer to some elements cannot change in some bizarre scenarios

yes

18:16

I agree that hashmaps are bad, becaue they enforce linked list buckets IIRC

the simple fact that implementations could not change for decades should indicate that this library is unsuited for performance

heated debate

but you're right, I'd like to have concrete examples of vectors

xD

std::vector doesn't need to change in decades, tbf

18:17

it's a glorified array, arrays haven't changed in 70 years

iirc the one container that is fine is the string

18:22

heinrich5991: did you find out if the reallocation strategy is specified by the standards?

is the 1000 of Smallvector a predefined allocation size?

it doesn't look like it

Dune: I took a look at the standard and didn't really see it specified, however it might be inferred from the wording that new_size is just enough to fit the new item

only that it's amortized O(1)

which would be a bad strategy

that wouldn't be amortized O(1) then

iirc actual algorithms aren't in the standard, but strange specific behaviours are, and lock into some possibilities

for hashmaps

*too high for me, leaves to play Anno 1800 ._., @Learath2 remove the line, just giving my 2 cents here.

@heinrich5991 where did you see it's amortized O(1)?

that's something I remembered, let me check

18:30

23.2.3 (sequence containers) 16

heated debate continues

Table 101 lists operations that are provided for some types of sequence containers but not others. An implementation shall provide these operations for all container types shown in the “container” column, and shall implement them so as to take amortized constant time.

18:30

a.push_back(t)

I see

https://lemire.me/blog/2012/06/20/do-not-waste-time-with-stl-vectors/

Daniel Lemire

Do not waste time with STL vectors

I spend a lot of time with the C++ Standard Template Library. It is available on diverse platforms, it is fast and it is (relatively) easy to learn. It has been perhaps too conservative at times: we only recently got a standard hash table data structure (with C++11). However,...

18:43

"stl vectors are fine"

fair enough

https://zeux.io/2019/01/17/is-c-fast/

Is C++ fast?

A library that I work on often these days, meshoptimizer, has changed over time to use fewer and fewer C++ library features, up until the current state where the code closely resembles C even though it uses some C++ features. There have been many reasons behind the changes - ...

18:55

compiler  std::vector  arrays
gcc            334 ms  318 ms
clang          327 ms  297 ms
clang libc++   328 ms  299 ms
msvc           285 ms  265 ms

18:58

Release performance also slightly increased across the board - this is because for many of our arrays, the default initialization performed by std::vector’s constructor is redundant as we’re going to fill the array anyway. With std::vector, you can either resize a large array and then compute the items (which requires default-initializing every item redundantly), or reserve and push_back repeatedly (which requires a bit more code for adding each item, and this overhead can also add up). With a custom container it’s easy to have an option to skip initialization - in fact, in our replacement that’s the only option since it’s easy to memset the array manually if necessary.

18:58

that's a reason for std::vector to be less performant than our own container type

Some time last year during a regular lunch time C++ discussion at work somebody said “there’s a good language subset of C++, C with classes”, to which I replied “there’s an even better subset, C with structs”.

huh :)

Somebody doesn't like OOP :P