[SB4] TLOAD causes map to disappear if I move too far

This worked in SB3 with BGLOAD, but not anymore. the graphics screen idea could work, just remember to store each tile as 2 pixels since TLOAD uses 2 integers per tile (the first is the tile ID+attributes and the second is the color (so you probably want this pixel to be white most of the time))

This worked in SB3 with BGLOAD, but not anymore. the graphics screen idea could work, just remember to store each tile as 2 pixels since TLOAD uses 2 integers per tile (the first is the tile ID+attributes and the second is the color (so you probably want this pixel to be white most of the time))

Yeah. I found a better way to handle this, because it's kind of involved in the graphics screen idea and could work by itself. I clip the map with a nested FOR loop. And the graphics screen idea was kind of broken anyway, because I can't (or don't know how) to combine 2 2D arrays into one 3D array that can store both the color and tile. The problem with using a nested FOR loop is that it's pretty slow, to the point that I had to lower the resolution to just above the 3DS resolution. There might be a few things I could do to optimize it, maybe ignoring blocks made of air, but I don't know.

Well you don't actually need to use a 3D array there are 2 (or actually, 3) ways you can store tile data, which are all the same internally DIM A[height, width*2], accessed as tile=A[y, x*2] and color=A[y, x*2+1] DIM A[height, width, 2], accessed as tile=A[y, x, 0] and color=A[y, x, 1] so if you're copying graphics data it would make the most sense to use the 2D form, with the data stretched horizontally to have 2 pixels per tile (and then multiply the X coordinate and width by 2)

Oh, that’s actually really cool. I’ll give it a try and see how it works out because it’s probably faster.

You two talking about using graphic pages to hold map data got me interested, so I did a very quick test to see how much time it took for a simple copy from graphic page to text screen. For a TS of 35x16, it took roughly 34 microseconds compared to the 58 microseconds my copy method requires. For a 128x128 TS, it takes roughly 566 microseconds to copy vs 720 microseconds by my method. Certainly advantageous (faster, doesn't take from available memory used for arrays, variables, etc) with the only downsides being that it's limited to a map size of 1024x2048 (though who would use such a large map size?), and the fact that it uses graphic pages that would normally be used just for graphics, so that's less for them.

with the only downsides being that it's limited to a map size of 1024x2048 (though who would use such a large map size?), and the fact that it uses graphic pages that would normally be used just for graphics, so that's less for them.

Actually, I'm not limited to that small of a map, and I do plan to have bigger maps. You see, GLOAD can accept negative coordinates, and I just copy the top corner of the graphics screen. That way, I can have as much map data as memory will allow.

with the only downsides being that it's limited to a map size of 1024x2048 (though who would use such a large map size?), and the fact that it uses graphic pages that would normally be used just for graphics, so that's less for them.

Actually, I'm not limited to that small of a map, and I do plan to have bigger maps. You see, GLOAD can accept negative coordinates, and I just copy the top corner of the graphics screen. That way, I can have as much map data as memory will allow.

Maybe I misunderstood what you were trying to do. Are you using graphic pages as a temporary buffer for this?

Yes, and I use the x,y parameters of GLOAD to scroll it, making it so that I can have some pretty big maps.

I'm getting something strange...

Maybe you have to specify the width and height of the array on GLOAD.

GLOAD X*2,Y,W*2,H,ARR,0

Turns out that using GLOAD doesn't really work... What seems to be going on could be two different possibilities. One is that it doesn't like the colors I put on the scren, and so it changes them. I don't think that that's it, though, because the color that's changing is one that G commands like. It's #C_WHITE. The other more likely possibility is that the coordinates are getting messed up, somehow. No matter how I try to rotate the coordinates, none of them really match up. And while 0,0 stays &HE800, 0,1 changes to something along the lines of 4960287384028460. (I don't remember the exact number.)

Turns out that using GLOAD doesn't really work... What seems to be going on could be two different possibilities. One is that it doesn't like the colors I put on the scren, and so it changes them. I don't think that that's it, though, because the color that's changing is one that G commands like. It's #C_WHITE. The other more likely possibility is that the coordinates are getting messed up, somehow. No matter how I try to rotate the coordinates, none of them really match up. And while 0,0 stays &HE800, 0,1 changes to something along the lines of 4960287384028460. (I don't remember the exact number.)

Are you accessing [0,1] to get the next tile? Remember, 2 entries/pixels per tile, the first being the tile number + attributes (rotation, flipping), the second being the color (which is typically &HFFFFFFFF for complete white, or an unsigned value of ‭4,294,967,295‬). To access the tile number for the second tile in the sequence, you need to read [0,2], then [0,4] for the 3rd, etc.

No. I just plug it into TLOAD. What I was saying is that 0,1 is supposed to be #C_WHITE, but instead of being -1 (also white) it's something way above zero. I guess I should've clarified that. Another thing I should mention is that by rotating the data, I mean swapping X,Y to Y,X and vice versa. I'm not sure how much this has to do with the bug though.

OH I FORGOT! There's a bug in GSAVE You have to make sure to use an integer array with GSAVE, otherwise it won't give the correct values (it uses unsigned instead of signed integers when you use a float array)

GPSET 0,0,#C_WHITE
DIM A#[1],A%[1]
GSAVE 0,0,1,1,A#
GSAVE 0,0,1,1,A%
?A#[0] '4294967295
?A%[0] '-1
?#C_WHITE '-1
RGBREAD A%[0] OUT A,R,G,B
?A,R,G,B '255 255 255 255
RGBREAD A#[0] OUT A,R,G,B 'overflow error
RGBREAD INT(A#[0]) OUT A,R,G,B 'overflow error

And if you try to convert the float to an int, it'll just give an overflow error, so the value is basically useless. Hopefully they'll fix this someday (I doubt it though, since it's existed since SB3) though it's better to use an int array anyway, because it's more efficient

OH I FORGOT! There's a bug in GSAVE You have to make sure to use an integer array with GSAVE, otherwise it won't give the correct values (it uses unsigned instead of signed integers when you use a float array)

GPSET 0,0,#C_WHITE
DIM A#[1],A%[1]
GSAVE 0,0,1,1,A#
GSAVE 0,0,1,1,A%
?A#[0] '4294967295
?A%[0] '-1
?#C_WHITE '-1
RGBREAD A%[0] OUT A,R,G,B
?A,R,G,B '255 255 255 255
RGBREAD A#[0] OUT A,R,G,B 'overflow error
RGBREAD INT(A#[0]) OUT A,R,G,B 'overflow error

And if you try to convert the float to an int, it'll just give an overflow error, so the value is basically useless. Hopefully they'll fix this someday (I doubt it though, since it's existed since SB3) though it's better to use an int array anyway, because it's more efficient

So then should I define the array as an integer array? I've seen in the reference a command that does this (I think)

As long as the array name ends with a %, it'll be an integer array, so all you have to do is this:

DIM NAME%[123]

I thought one of the selling points of the SB4 language was that vars are like type interchangeable. A bug like that would seem to violate that. So, maybe they'll fix it?

Ok, so I got it to display a map, but there's a problem.

I noticed you changed your NTLOAD parameter values for W and H (inputting XW and XH). What do those represent? Anyways, I think GLOAD works a little differently than what one might think.The parameters aren't for the array for which to copy from. It's for the graphic page of where to place the data. The array it takes from becomes represented a a 1D array, much like how COPY works, but with no offset for the array. The point of GLOAD is probably meant to go in tangent with data retrieved via GSAVE, which its own parameters define the section to copy from the graphic page. Think of it like their combined functionality (GSAVE -> GLOAD) acts like GCOPY, only you get to edit the section of data that does get copied before placing it into the graphic page again. So, you probably need to go back to using MAPW and MAPH for your W and H parameters, and work from there. Try this.

DEF NTLOAD L, X, Y, W, H, TW, TH, ARR%
  DIM NARR%[TH, TW*2]
  GLOAD X*2, Y, W*2, H, ARR%, 0
  GSAVE 0, 0, 0, TW*2, TH, NARR%
  TLOAD L, 0, 0, TW*2, TH, NARR%
END

X/Y are the positions on your array. W/H are the dimensions of your array (not taking into account that each entry is 2 elements rather than 1). TW/TH are your text screen dimensions (again, not including 2 elements per entry). This is under the assumption that your space on the graphic page starts at [0,0], and has the same W/H as the text-screen which you want to copy to, as well as having GCLIP already set to clip around that same area. If you still have trouble trying to do this, I can probably supply my copy version as early as tomorrow (that's when my weekend from work starts), but it still has a few bugs to iron out.