Gameboy Development Forum

Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)

You are not logged in.

Ads

#1 2017-09-02 11:54:54

drludos
Member
Registered: 2017-05-11
Posts: 48

GBDK: weird wrapping behavior of set_bkg_tiles()

Hi everyone,

I'm still working on my first title using GBDK, and I've encountered a strange behavior with "set_bkg_tiles".

Using this function, you can defines X tiles on the background map.

For example, let's say that I'm copying a "line" of 5 tiles to my background. I'll use the function:
set_bkg_tiles(0, 0, 5, 1, my_tiles);
(for non GBDK users, params are X,Y starting coordinates in the tilemap, width, height, tile_data)

My tilemap would look like this:
(* is "empty tile", and 12345 the tile I'm copying, and the real tilemap is 32*32, below is a reduced size figure)

12345***
********
********

Most of the time, it's working fine.
However, If I'm copying a tile series longer than the remaining available tiles, they'll be "wrapped" (which is great) but not on the same line (which is strange and currently annoying me)

Using : set_bkg_tiles(5, 0, 5, 1, my_tiles);

Will result in :
*****123
45******
********

While I would have expected the result to be:
45***123
********
********

The behavior is even weirder with Y wrapping: it simply doesn't happen (the "extra" tile are simply not copied).

My question is:
Is there a way to control how "set_bkg_tiles" will wrap data? Ideally, I'd like this function to wrap on the same line in X, and also be able to perform a wrap in Y.

Thanks a lot for your help!

Last edited by drludos (2017-09-02 12:16:06)

Offline

 

#2 2017-09-02 12:35:26

ISSOtm
Member
From: Somewhere in Echo RAM
Registered: 2017-04-18
Posts: 126
Website

Re: GBDK: weird wrapping behavior of set_bkg_tiles()

The reason this happens is that (the way I see it) this function is simply a "memcpy" tailored to suit VRAM. Thus, X wrapping does not occur, and Y wrapping doesn't either - thus, either it writes to the 9C00 tilemap (if using the 9800 tilemap) or SRAM (if using the 9C00 tilemap).
Thus, I would assert that there is no way. If that is the case, you should write a function yourself.


The French Lord Of Laziness.
Legend of Zelda and Undertale fan, I also tend to break Pokémon R/B/Y a little too much.

Twitter | Me on GCL | Discord : ISSOtm#9015 | Skype : isso.tm (I don't login anymore)

Offline

 

#3 2017-09-02 12:58:21

ssjason123
Member
Registered: 2017-03-21
Posts: 38

Re: GBDK: weird wrapping behavior of set_bkg_tiles()

This "wrapping" is just a behavior of a contiguous block of memory. If you laid each of your rows end to end that would match the way the memory is laid out. The tile pointer is just being incremented by one from your start position for each tile you are trying to copy. In the case of the Y not wrapping its just continuing to increment and writing to memory beyond the tile buffer.

For example we have a 2 dimensional array in memory something like char blah[3][3]. In memory this is treated as a contiguous block of memory like:
[0][1][2][3][4][5][6][7][8]

As a 2d array we would visualize it as:
[0][1][2]
[3][4][5]
[6][7][8]

The C compiler performs pointer calculations for look ups such as (row * row_size) + column to calculate the position of the memory at a given index. For example looking up position [1][1] would perform (1 * 3) + 1 and lookup the value at the offset of 4.

To wrap in the manner you describe you would need multiple calls to set_bkg_tiles. You could use a division to determine when the row exceeds the row end and modulo to determine how many tiles should be wrapped.

Offline

 

#4 2017-09-02 20:52:03

drludos
Member
Registered: 2017-05-11
Posts: 48

Re: GBDK: weird wrapping behavior of set_bkg_tiles()

Thanks a lot ISSOtm and ssjason123 for your explanations.

After a lot of trial and error, I was able to write my own function to manually "wrap" the tilemaps I use in my game on the same line.
It involved pointers & multiple calls to set_bkg_tiles, that seems overkill for such a "simple" outcome, but I'm happy that it's working!

Thanks again a lot for your help!

Last edited by drludos (2017-09-02 20:52:52)

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson