Memory cost of different attribute types?

Ignis

Do any of you super-technical GS users have an idea how much memory/storage the different types of game attributes demand? As far as I know, "boolean" is the least-taxing, then "integer" is probably the 2nd-lowest, and perhaps "index" is at the highest end.

I mainly ask because, as I mentioned in a previous post, I want to learn as many game optimizing tactics early in the going, so when I naturally complicate my games and add more features, I can take performance issues into account and design accordingly.

quantumsheep

I have no idea, but would be interested in the answer to this myself

mrfunkleberry

i really don't think that different attribute types would have any real performance difference. I could be wrong, but as long as you're using the right type for the data you're storing, thats as much as you can do.

Having said that, i don't use booleans, i don't trust em. (they break with spelling errors)

design219

mrfunkleberry said:
i don't use booleans, i don't trust em. (they break with spelling errors)

Haha, I almost sprayed my coffee. No offense intended, but you can't spell "true" and "false"?

quantumsheep

There's always the chance of a mis-type, and then it's a hell of a job trying to find where the error might be!

While I find it hard to trust *any* variables, Booleans, once rehabilitated, are alright in my book.

Just keep 'em away from me...

QS

mrfunkleberry

design219 said:
Haha, I almost sprayed my coffee. No offense intended, but you can't spell "true" and "false"?

No offense taken, you need help learning to drink from grown up cups?

quantumsheep

Now now, kids, play nice

Photics

But that's why I use Booleans, so I don't have to type... I just select from the menu. It doesn't always work that way, as the drop-down menu isn't present in expressions, but I think it's cool when using rules.

mrfunkleberry

Its exactly the inconsistency of setting the values that makes them hard to debug. if you we're always presented with a drop-down then it would be much better. It's not a big issue, but when you spent an hour chasing a 'trye', a 1/0 integer seems like a better option. It's just a personal preference.

Photics

Well, in general, I usually use "real" as it doesn't seem easy to change attributes later.

I don't know what the performance hit is though. It seems like it would be next to nothing, no?

ORBZ

Bool: 8bits (7 of which are wasted, this is normal since 8 is the smallest addressable range by the CPU)

integer:32bits

float:32 or 64bits

index:32bits but half wasted since an index is just an integer that can't go negative.

text:8bits per character

8 bits in a byte. 1024 bytes in a kilobyte. 1024*1024 bytes in a megabyte.

your memory is mostly used by gfx and sound and logic. Not attribs.

mrfunkleberry

ooo nice one orbz

design219

Thanks ORBZ, excellent info.

mrfunkleberry... apologies, there was no need for my comment... I like your reply :-)

mrfunkleberry

@design219 Awww shucks, forget about it. I'd have posted a very similar response 9 times out of ten. I like a bit of friendly ribbing.

rebump

From a performance and storage standpoint, integer number usage is generally quicker and more memory conscience than real/floating point number usage. However, with today's CPUs with floating point support as well as the off-loading of graphics processing (which are floating point heavy for translations and such) on dedicated chips, it really is not that much of a concern. Same with the memory usage not being too big a concern nowadays unless you are trying to eak extra storage in a large database and/or performance out of a very busy multi-user system (such as a web server or set of web servers).

Back in the early days of game/graphics programming, you tried to use integers when and where possible. For translations and such, it was quite common to waste memory storing pre-computed floating-point based equation results in a lookup table (e.g. value of sine and cosine across the degrees of a circle) to avoid the cost of processing those floating-point based equations on-the-fly during game/demo runtime. It may have wasted valuable memory (so little back in the day) but it vastly improved performance.