Byte datatype
Monkey Forums/Monkey Programming/Byte datatype
| ||
| Hi, I was wondering if it was possible for Monkey to have a 8-bit integer (usually known as Byte) datatype. Used in the correct places Bytes may greatly reduce the memory footprint of our games broadening the range of devices our games could run on. By example, I usually work with maps which are stored as a matrix of tile indexes (inside a tileset). My tilesets are restricted to contain no more than 255 tiles (reserving 1 index for "no tile"). While I can of course use Ints (and I'm currently using them) the memory usage gets large with ease. Maps have 4 layers (which is a reasonable number of layers to store information for most type of 2D games). For a 256x256 map, the number of cells stored is 256*256*4 = 262144 (counting all layers). Using bytes for each cell, that is exactly 256KB. The Monkey Docs state that Ints are "at least 32 bits", so if we use Ints to store the cell information we have 4 bytes per cell. What could have been 256KB (storing cells as Bytes) becomes *at least* 1MB in size. Of course, there are other cases when bytes are more than enough for a task. In fact, in some cases it may become desirable to use them. Please bear in mind that not all Android phones are high-end devices with plenty of RAM. So, anyone else thinks this would be a great addition to Monkey? |
| ||
| do all the target languages support bytes? |
| ||
| While I thing having a Byte datatype could be great, in the scenario you're describing,a 65536 length string of 8 bits chars could contain your "bytes" array, and you can check string[index] to get the numeric value (byte) of the given "char" position. Unless Mark has added unicode support to strings in Monkey, this should bring a nice mem reduction at (I think) zero performance cost. You could even read the whole map in a single pass. |
| ||
| Java has byte, C++ has unsigned char. Javascript doesn't have different types of "Number" so I assume bytes there should be handled in a similar way as Integers. |
| ||
| I suppose you could handle bytes as Ints in javascript 'behind the scenes' and switch to byte if the target language has them. |
| ||
| About using strings, already tried for other part of the code, but it looked like Strings in Monkey have some sort of encoding support at least in some platforms like iOS where they are mapped to NSString. On iPhone when I tried reading string[n] I got nothing like what it was supposed to be there, although the same did work on the other platforms (but I can't assure they were single-byte readings at all.. or stored as a single byte per character). |
| ||
| Maybe Monkey has partial unicode support then. Anyway, you could pack your bytes in integers, each 4 bytes into an integer variable, but I supose you've already done this. |
| ||
| That's not a good solution at all since Integers seems to be of different size depending on the platform. Also, additional bitwise operations (like masking and shifting) are required to then read the values. I'm using Ints for each cell currently, but as I said, it's using more memory than it should. EDIT: I really tried a few options but found no simple solution that provides a good implementation. It's not a big deal anyway. The game will use more memory and that's about it. The problem here is not what I wanted the Bytes for, but the advantages/disadvantages of having them implemented on Monkey. |
| ||
| Java has byte, C++ has unsigned char... Unfortunately, Java does not have an unsigned keyword - all numeric types are inherently signed. This is why when you read a byte from an InputStream, you actually get an int (since the byte type can't represent values 128-255). Trying to do any kind of fancy conversion in the translated code would become a nightmare to maintain and would probably end up being a performance hit if you're trying to use signed bytes across your entire app. |
| ||
| Right, forgot about java types being signed. A bit of casting (to int) may be needed when evaluating expressions and that may become messy. I guess I'll try to optimize the map representation, but that's another story... |
   |