Sunday, April 23, 2017

Logging the Creation of a Beast -- the Good, the Bad, and the Template Metaprogramming.

Re: Sunday, April 23, 2017

Postby Silverware » Wed Apr 26, 2017 12:45 pm

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.
Image
Image
User avatar
Silverware
Vice Admiral
 
Posts: 2959
Joined: Sun Sep 07, 2014 3:23 pm
Location: Goattown-Three, Sigma Six, Goat Space

Re: Sunday, April 23, 2017

Postby JoshParnell » Wed Apr 26, 2017 1:16 pm

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
User avatar
JoshParnell
Developer
 
Posts: 4260
Joined: Sun Oct 07, 2012 3:06 pm
Location: Baton Rouge, LA

Re: Sunday, April 23, 2017

Postby Silverware » Wed Apr 26, 2017 1:39 pm

Maybe userdata is a set number of bytes, like 16/32.
But whats IN that userdata is userdefined.
Image
Image
User avatar
Silverware
Vice Admiral
 
Posts: 2959
Joined: Sun Sep 07, 2014 3:23 pm
Location: Goattown-Three, Sigma Six, Goat Space

Re: Sunday, April 23, 2017

Postby JoshParnell » Wed Apr 26, 2017 3:43 pm

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.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
User avatar
JoshParnell
Developer
 
Posts: 4260
Joined: Sun Oct 07, 2012 3:06 pm
Location: Baton Rouge, LA

Re: Sunday, April 23, 2017

Postby Flatfingers » Wed Apr 26, 2017 4:33 pm

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.
User avatar
Flatfingers
Vice Admiral
 
Posts: 4536
Joined: Sat Nov 24, 2012 12:45 am

Re: Sunday, April 23, 2017

Postby Silverware » Wed Apr 26, 2017 5:44 pm

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:
Image
Image
User avatar
Silverware
Vice Admiral
 
Posts: 2959
Joined: Sun Sep 07, 2014 3:23 pm
Location: Goattown-Three, Sigma Six, Goat Space

Re: Sunday, April 23, 2017

Postby jkcxn » Thu Apr 27, 2017 12:12 am

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.
jkcxn
Recruit
 
Posts: 1
Joined: Thu Apr 27, 2017 12:04 am

Re: Sunday, April 23, 2017

Postby Kekasi » Thu Apr 27, 2017 9:07 am

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
Kekasi
Lieutenant
 
Posts: 52
Joined: Fri Jan 31, 2014 9:55 am

Re: Sunday, April 23, 2017

Postby Spoon » Thu May 04, 2017 6:12 pm

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:
User avatar
Spoon
Recruit
 
Posts: 2
Joined: Thu May 04, 2017 6:09 pm

Re: Sunday, April 23, 2017

Postby Talvieno » Thu May 04, 2017 7:26 pm

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.
Image
Have a question? Send me a PM!
User avatar
Talvieno
Community Manager
 
Posts: 8187
Joined: Fri Apr 11, 2014 6:50 pm
Location: North GA, USA

Re: Sunday, April 23, 2017

Postby RedDwarfMining » Fri May 05, 2017 6:45 am

Is Josh showing LT at LSU today? Any links to what this event is? ?
User avatar
RedDwarfMining
Lieutenant
 
Posts: 88
Joined: Tue Nov 18, 2014 1:26 pm

Re: Sunday, April 23, 2017

Postby Talvieno » Fri May 05, 2017 7:06 am

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.
Image
Have a question? Send me a PM!
User avatar
Talvieno
Community Manager
 
Posts: 8187
Joined: Fri Apr 11, 2014 6:50 pm
Location: North GA, USA

Re: Sunday, April 23, 2017

Postby Dinosawer » Fri May 05, 2017 7:08 am

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.
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
User avatar
Dinosawer
Admiral
 
Posts: 5818
Joined: Fri May 09, 2014 1:08 pm
Location: Belgium

Re: Sunday, April 23, 2017

Postby N810 » Fri May 05, 2017 8:46 am

I guess Josh is still neck deep in the physics engine/collision detection. :eh:
"A sufficiently advanced technology is indistinguishable from magic."
- Arthur C. Clarke
User avatar
N810
Captain
 
Posts: 690
Joined: Mon Nov 26, 2012 3:20 pm

Re: Sunday, April 23, 2017

Postby Talvieno » Fri May 05, 2017 9:07 am

From what he's said, he should have a new devlog ready today or tomorrow. :)
Image
Have a question? Send me a PM!
User avatar
Talvieno
Community Manager
 
Posts: 8187
Joined: Fri Apr 11, 2014 6:50 pm
Location: North GA, USA

PreviousNext

Return to Dev Logs



Who is online

Users browsing this forum: JoshParnell and 10 guests