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

This works much better, but still has some problems. It gets the BG movement to work properly, but there seems to be some sort of offset that makes it all jumbled up. Another problem is that it doesn't seem to load outside of one screen, but that could have something to do with the other bug. EDIT: Screenshot: I'm kind of proud actually; this is the highest resolution and it runs at 60FPS

Alright I tested it and it's actually faster to just use a loop and copy 1 row of data at a time, like this:

'L: which text screen to use
'X,Y,W,H: the region inside the screen to load to
'OX,OY: the offset inside MAP to load from
'MAP: map data
DEF TLOAD2 L, X,Y,W,H, OX,OY, MAP[]
 OX=FLOOR(OX)
 OY=FLOOR(OY)
 DIM ROW%[W*2]
 VAR I
 VAR MW=DIM(MAP,1)
 FOR I=0 TO H-1
  COPY ROW%,MAP,(OY+I)*MW+OX*2,W*2
  TLOAD L,X,Y+I,W,1,ROW%
 NEXT
END

Example:

DIM MAP%[1000,1000,2]
FOR Y=0 TO 1000-1
 FOR X=0 TO 1000-1
  MAP%[Y,X,0] = #TUSRCHR+RND(100)
  MAP%[Y,X,1] = #C_WHITE
 NEXT
NEXT

X=100*16
Y=100*16
LOOP
 VSYNC
 STICK 0 OUT SX,SY
 X=X+SX*4
 Y=Y+SY*4
 TOFS 0,0,-(X MOD 16),-(Y MOD 16)
 TLOAD2 0, 0,0, 20,10, X/16,Y/16, MAP%
ENDLOOP

Two things regarding that code. First is that should OX or OY in the function be negative, it will either incorrectly lay out the copied sections (not aligned), or cause an out-of-range error (because the source offset used for COPY would be negative). Also not aligned if "OX+W > MW" or an out-of-range error if the "source offset + copy amount > LEN(MAP)". Second is with TOFS, also dealing with negative numbers. The point is to limit the number from 0 (inclusive) to 16 (exclusive), but with using MOD 16, the range can actually be from -16 to 16, exclusive. Instead, use -(value AND 15).

Cool. I'll try that out.

Oh I used MOD because this only works with positive offsets With proper range checking it would have to be changed, but AND isn't perfect either because that assumes tile size is a power of 2 (which is not always the case in sb4) the correct thing would be to use X-FLOOR(X/size)*size

Wow thank you 12 It works really well and is really fast. Runs at smooth 60 FPS. The only issue the out of range errors that come from when part of the screen doesn’t contain map data, but that’s not a horrible bug. EDIT: I found a bug

True about using AND in SB4 because tile sizes can be 24, 48, etc. Well, if you aren't planning on having areas outside of the map viewable area (restricting to 0,0-mapw-maph), then you can restrict it easily via... X = MIN( MAX( 0, X ), MAP_PWIDTH - SCREEN_PWIDTH) Y = MIN( MAX( 0, Y ), MAP_PHEIGHT - SCREEN_PHEIGHT) PWIDTH/PHEIGHT is the width/height in pixels, not tiles. edit: Can't quite read your output in the top-left, but is that showing your screen coordinates in the negative? Be aware that COPY operates with arrays like they are 1D, so if your array is 20x20, and it's trying to grab from a spot starting at [2,-5], the calculations would make that index 35 in 1D, which is [1,15] in 2D, on the row just above what you want to grab. Same if with a 20x20 array, you grab from [1,15] and plan to copy 20 tiles, it won't stop at [1,19], but runs through the next row until it hits [2,15], and plops all 20 tiles on the same row.

True about using AND in SB4 because tile sizes can be 24, 48, etc. Well, if you aren't planning on having areas outside of the map viewable area (restricting to 0,0-mapw-maph), then you can restrict it easily via... X = MIN( MAX( 0, X ), MAP_PWIDTH - SCREEN_PWIDTH) Y = MIN( MAX( 0, Y ), MAP_PHEIGHT - SCREEN_PHEIGHT) PWIDTH/PHEIGHT is the width/height in pixels, not tiles. edit: Can't quite read your output in the top-left, but is that showing your screen coordinates in the negative? Be aware that COPY operates with arrays like they are 1D, so if your array is 20x20, and it's trying to grab from a spot starting at [2,-5], the calculations would make that index 35 in 1D, which is [1,15] in 2D, on the row just above what you want to grab. Same if with a 20x20 array, you grab from [1,15] and plan to copy 20 tiles, it won't stop at [1,19], but runs through the next row until it hits [2,15], and plops all 20 tiles on the same row.

The position labeled screen coords is what I put into BGOFS. The one above it is raw pixel data for where the player is relative to the map, and the one below is what I put into NTLOAD. But what you said makes sense. I’ll play with that a bit.

Ok my map system works well now. Thank you so much. EDIT: What I did about the map wrap issue is I checked if OX*2+W*2 is bigger than DIM(MAP,1). If it was, I set W to DIM(MAP,1)/2-OX.

Oh hey I just discovered something while rewriting Wonderflonium. It seems like they fixed the TLOAD problem with the negative position, so I don’t need to use that new function anymore. I assume TLOAD is faster. Maybe I should check that. EDIT: It seems the new TLOAD function is actually faster. This could be because it loads only the section of the map you specify, while TLOAD loads the whole map with the arguments I put. Maybe if I change those, it’ll be faster. EDIT2: So I can’t find a working way to change the arguments of TLOAD so I guess I’m using NTLOAD. It’s so much faster.