Could someone explain:

[Lemmy]

quote:

---

Originally posted by KiloOhm:

But we're not talking about combinations, we're talking about straight storage, right? Or did I miss the point entirely?

---

in that i case i did mean combinations..
ok, i was a little vague when i posted this

quote:

---

...but suppose you use a 16 bit number for the systems instead of an 8 bit number...

---

what i meant was :
suppose you use a 16 bit number to define the number of systems instead of an 8 bit number...
you would then get 65536 systems max.


/ offtopic

quote:

---

Posted by geoschmo:
If we assume that Lenny's first number

---

Lenny ??

[This message has been edited by LemmyM (edited 08 May 2001).]

[This message has been edited by LemmyM (edited 08 May 2001).]

[zen.]

*zen reels from mathematical gymnastics*

I, um, like klausD's quadrant-jumping idea.

I wonder how hard it would be to code something like that?

zen

[geoschmo]

Sorry Lemmy. Too many hours stuck in front of the screen playing Space Empires.

They say the eyes are the second thing to go, but I can't remember what the first was...

[KiloOhm]

Oh, I think it just clicked, you guys were talking about 16bits worth of systems (i.e. 8 bit = 256 systems and 16 bits = 65,000 systems which then makes sense to me on the exponential growth.

Thanks, I guess I just needed to read what you guys were saying but put in a differen't way.

I thought you meant keeping 256 systems constant, double the data word lengths used to keep track of all the variables in the system, which would only double the storage needed. Now I get it

quote:

---

Originally posted by geoschmo:
Kilo,

If we assume that Lenny's first number (280Kb)is correct then the second number (70Mb) is also correct.

I'll admit it blew me away at first, but think of it like this. If 280Kb is correct for a galaxy with 255 systems, then simple division gives us a little more than 1Kb per system on average. If we then go to an 18-bit number that allows 65,000 systems then simple multiplication of a 1Kb per system times 65k systems gives us 65Mb of memory.

What I would like to know is, in my ignorance of computer programming, are if an 8-bit number is too small, is 16-bit our next option? Is not there some number in between we could use? If not I am sure he could use a 16-bit number, and then hard code some logical limit to the number of systems, say 1000 or somethhing like that that would keep the mem usage to a reasonable level.

Geo

---

[capnq]

quote:

---

What I would like to know is, in my ignorance of computer programming, are if an 8-bit number is too small, is 16-bit our next option? Is not there some number in between we could use? If not I am sure he could use a 16-bit number, and then hard code some logical limit to the number of systems, say 1000 or somethhing like that that would keep the mem usage to a reasonable level.

---

Since computers "think" in binary arithmetic, at the bit level everything is done in powers of 2. That's why a "kilobyte" is 1024 bytes rather than 1000, and a "megabyte" is 1048576 bytes (1024^2) rather than 1000000. I suppose in theory you could design hardware that used some intermediate value, but I don't know of any real-world examples where it's been done.

------------------
Cap'n Q

[DirectorTsaarx]

The reason we're stuck with either 8-bit or 16-bit numbers is that computers typically use either 1 byte or 2 byte registers to store numbers. 1 byte=8 bits, so 2 bytes=16 bits.

And, of course, those registers are independent of the actual programming language, since the higher-level programming language instructions are compiled into a set of machine instructions, which are based on the registers (and a few other things, but that's a different topic entirely).

As for why 1 byte = 8 bits, that's a matter for history buffs (hey, I'm only 31 years old, how should I remember the glory days of computing ).

[klausD]

Zenbudo:
thanks for your kind words.
I cannot answer if it is very complicated to program multiple sector game areas. But I assume such a system is simpler and more flexible than a "monster" universe with thousands of systems located in one gigantic sector.

Especially because the entire data of the different sectors have not to be in RAM the whole time, (because only one sector is active in RAM at the same time) it could be a resource saving method. On the other hand the universe could be nearly infinite. (depending rather on HD-space than RAM)

bye
Klaus

[Taqwus]

Another reason for octets --

Load/store instructions are often constrained to 1) operate only on data words or double words, and 2) operate only at *word boundaries* -- e.g. for 32-bit words, only at addresses divisible by 4 (bytes). I'm not familiar with x86 machine language, so I can't be sure.

Ditto for arithmetic. ALUs are designed for a given number of bits in their input -- e.g. handling 32-bit numbers, and outputting 32 bits plus various flags that can be set.

So while one *could* use, say, 14-bit foo, there'll need to be instructions converting back and forth between 14-bit and, say, 32-bit, if you want to do arithmetic. Those 14 bits may need to be shifted and zero-padded to fit into a 32-bit word for arithmetic, memory usage... and depending on language support, the programmer may need to explicitly specify the shifts and other bit operations. It's much more convenient normally to rely on "standard" data types.

(Standard in quotes. C, for instance, specifies only minimum ranges and the ordering -- shorts must be at least 16 bits, and no longer than ints, but other than that could pretty be whatever. Endianness is also not specified. Java is more standardized IIRC -- fixed bit lengths, and network-byte order.)

------------------
-- The thing that goes bump in the night

[raynor]

Q: If eight bits are a byte, what do you call four bits?

A: A nibble

[mottlee]

What is this???? Greek 101?



------------------
mottlee@gte.net
"Kill em all let God sort em out"