Return to “Dev Logs”

Re: Sunday, April 23, 2017

#16
Josh, you have a beautiful entity system.

Just make thrusters a sub-class of entities, inherit the current system, add the extra code you need. Done.
By your own admission, they aren't exactly uncommon, so a unique class for them has no real penalty.

*OR* make a single 0.0-1.0 float for all entities, call it activationLevel or something, and for non-thrusters use it in any number of ways, possibly armor damage/dirtiness levels, or shield brightness on the part (higher after being hit more recently)
Thrusters just use that single float then for their thrust level.
(This way gives modders more options ;))



Doing it this way is far faster, and more elegant than trying to solve a general case for a thing that ISN'T a general case.

Actually thinking about it, do it as an inherited class, entityWithAnExtraFloat.
Then you can choose to have that float or not. :V
For entity, when calling that float's variable name just have it default to 0. Then you don't have to treat either any differently.

Code: Select all

<+BMRX> Silver Invokes Lewdly Verbose Experiences Readily With Absurd Rectal Expeditions
Image
Image

Re: Sunday, April 23, 2017

#17
The second option is something that I'm seriously considering. Having, say, 16 bytes (4 floats, 4 ints, 1 color, a direction and a magnitude, ..) of 'userdata' on the C side wouldn't be a bad idea nor would it add any significant cost.

The first option is more drastic and something I'd rather not do, unless I decide to do so in a 'big' way, in which case I would also make subclasses for turrets and a number of other entity types that would benefit from specific logic.

But again, first course of action is: nothing. Not until perf measurements show that we need to do something :thumbup:

Now that I think of it (well, you thought of it, I'm extending your thoughts), being able to choose how much 'userdata' to allocate with an entity would be a great way to store extra data on the C side while remaining very flexible. Nope, then pool allocation couldn't be used, and being able to use a pool allocator for entities (since they're all the same size / type) is a huge perf advantage. (See how many bloody considerations there are here!?) So sizeof(userdata) must be constant or it must be dynamically-allocated. The former is far more attractive.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Re: Sunday, April 23, 2017

#21
Flatfingers wrote:And I take it the values can't simply be pointers to any-size blocks of data that don't have to be part of the pool?

If not, then a selection of undefined floats and ints sounds fine to me, too.
There is no reason why that data couldnt be pointers now, so long as Josh has a way of telling that data that it is actually a pointer, and getting the pointer from C into the Scriptspace to be put back into C, as I presume most of this interaction will be script driven.


Sounds like we just solved a problem for Josh though. :ghost:

Code: Select all

<+BMRX> Silver Invokes Lewdly Verbose Experiences Readily With Absurd Rectal Expeditions
Image
Image

Re: Sunday, April 23, 2017

#22
Probably over my head but this stuff is interesting to me and I love reading these devlogs.

Instead of the C side reading from Lua data couldn't you have the Lua push information to the C side? For example the strength of a thruster is kept on Lua and never used by C engine. When the thruster changes strength in Lua, it updates the render queue with new shader parameters.

Re: Sunday, April 23, 2017

#23
jkcxn wrote:Probably over my head but this stuff is interesting to me and I love reading these devlogs.

Instead of the C side reading from Lua data couldn't you have the Lua push information to the C side? For example the strength of a thruster is kept on Lua and never used by C engine. When the thruster changes strength in Lua, it updates the render queue with new shader parameters.
Edited, because I so good at english.

How I understand the data transfer is there's a communal data set which LUA writes to and C reads from for the rendering. In essence, neither are telling each other anything, they just have a courier.

With updating the thruster everytime a change happens, you have a lot of calculations happening in the LUA side, which is what Josh is trying to avoid. Although, none of us know what kind of performance losses that would cause.

I'm also for ignoring the problem until you can guarantee there are performance concerns. But maybe add thrusters to a list of "optimizable" code for later optimizing. And adding 1000 ships driving around to the "to test" list.
An idea that is not dangerous is unworthy of being called an idea at all. - Oscar Wilde

We often refuse to accept an idea merely because the tone of voice in which it has been expressed is unsympathetic to us. - Friedrich Nietzsche

Online Now

Users browsing this forum: No registered users and 2 guests

cron