Page 2 of 3

Re: Sunday, April 23, 2017

Posted: Wed Apr 26, 2017 12:45 pm
by Silverware
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.

Re: Sunday, April 23, 2017

Posted: Wed Apr 26, 2017 1:16 pm
by JoshParnell
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.

Re: Sunday, April 23, 2017

Posted: Wed Apr 26, 2017 1:39 pm
by Silverware
Maybe userdata is a set number of bytes, like 16/32.
But whats IN that userdata is userdefined.

Re: Sunday, April 23, 2017

Posted: Wed Apr 26, 2017 3:43 pm
by JoshParnell
Yeah, that's what I was saying above (listing some possible ways that 16 bytes could be used). I think it's a good compromise.

Re: Sunday, April 23, 2017

Posted: Wed Apr 26, 2017 4:33 pm
by Flatfingers
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.

Re: Sunday, April 23, 2017

Posted: Wed Apr 26, 2017 5:44 pm
by Silverware
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:

Re: Sunday, April 23, 2017

Posted: Thu Apr 27, 2017 12:12 am
by jkcxn
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

Posted: Thu Apr 27, 2017 9:07 am
by Kekasi
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.

Re: Sunday, April 23, 2017

Posted: Thu May 04, 2017 6:12 pm
by Spoon
Holy crap... I'm just glad you're not dead. O.O


The youtube videos stopped and I didn't know these forums existed so I thought the worst. Cheers to LT and your safety! :clap:

Re: Sunday, April 23, 2017

Posted: Thu May 04, 2017 7:26 pm
by Talvieno
Lol, welcome! Josh is indeed alive and fine. Hopefully, now that you've found us, you'll stick around for a while. :) We're a friendly bunch.

Re: Sunday, April 23, 2017

Posted: Fri May 05, 2017 6:45 am
by RedDwarfMining
Is Josh showing LT at LSU today? Any links to what this event is? ?

Re: Sunday, April 23, 2017

Posted: Fri May 05, 2017 7:06 am
by Talvieno
Is he? I know he was recently, and it turned out to be a lot smaller an event than he'd anticipated. I didn't know about today, though.

Re: Sunday, April 23, 2017

Posted: Fri May 05, 2017 7:08 am
by Dinosawer
JoshParnell wrote: In the coming week I have another LT showing at LSU on Friday
^presumably that, but since he posted it on sunday that was friday a week ago, not today.

Re: Sunday, April 23, 2017

Posted: Fri May 05, 2017 8:46 am
by N810
I guess Josh is still neck deep in the physics engine/collision detection. :eh:

Re: Sunday, April 23, 2017

Posted: Fri May 05, 2017 9:07 am
by Talvieno
From what he's said, he should have a new devlog ready today or tomorrow. :)