Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bevy game development tutorials and in-depth resources

taintedcoders.com

Post reply on HN
Print view View original

91–100 of 121 posts

Re: Bevy game development tutorials and in-depth resources

#91

Post by fluffybucktsnek »

CyberDildonics wrote: post #88
fluffybucktsnek wrote: post #85

Earlier quoted context omitted.

It's a data structure, except it doesn't describe how data is actually stored, only how its elements interact, so it's a data structure that doesn't actually structure data. If you are the kind of person that considers stuff like MVVM and Clean Architecture to be data structures, then I suppose it would be consistent. Most people don't.

It does store data so it is a data structure. Every implementation is meant to store data and the whole point is to have more memory locality so how it stores data is actually crucial.

No, not every ECS implementation is about data storage (to be more precise, component storage). This architecture's abstraction being better suited for data locality is the main appeal, yes, but many appreciate the mere separation of the GameComponent's Components into Components and Systems. So your assertion about it being strictly meant for data storage is just wrong. As [2] states:

> Data is often stored in cache-friendly ways which benefits performance.

Notice it says often, not always.

And bear in mind, generally, data structures aren't just about storing data. They are about storing data in a very particular way.

Re: Bevy game development tutorials and in-depth resources

#92

Post by fluffybucktsnek »

CyberDildonics wrote: post #89
fluffybucktsnek wrote: post #84

Earlier quoted context omitted.

> No, it depends on excessive dependencies that themselves have dependencies. Not necessarily. Not every dependency will generate code. Furthermore, those dependencies of dependencies are rather small. If you're so certain that's the case, then provide an actual analysis over a case. Would be an interesting read. > And that 50MB was the stripped version. What is not sinking in? From the reddit post you linked: > paho…

Not every dependency will generate code. Who said that? Furthermore, those dependencies of dependencies are rather small. No, they add up to 50 MB.

> Who said that?

Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint.

Which brings to...

> No, they add up to 50MB.

You are just asserting this. The thread you linked doesn't really support this. So I'm asking for actual proof, like a disassembly, or analysis through other tooling.

Re: Bevy game development tutorials and in-depth resources

#93

Post by CyberDildonics »

fluffybucktsnek wrote: post #91
CyberDildonics wrote: post #88

Earlier quoted context omitted.

It does store data so it is a data structure. Every implementation is meant to store data and the whole point is to have more memory locality so how it stores data is actually crucial.

No, not every ECS implementation is about data storage (to be more precise, component storage). This architecture's abstraction being better suited for data locality is the main appeal, yes, but many appreciate the mere separation of the GameComponent's Components into Components and Systems. So your assertion about it being strictly meant for data storage is just wrong. As [2] states: > Data is often stored in cache…

(to be more precise, component storage)

That's data, so it stores data, meaning it is a data structure.

So your assertion about it being strictly meant for data storage is just wrong.

No, using a data structure doesn't mean it isn't one.

Notice it says often, not always.

This doesn't matter. You're way off the map in what causes 50MB binaries.

data structures aren't just about storing data. They are about storing data in a very particular way.

Same thing, you're pretty deep in the replies and still not making a point.

Re: Bevy game development tutorials and in-depth resources

#94

Post by CyberDildonics »

fluffybucktsnek wrote: post #92
CyberDildonics wrote: post #89

Earlier quoted context omitted.

Not every dependency will generate code. Who said that? Furthermore, those dependencies of dependencies are rather small. No, they add up to 50 MB.

> Who said that? Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint. Which brings to... > No, they add up to 50MB. You are just asserting this. The thread you linked doesn't really support this. So I'm asking for actual proof, like a disassembl…

Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint.

That makes zero sense. That's like saying your luggage can't be too heavy because it contains a feather. Think about this super hard.

So I'm asking for actual proof, like a disassembly, or analysis through other tooling.

You think you need disassembly to see file sizes?

Re: Bevy game development tutorials and in-depth resources

#95

Post by fluffybucktsnek »

CyberDildonics wrote: post #93
fluffybucktsnek wrote: post #91

Earlier quoted context omitted.

No, not every ECS implementation is about data storage (to be more precise, component storage). This architecture's abstraction being better suited for data locality is the main appeal, yes, but many appreciate the mere separation of the GameComponent's Components into Components and Systems. So your assertion about it being strictly meant for data storage is just wrong. As [2] states: > Data is often stored in cache…

(to be more precise, component storage) That's data, so it stores data, meaning it is a data structure. So your assertion about it being strictly meant for data storage is just wrong. No, using a data structure doesn't mean it isn't one. Notice it says often, not always. This doesn't matter. You're way off the map in what causes 50MB binaries. data structures aren't just about storing data. They are about storing dat…

> That's data, so it stores data, so it's data structure.

Technically, the component storage is, at best, a ADS. But that's grasping at straws given that you can just store components directly in a function's stack frame. Still, the component storage isn't "the ECS" in the same way that a service injector isn't "the Clean Architecture ", even though you'll always have them in some form in each.

> No, using data structure doesn't mean it isn't one.

Now, where did I say that?

> This doesn't matter.

For the discussion of whether ECS is a data structure, it is, given that you previously stated that ECS was meant for storing data, and "often" contradicts that.

> You're way off the map in what causes 50MB binaries.

I haven't asserted anything about it. You did, and you have yet to prove it.

> Same thing

Pretty much everything stores data in someway. Which brings us back to the "kernel is a data structure in your eyes?" question from earlier. I don't think it is me who isn't making much of a point.

Re: Bevy game development tutorials and in-depth resources

#96

Post by fluffybucktsnek »

CyberDildonics wrote: post #94
fluffybucktsnek wrote: post #92

Earlier quoted context omitted.

> Who said that? Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint. Which brings to... > No, they add up to 50MB. You are just asserting this. The thread you linked doesn't really support this. So I'm asking for actual proof, like a disassembl…

Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint. That makes zero sense. That's like saying your luggage can't be too heavy because it contains a feather. Think about this super hard. So I'm asking for actual proof, like a disassembly, or ana…

> That's like saying your luggage can't be too heavy because it contains a feather. Think about it super hard.

There's nothing to think here. This analogy is stupid at best, profoundly ignorant at worst. We both agree that the binary is 50MB (the weight), so the "luggage can't be too heavy" is already nonsense.

> You think you need disassembly to see file sizes?

I mean the cause for the 50MB, if that wasn't clear (somehow).

Re: Bevy game development tutorials and in-depth resources

#97

Post by CyberDildonics »

fluffybucktsnek wrote: post #96
CyberDildonics wrote: post #94

Earlier quoted context omitted.

Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint. That makes zero sense. That's like saying your luggage can't be too heavy because it contains a feather. Think about this super hard. So I'm asking for actual proof, like a disassembly, or ana…

> That's like saying your luggage can't be too heavy because it contains a feather. Think about it super hard. There's nothing to think here. This analogy is stupid at best, profoundly ignorant at worst. We both agree that the binary is 50MB (the weight), so the "luggage can't be too heavy" is already nonsense. > You think you need disassembly to see file sizes? I mean the cause for the 50MB, if that wasn't clear (so…

This analogy is stupid at best, profoundly ignorant at worst.

No it isn't. If you could explain why you would have already. Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make any sense. Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50 MB of stuff to do what they need.

Re: Bevy game development tutorials and in-depth resources

#98

Post by CyberDildonics »

fluffybucktsnek wrote: post #95
CyberDildonics wrote: post #93

Earlier quoted context omitted.

(to be more precise, component storage) That's data, so it stores data, meaning it is a data structure. So your assertion about it being strictly meant for data storage is just wrong. No, using a data structure doesn't mean it isn't one. Notice it says often, not always. This doesn't matter. You're way off the map in what causes 50MB binaries. data structures aren't just about storing data. They are about storing dat…

> That's data, so it stores data, so it's data structure. Technically, the component storage is, at best, a ADS. But that's grasping at straws given that you can just store components directly in a function's stack frame. Still, the component storage isn't "the ECS" in the same way that a service injector isn't "the Clean Architecture ", even though you'll always have them in some form in each. > No, using data struc…

No one knows or cares about whatever "ADS" is, injector services or 'clean architecture'. It seems like you're caught up in so much nonsense that you don't think that a class meant to store data is a data structure.

Re: Bevy game development tutorials and in-depth resources

#99

Post by fluffybucktsnek »

CyberDildonics wrote: post #98
fluffybucktsnek wrote: post #95

Earlier quoted context omitted.

> That's data, so it stores data, so it's data structure. Technically, the component storage is, at best, a ADS. But that's grasping at straws given that you can just store components directly in a function's stack frame. Still, the component storage isn't "the ECS" in the same way that a service injector isn't "the Clean Architecture ", even though you'll always have them in some form in each. > No, using data struc…

No one knows or cares about whatever "ADS" is, injector services or 'clean architecture'. It seems like you're caught up in so much nonsense that you don't think that a class meant to store data is a data structure.

ADS stands for Abstract Data Structure. ECS ain't even a class. Nothing you're saying now is making sense.

Edit: checking now ADS is a too literal of a translation (English isn't my first language). The more appropriate term is ADT.

Re: Bevy game development tutorials and in-depth resources

#100

Post by fluffybucktsnek »

CyberDildonics wrote: post #97
fluffybucktsnek wrote: post #96

Earlier quoted context omitted.

> That's like saying your luggage can't be too heavy because it contains a feather. Think about it super hard. There's nothing to think here. This analogy is stupid at best, profoundly ignorant at worst. We both agree that the binary is 50MB (the weight), so the "luggage can't be too heavy" is already nonsense. > You think you need disassembly to see file sizes? I mean the cause for the 50MB, if that wasn't clear (so…

This analogy is stupid at best, profoundly ignorant at worst. No it isn't. If you could explain why you would have already. Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make any sense. Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50 MB of stuff to do what they need.

> If you could explain why you have already.

I have my suspicions. But I rather speak with certainty rather than spout unfounded hypotheses as facts.

> Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make sense.

If I did say that. I said that isn't necessarily dependencies, because you have yet to prove it. If you do prove it, then that is that. As of now, all you've shown is that thread.

> Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50MB of stuff to do what they need.

Restating what I've said prior, you are just asserting this, but have yet to prove it. For starters, what are the specific bloated dependencies? How much space does each dependency actually occupy in the final binary? A disassembly would answer those really quickly.

Post reply on HN