I believe that the built-in memory operations can only handle DWORD adresses, so they are a bit limiting.
Thus, you should be able to store dwords and integers, storing individual bytes, strings etc. is of course also possible however it would require some after processing to break out the relevant parts of the returned dwords. A natural consequence of this is that for storing datatypes of < 4 bytes in size, you have to either squash them together and de-scramble yourself, or just use dwords to store their values (which will take up inecessary memory).
About retrieving signed variables, I would guess that is determined by the datatype you are storing the result to. -1 would become -1 if retrieved to an integer (signed), but (likely) 2147483649 if retrieved to a dword.
Quote: "If I have an integer(4bytes) will it be the same 4 bytes in the memblock / memory?"
Yes.
The first downside to memblocks to consider is that you can only have a limited amount (I believe it is 127 or 255).
Second, it is likely that raw memory access is a bit faster, but that depends on the implementations of the memblock and memory functions I suppose.
I'd really advice to use IanM's memory access command set from his M1U package, as it supports a lot more than the built in 4-bytes only system. It is very fasy as well (not that I have clocked any comparison tests, but it runs fast enough for me, so to say
)
I find myself for example needing sets of bitmap font memory, where each character can be stored to raw memory. Since each character has the same dimensions, we can strip off the header of the memory image object. Also, when having a few fonts with ~80 characters each loaded, you would experience the afforementioned memblock limit. Whenever you need to drain the image data out to paste it onto a memblock for making an image from,
copy memory works wonders. The same principle goes with all other memblock-supported media.
Quote: "As I have the array thing already working, I just thought if it's worth changing the whole thing to use a raw memory/memblocks?"
There might be a slight speed improvement, but I doubt it is of any relevant impact. As long as you only store relevant information in your array, I'd say keep it as large as it needs to be. If there are blank fields etc. in places you might want to consider a memory solution where you basically have elements telling the sort of data as a word or something, then features a pointer to the relevant data. In that case you can store only as much data for each entity as it needs and strip out the rest.
That would only make sense to be bothered with if you could save a considerable deal of memory that way though, I'd say.
