[Dude]

Current issue: I'm having a hard time figuring out how to pick which tiles need to be shown onscreen. I'm getting 'tile pop', which is a result of the game dividing the screen coordinates by 256 to get the tile index of the upper left corner, and it is admittedly imprecise, which is causing the top and left rows to disappear when the division splits them off.



somewhat recent implementation: http://pastebin.com/zRsu0mCY

This post has been edited by Dude: 20 November 2010 - 10:07 PM

[GerbilSoft]

Your conversion from row/col to index is slightly off. You should only multiply the row value by 256, not the column value.

CODE

inline int rowcolToIdx(int row, int col)
{
    return (col + (row * 256));
}

inline int rowFromIdx(int idx)
{
    return (idx >> 8);
}

inline int colFromIdx(int idx)
{
    return (idx & 0xFF);
}

Do note that these functions may end up returning an invalid index if the row value is too high. You'll have to add bounds checking yourself.

Also, you might want to use unsigned values instead of signed values to prevent negative values. I used int for conciseness.

This post has been edited by GerbilSoft: 17 November 2010 - 11:37 PM

[Dude]

http://pastebin.com/Apt8UhGU

If anyone can figure out why the level isn't rendering, you win a cookie!

[DigitalDuck]

If anyone can figure out why the level isn't rendering, you win a cookie!

Lines 351-354:

CODE

                for(h = 0; h > 5; h++)
                {
                        for(v = 0; v > 5; v++)
                        {

Try making those < signs so loops work correctly.

[Sintendo]

Yeah, you do that in multiple places. Keep in mind that all types of loops in C (for, while) loop as long as the condition is true, you seem to have interpreted it the other way around (loops run until the condition is true).

Also, any reason you're not using a 2D array to begin with?

CODE

u8 tilearray[10][256];

[Dude]

Yeah, you do that in multiple places. Keep in mind that all types of loops in C (for, while) loop as long as the condition is true, you seem to have interpreted it the other way around (loops run until the condition is true).

Also, any reason you're not using a 2D array to begin with?

CODE

u8 tilearray[10][256];

The reason I'm not using a 2d array is because for some reason if I try nesting one drawcall inside of 2 for loops (to keep track of array position), GRRLIB_DrawImg only draws one of the rows, so I opted for an approach where all of the tiles can be handled in one loop and the screen coords calculated as such.

This post has been edited by Dude: 18 November 2010 - 01:03 PM

[Dude]

http://pastebin.com/sjYYPq2s

It renders stuff now, but it's rendering the wrong tiles and I'm getting 'tile pop', where the leftmost and topmost rows sometimes don't draw. Any ideas?

[DigitalDuck]

It renders stuff now, but it's rendering the wrong tiles and I'm getting 'tile pop', where the leftmost and topmost rows sometimes don't draw. Any ideas?

They both sound like camera errors. The tile pop would suggest that you're not starting with the tile that's at the very top-left corner of the screen; I can't see why it's going wrong in the code, though. As for rendering wrong tiles... is that the entire screen, or just individual tiles?

[Dude]

It renders stuff now, but it's rendering the wrong tiles and I'm getting 'tile pop', where the leftmost and topmost rows sometimes don't draw. Any ideas?

As for rendering wrong tiles... is that the entire screen, or just individual tiles?

I mean that the layout being shown doesn't match the one in the map editor. However, it does appear as though one tile on the screen usually shows the right tile, but I can't be sure. A different method for gathering the onscreen tiles might help, but I'm out of ideas for a fresh implementation.

edit: screenshot because people like pictures of stuff =P

This post has been edited by Dude: 20 November 2010 - 01:03 AM

[Sintendo]

I'm not sure if this is related, but you're going out of your vis_tiles array bounds.

CODE

unsigned int vis_tiles_1[3];
unsigned int vis_tiles_2[3];
unsigned int vis_tiles_3[3];
unsigned int vis_tiles_4[3];

Keep in mind that these arrays can only contain 3 items and the highest usable index for them is 2.

CODE

for(h = 0; h < 4; h++) // first row
{
    vis_tiles_1[h] = first_tile + h;
}

for(h = 0; h < 4; h++) // second row
{
    vis_tiles_2[h] = (first_tile + 256) + h;
}

...

I'll let you know if I find more.

[Dude]

The level is loading properly, the only immediate issue is the tile pop (left/uppermost tiles disappearing unless camera coordinates are divisible by 256).

http://pastebin.com/iApiBywT <- latest source, for the curious/helpful =]

This post has been edited by Dude: 20 November 2010 - 11:24 PM

[Sonica]

Not being able to help, I'll say this: This looks really interesting, it'd be nice to see a video =P.

[Dude]

Level rendering works now, onto collision detection.

This post has been edited by Dude: 21 November 2010 - 09:47 PM

[Aerosol]

Just as a note, Dude, every engine I've ever seen has the layer switching at the apex of the curve, so in the case of a loop, the point at which you switch from one layer to the other should be at the top of the loop. The way you have it, you go from layer 1 to layer 0 to layer 2, with layer 1 being blue, layer 0 being the regular layer, and layer 2 being the red. It should go straight from layer 1 to layer 2 at the top of the loop.

[Dude]

Just as a note, Dude, every engine I've ever seen has the layer switching at the apex of the curve, so in the case of a loop, the point at which you switch from one layer to the other should be at the top of the loop. The way you have it, you go from layer 1 to layer 0 to layer 2, with layer 1 being blue, layer 0 being the regular layer, and layer 2 being the red. It should go straight from layer 1 to layer 2 at the top of the loop.

I'm only rendering the collision ATM, the object for layer switching hasn't been implemented yet. I'll remember that though.