bonkmaykr (@bonkmaykr@canithesis.org)

0 ★ 1 ↺

bonkmaykr » 2025-01-20
@bonkmaykr@canithesis.org

Hm, well, you guys were right. I was deriving the base classes wrong, using the public modifier fixed the compiler errors.

But the function calls going outside of their allowed memory is still happening.

What's weird is that it works totally fine on another objects, even with classes that are set up the same, but not on bullets.

CLion debugger (frontend for gdb) can see the object but only displays it's base o_worldObjectGeneric whereas it normally shows the entire hierarchy of inheritance. GDB CLI is so confused it literally crashes itself.

It might be an issue with the way I keep things inside vectors or add objects to the world mid-tick? I don't get why this is happening, I showed it to someone else and they couldn't fix it either. If I can't figure it out I might need to ditch inheritance somewhat and base all projectiles directly on a single class. It will make things harder to structure but I don't have a lot of other choices.

...

Coyote » 2025-01-20 / 2025-01-20
@Coyote@social.singing.dog

@bonkmaykr

It might be an issue with the way I keep things inside vectors

How are you keeping them? If you're keeping them directly inside the vector then you're probably slicing all your objects. Inheritance based polymorphism only works if you're taking pointers or references to the derived objects or with derived objects that have the same size as their ancestor (i.e. no non-static member variables).

...

0 ★ 0 ↺

bonkmaykr » 2025-01-20 / 2025-01-20
@bonkmaykr@canithesis.org

@Coyote@social.singing.dog I'm using pointers, the vector is type "vector

" and all objects are created with the new keyword, something like;

simulation->w_content.push_back(new o_bulletGeneric());

...

Coyote » 2025-01-20
@Coyote@social.singing.dog

@bonkmaykr What is the vector's template parameter? If it's std::vector<o_worldObjectGeneric> it'll still allow you to push derived objects, but it'll copy construct an o_worldObjectGeneric instead of pushing the entire derived object on the vector. Look at this; notice how despite calling push_back with four different objects, only "A copy construct" will be printed between "Before push_back" and "After push_back."

...

1 ★ 0 ↺

bonkmaykr » 2025-01-20
@bonkmaykr@canithesis.org

Sorry, I tried to specify it but it got blocked by the filters since it has the > brackets.

The vector stores o_worldObjectGeneric*, with the asterisk. So there should be no slicing.

...

Coyote » 2025-01-20
@Coyote@social.singing.dog

@bonkmaykr My next hunch would be if you're doing any kind of multithreading or maybe accidentally using static_cast instead of dynamic_cast.

...

1 ★ 0 ↺

bonkmaykr » 2025-01-21 / 2025-01-21
@bonkmaykr@canithesis.org

I haven't used either of those but I should look them up to see what the difference is

I managed to figure it out, IDK the low-level specifics but basically since updating world objects happens in the middle of a for() that reads the vector, it would see the new object get added to the end of the vector and try to call it's updateMe() while the vector was getting shifted around. Adding a lag of one game tick before each new object spawns by giving them a queue to wait in helped work around the issue. So I just do this before each tick:

for (globals::objects::o_worldObjectGeneric* o : w_contentQueue) w_content.push_back(o); w_contentQueue.clear();

...

Coyote » 2025-01-21
@Coyote@social.singing.dog

@bonkmaykr You should generally avoid adding to a vector while iterating over it, especially if you're using the for(auto x : y) syntax. What can happen is that when you try to push onto the vector and there's no more space, the vector allocates a new buffer and moves all the objects into it. This doesn't change the for loop iterators, so your for loop continues to loop over the destructed and freed objects.