Sorry your browser is not supported!

I was looking over using memblocks to get a better understanding of them and I have a question. I'e seen that in order to store a string variable in a memblock you have to convert it to an integer variable for each character in the string. And then when you need to retrieve it you must access the numeric variable and then convert it back into a string. This seems to be a lot of work for storing a string so what would be the real benefit to using a memblock to store strings and not just create a .dat file to store the info for later gameplay?

There's no use in storing strings in memblocks, that was probably just a bad example for showing how memblocks work.

Memblocks are useful when manipulating vertexdata in meshes, pixels in images, etc. Stuff that requires raw access to memory.

If you're looking for a way to save/load game states then you should be using the file commands (open to write, write byte, write float, etc.)

I wrote a tutorial on memblocks a long time ago

There are some situations where one may end up using memblock strings to send customized data packets containing text fields over a network; but even that would be optional.

Memblocks can interact quite nicely with a number of the popular DBP plugins; and can even be saved or loaded from disk.

Unless your memblock is going to be parsed by something; or converted into something, or saved to disk; do not bother to use them.

Well.. since DBpro uses null terminated strings, It'd depend largely on how much string processing your application does. So even though this sounds counter intuitive, you could bypass a lot of the native string engines overhead by going down the memblock/string pointer route and rolling your own processing functions.

Most people are aware that null terminated strings perform poorly when string operations are cumulative (eg. A$=A$+B$ type stuff). This occurs, because underneath this seemingly insignificant operation, there's len() operation being performed every addition (and potentially allocations and copies also). This Len() operation runs through the strings looking for the zero characters. Not a huge cost on small strings, but can have significant impact the bigger they get. And surprising they don't have to be all that large at all to bring your program to a grinding halt.

Eg.



The same thing occurs in DBpro string functions, which have to screen the user input parameters, so you'll find similar types of slow downs when using MID$(), LEFT$(),RIGHT$(),Lower$(),Upper$(), String compares etc etc. Since they have to find the string length before doing anything with it. You can minimize the impact of this by splitting string processing tasks up into smaller strings (small strings ='s lower len() cost per operation)

If you had to say parse a TEXT / XML / HTML file or something then doing this in memblock would most likely give you better performance (assuming you can load the file to a block quickly). Alternative, if you can get a pointer to a string you can do the same thing really, but without the memblock container. Either way, it'd be quicker, just not as pleasant.

Interesting. Perhaps that is the concept behind Ian M's fast string
plugin functions .

So if I was to store a whole medieval armory as well as weapons of all kinds, would it be better to use a memblock to store those names or would it be better just to create a .dat file and read the ames upon loading he game?

Depends on how much data you are working with, how complex it is, and how you plan to manage it.

You might check out my post regarding data storage. It discusses several methods, and pro/con for each.

http://forum.thegamecreators.com/?m=forum_view&t=211983&b=8&msg=2534332#m2534332