LoginLogin
Might make SBS readonly: thread

SmileBASIC 4 Discussion「プチコン4」

Root / General / [.]

📌
MZ952Created:
Yeah but I kind of want the text to scroll to the left. Maybe I can come up with a way to make 0,0 be the bottom right? idk

Yeah but I kind of want the text to scroll to the left. Maybe I can come up with a way to make 0,0 be the bottom right? idk
My current method for scrolling involves using SCROLL to shift the current text-screen contents in the opposite direction of where I'm scrolling, and then filling in the empty section made from the shift with the proper information from my map data. I keep track of the actual position, but also use variables that keep track of the offset on the X/Y axis, limiting it to within the area of the tilesize. This offset is what I use with TOFS. If this offset is < 0 or >= tilesize, then I either add/subtract the tilesize, shift the TS contents, then fill in the new map information. Right now, I'm trying to find a better method for filling in the new information, as filling in one tile at a time is processing that could be spent elsewhere. Filling in the information when scrolling vertically is easy enough because of how arrays are arranged, but horizontally is different.

Yeah but I kind of want the text to scroll to the left. Maybe I can come up with a way to make 0,0 be the bottom right? idk
My current method for scrolling involves using SCROLL to shift the current text-screen contents in the opposite direction of where I'm scrolling, and then filling in the empty section made from the shift with the proper information from my map data. I keep track of the actual position, but also use variables that keep track of the offset on the X/Y axis, limiting it to within the area of the tilesize. This offset is what I use with TOFS. If this offset is < 0 or >= tilesize, then I either add/subtract the tilesize, shift the TS contents, then fill in the new map information. Right now, I'm trying to find a better method for filling in the new information, as filling in one tile at a time is processing that could be spent elsewhere. Filling in the information when scrolling vertically is easy enough because of how arrays are arranged, but horizontally is different.
Since TARRAY() is two-dimensional, you may be able to use RINGCOPY to copy in vertical data. You'll have to put the data you're copying into an array with first dimension equivalent to the height of the text screen.

Hmm

Is there a way to have a 2D array be treated like a 1D array, besides copying from 2D to 1D?

You can access a multidimensional array like a singledimensional array, for example:
VAR ARR[4,4]
ARR[8]=1 'this is equivalent to ARR[2,0]=1

You can access a multidimensional array like a singledimensional array, for example:
VAR ARR[4,4]
ARR[8]=1 'this is equivalent to ARR[2,0]=1
I should have been more specific. There are commands that can utilize both 1D and 2D arrays, and while I have a 2D array, I'd like the commands to utilize it like a 1D array, as it would handle it differently.

Which commands?

Which commands?
FILL, COPY, probably like 2 others.

Yeah, how can I use COPY on an array? I've tried experimenting with RINGCOPY, and I can't get it to work.

COPY just copies elements from the source array to the destination array, given a beginning offset in the source, a beginning offset in the destination, and a number of elements to copy from the source to the destination.
DIM B[3]:FILL B,1
DIM A[6]
COPY A,2,B
PRINTALL A
> 0,0,1,1,1,0

Yeah, how can I use COPY on an array? I've tried experimenting with RINGCOPY, and I can't get it to work.
RINGCOPY has various limitations. Firstly, if both destination and source are 2D, they must have the same number of channels (first dimension). Also, I believe the source offset + number of elements to copy has to be less than or equal to the number of elements in the 2nd dimension. Probably other restrictions.

Hmm. Is it possible to use COPY on a square area in a 2D array? Are there any alternatives besides TLOAD that don’t run TPUT 7000 times every frame at full resolution? I’m thinking of having multiple arrays that each carry a row or column and using copy like that, but it’d be pretty hard.

COPY treats every array as 1D (since they're all linear in memory, really) so no, you can't rectangular copy a 2D array very easily.

Ok then. I guess I have my plan that I'm gonna try. Just gonna make sure, though. When referencing multi-dimensional arrays, do they increase from right to left (like 0,1; 0,2; 0,3; 1,0; etc.) or right to left? (like 1,0; 2,0; you probably get what I'm saying.)

In multidimensional arrays, the last/rightmost index is the index that counts up first. So it would be 0,0; 0,1; 0,2 etc.

In multidimensional arrays, the last/rightmost index is the index that counts up first. So it would be 0,0; 0,1; 0,2 etc.
Ok, thank you

Funny how one looks at various instructions, and think of ways to use them for a particular function as if they are the best means for it, to then spend hours mulling, coding, and testing only to have a solution that doesn't use those instructions. That's how it is for me when working on a wrap-around map solution. Tried using SCROLL and RINGCOPY in different ways, but either the code just to fill the gaps became too complex to be worthwhile (SCROLL), or copying large amounts of data took too long with very large map arrays when most of it would not be used (RINGCOPY + COPY). I finally settled with a middle ground that was both simple, and didn't deal with as much data. So simple that I wonder why it wasn't the very first method I'd have thought up. Incorporated it into my tunnel demo. https://twitter.com/DiscostewMC/status/1257460706972229637

Oh yeah. A couple days ago I was working on my graphics library, trying to get a horizontal/vertical inversion function going. I started messing around with GCOPY operations, but then I remembered that if you RSORT an empty [0,0,0,0,...] array along with a result-sorted array, the result-sorted array is reversed. So, solution: GSAVE rows and columns of the area of the graphics page to reverse, RSORT their image arrays, and GLOAD them back to the screen. Spent about an hour trying to figure out why my original code wouldn't flip even-pixeled regions the same as odd-pixeled regions only to remember this and solve the issue in 5 minutes.

So using COPY 15-45 times every second doesn’t really work, because that drops the speed from 60 FPS to 3 FPS. That’s not a joke. I really don’t know how to make working BG movement at this point. Maybe I’ll read through this thread to find out. I’m thinking about trying TOFS, then finding some way to combine 2 arrays when you approach multiples of 128. But I can’t think of any way to do that without slowing the entire thing down.