How do I use them and what are they used for?
2D arrays
Gotcha
Don't use them. They'll make your life a misery.
They might seem like a nice clean way to store data, but SB's support for them isn't mature enough.
Once you've realised there's no way to determine the dimensions of an array it'll be too late and you'll have written too much code that you won't want to go back and change it all.
Stick with 1D arrays. You can do everything with two 1D arrays that you can do with one 2D array.
Memory is plentiful, so don't worry about DIMming those extra variables :-)
Don't use them. They'll make your life a misery. They might seem like a nice clean way to store data, but SB's support for them isn't mature enough. Once you've realised there's no way to determine the dimensions of an array it'll be too late and you'll have written too much code that you won't want to go back and change it all. Stick with 1D arrays. You can do everything with two 1D arrays that you can do with one 2D array. Memory is plentiful, so don't worry about DIMming those extra variables :-)Why would you want the dimensions of the 2D arrays? If you create them, you can just store the sizes if it is absolutely needed.
ARRAYX=6 ARRAYY=3 DIM ARRAYTHING[ARRAYX,ARRAYY]1D arrays are impractical for storing 2D data. Either you need things like I%*8+J% or you have an unreasonable number of arrays that could be stored in one. I am a supporter of 2D arrays, they are invaluable in their simplicity as compared to using 1D arrays.
array war coming this summer
I used to use them a lot. I wrote a little vector library that passed 2D arrays about. It was nice and simple and pleasant to work with due to the short function calls. The trouble started when i tried making very generic library functions (like this http://smilebasicsource.com/forum?fpid=2537#post_2537 ) and I kept bumping up against the limitations of SB's handling of arrays greater than 1D.
Since then I've had no problem creating twice as many arrays as I would have done before.
Now I use X[0] and Y[0] and think of it as player.x and player.y :-)
I was hoping for a little more information about certain syntax info on 2D arrays.
I have been trying to figure out how this works on and off for a while, as the in game explanation for DIM is rather lacking imo.
EDITED so that the code shown works as intended, with a few minor additions:
@STARTUP
ACLS
BACKCOLOR #WHITE
DIM SUIT$[4]
SUIT$[0]="C" 'pretend theses are the suit symbols
SUIT$[1]="D"
SUIT$[2]="S"
SUIT$[3]="H"
DIM RANK$[13]
RANK$[0]="2"
RANK$[1]="3"
RANK$[2]="4"
RANK$[3]="5"
RANK$[4]="6"
RANK$[5]="7"
RANK$[6]="8"
RANK$[7]="9"
RANK$[8]="10"
RANK$[9]="J"
RANK$[10]="Q"
RANK$[11]="K"
RANK$[12]="A"
DIM DECK$[13,4]
FOR S=0 TO 3
FOR R=0 TO 12
' DECK$[R,S]=DECK$(SUIT$[S],RANK$[R])
DECK$[R,S]=RANK$[R]+SUIT$[S]
NEXT R
NEXT S
'? DECK[10,3] 'to test if it worked.
R=RND(12)
S=RND(3)
IF S==0 OR S==2 THEN COLOR 1,0
IF S==1 OR S==3 THEN COLOR 3,0
? DECK$[R,S]
I get a syntax error for DECK$[R,S]=DECK$(SUIT$[S],RANK$[R]), and I tried several variants.
So it took a bit of haggling with the code to find the correct syntax for what I was trying to ask the program to do.
DECK$[R,S]=DECK$(SUIT$[S],RANK$[R])
This was kind of a dumb guess, but it just happened to be the last guess I attempted to get this to work, when I saved my program.
and the last DECK line was a typo, it was correct in the code. I also flipped the rank and suit in the typed up version too.
ANSWER:
DECK$[R,S]=RANK$[R] + SUIT$[S]So I had to ADD the two string outputs from the separate arrays together under the DECK$ array reference for that location on the grid. The space before and after the plus symbol is there for emphasis. (I swear that I thought I tried this at some point before posting. oh well) Another question: When using a 2D array for a board game, such as chess. IS it more practical to make the chess piece types represented as an integer? To make it easier to change the pawn when promoted? (0=pawn, 1=BISHOP, 2=KNIGHT, 5=QUEEN... ect) OR Should each piece have a number assigned to it? (White pawn #0-7, White bishop #8-9 ect)
I would have an array full of the locations of each piece. Example:I'm not sure I'd do it like this. For starters, you'd also have to keep track of the kind of piece too, because pawns can be promoted to a queen, knight, rook, or bishop when they reach the opposite end of the board. Determining what piece is in a given space would require searching the entire array for a piece with the given coordinates, every single time, instead of simply checking the value in a given cell of the board array directly. There's more opportunities for things to go wrong, because that structure doesn't make it impossible for multiple pieces to have the same coordinates, unlike the board array. It brings up the question of what to do with captured pieces. In the board array, the piece is simply removed, but with this piece array you'd need to have some special value like setting the coordinates to (-1, -1), which could be error-prone. It's also kind of unnecessary because each piece doesn't really need to be kept track of individually like this. All white pawns are exactly the same and can be treated interchangeably, so just storing the type of piece in a given spot, like in the board array, is enough.DIM ARR[32,2]'Amount of pieces * 2 for x/yARR[0,0] for example could be the x coordinate of a white pawn or pretty much whatever you want (though it may be a good idea to organize it).
That's true. I guess I should have considered that this is chess.
But there are still useful ways to use the method I shared. Like for instance bullet data in a Diep.io remake (yes, I used this strategy in that). The difference is that there aren't cells, and I can tell if a bullet exists based off of SPUSED. But that's a whole other thing for another time.
I don't think there would be any advantage to giving each piece a unique number Maybe use positive/negative numbers for white/black pieces (and 0 for empty spaces) so you can get the piece type with ABS() and the color with SGN()This is GOLD. If I wasn't busy trying to learn to shuffle a deck of cards in an array I would probably try doing this for the chess game exercise. I am also messing around with parallel 2D arrays for simple data for locations so all the info for the card deck can be called with less complication. (Such as in the card game Hearts writing data to a separate parallel array to determine card point values. or black jack where several of the cards have the same value.)
If I wasn't busy trying to learn to shuffle a deck of cards in an arrayPsst my take on Solitaire is open source.
Psst my take on Solitaire is open source.I have attempted to look at your code, and have played and enjoyed it. In fact I have found that looking at your work has inspired me to use a little more decorative comments in my programs for the future. Sadly I understand about 1/3 of the code, and is partly my motivation to finally get cracking on learning the proper syntax for arrays a few weeks ago. So because of the limits of my understanding and the fun joy of exploration of making a version of a card game mostly myself I will try not to use too much of your code directly. I learn best, and exercise my brain the most, by hammering out each problem as it comes. And when I get stuck, I will post on this wonderful forum for help :) . I have had the goal to make my own Trading Card Game in Petite Computer, then Smile Basic (3) and now while I am closer, I hope to finally get to that point in SMILE BASIC 4. (IF it ever comes out in 2020)
Sadly I understand about 1/3 of the code.I can't remember what I named it off the top of my head, but it's probably some variation on the name @RANDLIST. I do know that's how the deck is shuffled in Super Bearland. Suppose you want a deck of 52 cards: The way I handled it was to generate a list of integers in order (1, 2, 3... 50, 51, 52) and then randomly pick two of those integers and swap them. I repeated this random swapping 52 * ENTROPY times. (I think I set my ENTROPY variable to 5, but 3 is probably enough.) That's not the only way to shuffle a deck, but it's how I do it anyway. And if your deck isn't too large, the shuffle happens faster than you can blink.