Sorry guys. It seems as if I fibbed to you all. :(
I didn't manage to get a video up in time for Halloween -- my apologies. My ISP simply didn't make it to my home in time to make the swap over to fiber for me, and I've been sitting here waiting on them to move me on up so I can upload and download without having to wait all day for things to finish...
Well, they've finally got me on the schedule, and should be here today to come inside and finish up things. The line from the junction to my house has already been laid. They've made all the changes to the box outside my house which was necessary, and have dug and laid the cable from the box to my house. All that's left is for them to basically come in today and swap out the old modem which worked with DSL for the new one for the fiber, and then I should be good to go!
And what's this mean for all of you??
I'll be a fibber who can once again upload videos of decent quality and stuff to the interwebs for everyone!!
And yes, it seems I'll even fibbed about what the next video will be about. I promised it was going to be about "Beyond the 1st Dimension", and to go into multidimensional arrays with mem, but...
it's not. :(
As I was working on the blueprint which I wanted to follow for the next mem tutorial, I realized that there's an important bit of information which I really should share and stress first for everyone BEFORE I get into the formulas for calculating offsets for multidimensional arrays and such with mem...
... and that's REDIM _PRESERVE and why the heck it's so frustrating to work with! ARRRGGHHH!!
I've heard a ton of folks complain about how it doesn't really preserve our data (it does), and how it's useless (not quite, but sometimes it can be), and since its behavior is all memory related, I thought I'd go ahead and talk about it for the next video and then the one after that will be about how to do the math to calculate multidimensional array offsets with mem.
My question for all you guys to ponder on, while I wait on the ISP folks to show up today and swap out my internets, is this one:
How do you think an array is stored in memory?Take an array and let it be: DIM A(x, y)
Now obviously, it's just going to be a chunk of continuous memory and not some elaborate grid of data. (If we could use grids of data, that'd be cool, but how would we layout something like DIM A(x, y, z, p, d, q)?? Do we have 6-dimensional memory chips to hold that information???)
Since we don't have multi-dimensional RAM, it's just going to be stored in a simple continuous list in memory.
A(0,0) = whatever
A(0,1) = whatever
A(0,2) = whatever
But HOW is it stored??? Remember my lesson on
Little Endians and Big Chiefs? We could store that data left to right, or right to left, or top to bottom, or bottom to top.... As long as the computer maps to the same spot each and every time, we can store it in whatever dang direction we want!
So the question is, how do we actually store it??
And that's what the video I'll be sharing later today (or next week, as reliable as my ISP isn't) will cover for everyone!
The actual code which I'll explain and use to illustrate this lesson is already written, and I'll go ahead and share it so you guys can look it over early if you want. By itself, it's not going to help explain everything the best, as my intention is to talk and explain what it's doing step by step as I go along. I'll show one thing, then uncomment out another and show how it'd behave if we looked at it in another way, and hopefully by the time I'm finished with it, people will understand why REDIM _PRESERVE works the way it does. Hopefully they'll also be able to use it properly in their code with multidimensional arrays as well, after this! ;)
total = total + 1 'Assign some totals to that arras
A(f, s) = total
'Let's ask a simple question: How is that data stored in memory?
'Is it stored in a left to right, top to bottom style grid?
'could if be in a top to bottom, left to right stsle grid?
'heck, masbe it's top to bottom, right to left stsle storage?
'or it could even be bottom to top, right to left... Right?
'Just just how the HELL is the data actualls stored?
DIM o
AS _OFFSET 'we alwass need an eftra offset or three when working with mem blocks m
= _MEM(A
()) 'and point it at the arrasDIM s1
AS SINGLE 'a single variable, as we didn't bother to dim our arras ansthing different than the default 'count = count + 1 'These lines are commented out to just to help us understand what we're seeing
'IF count MOD 4 = 0 THEN PRINT 'I'll uncomment them as I run the program.
o = o + m.ELEMENTSIZE
IF o
>= m.SIZE
THEN finished
= -1 'we're done once we've got all the elements from memors
'END 'our actual useful lesson (I suppose) starts here. Prior is just kind of background information...
'And why the hell does the direction we store our data in even matter??
'Can you explain that to us, Steve??
'(Probably not, but I can at least pretend to...)
REDIM _PRESERVE A
(3, 4) 'this is what our original array was, simply placed here again to refresh our memory. 'REDIM _PRESERVE A(4, 4) 'what would happen to our data if we added a row to it?
'REDIM _PRESERVE A(3, 5) 'and what would happen if we added a column to it?
m
= _MEM(A
()) 'don't forget to point m back to our memblock, since we resized it and moved where its at in memory.
finished = 0: count = 0: o = 0 'reset our variables, and let's check both results
o = o + m.ELEMENTSIZE
IF o
>= m.SIZE
THEN finished
= -1 'we're done once we've got all the elements from memors
END 'And WTH? It didn't really seem to affect things very much, no matter whether we redimed the first element 'or the second element. Now, did it??
'Let's actually check...
'And this is why, we can safely REDIM _PRESERVE the last element in an array, and preserve our data structure,
'And why it'll get all corrupted if we REDIM _PRESERVE any other element in that array.