@Mahoney -
Quote: "I simply meant you have to realize it will not be linear. I didn't mean that you shouldn't allocate memory."
Understood - I agree - and I knew what you meant
DX and other lib's we link to when executed from within our application - plus other applications in general - all share the heap typically. Some systems allow per process "heap reserves" which would be contiguous at start... but generally speaking - Memory fragmentation just doesn't have the negative imapct it used to however I still believe taking it into account while writing your software is not a waste of time if you are making an application that is conceptually going to run for hours on end and has alot of memory allocation and releasing - as is with a complex game - classes - dx etc all going on.
@Charles Thompson -
Quote: "I could take the the time to go into details"
that's what I was doing is all...
Quote: "but just allow me to say that I didn't mean it completely avoids it. Replace avoid with reduce."
Ok. BTW - My message wasn't meant to destroy your statement as it was to steer the reader(s) mainly Shadow Wolf who is fairly new still - toward a more accurate understanding of all this menutae because seemingly little details can impact how someone designs their code/systems/games/apps etc.. and I try to be diligent about making people who are learning this stuff get steered in the right direction - if nothing more then to send them on their merry way googling the answers for themselves.
Quote: "While you're code certainly does have the potential of eventually being faster I just find it an awkward solution."
I can appreciate that. I consider it a "resources on demand" kind of solution with regards to processing the same "stuff" more than once being redundant. Now in a game - squeezing performance is a contant concern. Now, in a business application - this solution would be considered absurd for MOST things. I can see a use for this sort of logic though in some scenarios - but definately not the norm.
Quote: "You might be right about him not being ready for it though."
LOL - Won't know how he's making out either until he responds. No harm there being new to this - I admire the fact that so many people are diving in and getting their teeth cut. It's not easy - its DEFINATELY work... and it takes ALOT of TIME! So HAng in there people! (I struggle too)
Quote: "On a side note, you took my comment a lot more seriously than I did."
Not intentionally to be a pain in the rump - more to not let that comment be thought of as gospel by others - I personally wasn't effected in any way - either way - but I didn't want people thinking a "class" (in it of itself) prevents memory fragmentation - nor an alternative for problem that screams ARRAY loudly no mater how you pull it off - and Array is the only way that works - and Array of classes I think is very adequate - or at least an array of "struct" managed by some code to keep things organized.
Quote: "As for a class deleting itself well it can't delete the class but it can delete an instance of a class thus freeing up some memory."
Agreed.
Quote: "the only way to avoid memory fragmentation is to break out some machine code and start assigning items in continuous blocks then after you get done do a little tap dance around it"
Or allocate on demand and KEEP allocated for the duration - OR - Allocate a contigous chunk of ram - and manage it yourself like you said. This falls into the realms of writing your own memory manager though so you can get your class instantiations to use the
"available memory" you're controlliing versus getting it from the general heap.
Quote: "One last thought by what classes were designed for I was referring to initiating multiple bullet objects. They're designed to handle things that are similar but act a bit differently. I.E. All the bullets are same but where they're heading is a bit different"
I'll buy that with this summary: Class - One set of Code for an object type - used by multiple instances of that object type. Yuppers.
Quote: "One last side note: You put a lot more time into it than I did."
No Question LOL
Quote: "Sorry to the OP if I caused any confusion. "
Don't be - this sparked a good read for those who happen to be googling about such things.
Quote: "Next time I'll try to take a bit more care so Jason won't write up a twelve page retort destroying one sentence."
NOOOO - Don't do that! This was great! Are you kidding - the fact that you tossed out another approach and we discussed it - our thoughts - reasons - that's COOL to me... Please DO post your opinions - EVERYONE SHOULD! If I don't reply and share my thoughts - how can I ever be taught anything! I mean - what if I thought XYZ and you knew better and showed me the light? I'd be greatful.
In this case - I didn't really shed light for you - but I BET we BOTH did to other forum visitors! Its all good. Besides - 12 page posts don't kill trees
Chainsaws do LOL
@Sydbod - Thank you for those numbers and your thoughts - I found them very informative seriously - thats a lot of bullets.
One trick I think sone games do is they make the sounds of 20 bullets while actually only shooting a few - maybe even visually having one bullet look like 3,6 etc.. so cut down on those numbers. Me personally, I like the "simulate each bullet" approach even if its more resources. Allows better gameplay in my opinion.
--Jason