Sorry for the late reply, but I had to create a bunch of images for a idea that I want to post on the GMS forums, which is related to this post. Using gimp has a limitation that slows me down when I draw my pictures on it.
I read your post , but I am going to re-explain myself and what I am trying to do, as best as I can. This way you understand where my train of thought is going. I will use pictures to explain what I mean further. I hope other members, can understand this too.
Im currently planning and designing a complicated game, which is actually a collection of almost 40+ games for offline play. One of these games will be off-line and on-line ( depending on the design ). Because I want to have it online, I want to use .JSON file format offline before I can implement the online version, since using .JSON files saves me from having to reinvent or learn a new data format to use ( since I am going to be using Javascript for the online version ). One of the data types of files that I want to use .JSON files for, is for a extremly complicated mapping system that not just one game can use from my collection off-line.
The basic mapping system of mine, is based on organization is like a deck of playing cards is stacked. The basic unit that I am talking about is an array or a grid field of 64 x 64 , where there 4096 values that are binary. Well 4096 bytes ( 64 rows x 64 bytes ) is how long a text string holding the binary field would be to write my grid field in to a .JSON file. My plan for my game is to have an area of memory that uses organized binary array of 64 bits, which why I need to use int64 (). An int64 uses 8 bytes. 64 x 8 bytes uses 512 bytes ( there are 4096 positions in binary bits ). For the text stream format for .JSON its 4096 bytes, plus what ever extra data a .JSON file has to add on to it to make it a valid .JSON file.
So each grid field of 64 x 64 is going to represent two different types of values depending on its use and interpretation. The first interpretation using the location determine by the bit ( 1 to 64 ) or the individual bits of each of the 8 bytes representing 1,2,4,8,16,32,64, and 128, represents a location or a void.
So what I wanted to know, and I did not know , which I understand now through the replies. Please understand, GML is a hurdle for me compared to my experience with C. They are two different languages.
@GMWolf ( et al ) I really dont consider Boolean variables as anything special ( it's not a valid variable type ), because any type of variable can be boolean, its not hard to store a 1 or 0. But is it a waste of space, to use 8 bytes for a double or a int64 to serve as boolean? I think so. Is it a waste of space to use text strings to store binary bit fields, but if thats what I have to do to use .JSON file formats, then thats what I have to do. I will have to pass the cost of storage to the end user for this. Because heres where the cost of storage binary data as text data comes in ( as I further explain ).
I thought that I had to convert a double ( initialized to 0 , e.g. var mybitfield, myint64; mybitfield = 0; myint64 = int64(mybitfield); ) then I do bit fiddling , this for one row only. So really using an array of 64 mybitfields ( var mybitfield[64], myint64[64] ). Next, I got to get rid of the garbage in variables that I instantiate ( for (x=0;x<64;x++) { mybitfield[x] = 0; myint64[x] = 0; } . Now I need to create the binary version of the double floating type ( myint64[x] = int64(mybitifield[x]); then I do bit fiddling with 4096 bits or 64-bit fields by 64 rows.
@FrostyCat, your last reply makes more sense to me now - again this is a new langauge to me. And what I'm used to thinking from C programming does not work all the time in GML. So thats why I posted the message. Thanks.
There is a second part to this , but I will reveal it in the next post of mine as a new topic