Hi, I've got a couple quick questions. The biggest and most pressing is about saving arrays as a file. I simply don't understand it.
So right now I have this array of tiles, each tile contains two numbers. I'd like to save thoes numbers into a file. In such a way that I can assign thoes values back to an array of tiles again.
Hokay, so next is. I'm looking for an easy way to compare one ALLEGRO_KEYBOARD_STATE to another.
It would be great If I could just do something like:
That doesn't work, I ended up working around it and did this:
I can see that being really riddiculous to do if you where asking someone to print their character name or something. So I guess the question is still how can I compare the whole keyboard state?
Hi, I've got a couple quick questions. The biggest and most pressing is about saving arrays as a file. I simply don't understand it.
It's not so bad. Use al_fopen, al_fwrite32le or al_fwrite32be and to read, use al_fread32le or al_fread32be and close the file with al_fclose.
I can see that being really riddiculous to do if you where asking someone to print their character name or something. So I guess the question is still how can I compare the whole keyboard state?
update_keyboard_handler(); if (key_press(ALLEGRO_KEY_ESCAPE)) {quit = true;}
Using keystates can be a problem if it takes too long between updates, so a lot of people will probably recommend using keyboard events instead though. That makes it harder to detect double clicks and key held durations though.
Thanks again, Edgar! That looks like it covers pretty much everything.
And about the files. I think I've got a bit of a handle on it. I'm about half way there. I decided to just go with <fstream> as it looks simpler .
I decided to just go with <fstream> as it looks simpler
The fstream routines will work fine if you are reading/writing as text. However, if you are working with binary data, different architectures will represent the data in different ways, so your code will no longer be portable to other platforms.
The Allegro routines take care of this problem.
I decided to just go with <fstream> as it looks simpler
Word to the wise, if you use fstream, you will have to handle endianness on your own if you want your data to be portable to other computers besides your own. Using iostream's write function will write your data in the order it appears on the computer in use, and if you try to read it from a computer with different endianness, then you will get backwards data.
Stick with A5's file I/O and you'll be much better off. There are functions to read/write a char, read/write in little_endian/big_endian for shorts and ints. I wonder why there isn't a function for read/write'ing doubles though?
Okay, so I got it working... But it just seems like magic, I have no clue why this works.
To me this feels like:
step 1: poop in a box.
step 2: wait 3 seconds.
step 3: retrieve gold from box.
Could someone please explain this a little bit?
If you poop gold into a box, you will be able to later retrieve it. What part of that is hard to understand?
Could someone please explain this a little bit?
Here you go:
Maybe you're having trouble wrapping your head around the way the 2D array gets serialized into a 1D sequence of 32 bit integers?
Maybe you're having trouble wrapping your head around the way the 2D array gets serialized into a 1D sequence of 32 bit integers?
Yeah after what you wrote there It makes sense though. My interpretation now is, everything I write to the file is writtin as a chunk of data, and that gets placed after the chunk written before it. Which I think is good enough for a pass now Thanks for making it clear.
A file is just a bunch of bytes. When you store bytes in it, you can later retrieve them in the same order. al_fwrite32le is just a convenience function that takes a 32-bit integer, chops it into four bytes, and sends them to the file, one by one, starting with the most significant one. al_fread32le reads them back in, in the same order they were written, and combines them back into a 32 bit integer. That's all there is to it, really.