Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / 2D: Working map scroller, but weird border problem

Author
Message
StaticSD
14
Years of Service
User Offline
Joined: 17th Jan 2010
Location:
Posted: 22nd Jan 2010 00:49
I have a function that processes data from a dynamic vector and turns it into a tiled map, and another function that scrolls around the map when the player moves. I'm not really sure how this is happening, but every row and column of tiles that is generated (which happens when they come into view of the player) sticks around on the borders of the screen when they are no longer in the view of the player. They are all stored in the same position, so basically all of the rows and columns that have been generated and that are no longer in view (ie, when the player moves away from them) are piled on top of one another on the outer edge of the screen. They should, at least, stick around OUT OF VIEW, but the "hidden" rows and columns are just barely visible - about two pixels of them stay on the edge of the screen.



This screenshot shows the "hidden" column on the left-hand side. There is a two-pixel-wide line of tiles that just shouldn't be there. The red arrows point out the places where this is visible, but they actually run up the whole side - the rest of them just blend in because they are the same color as the background.

When I run the program and I am in the position captured by the above screenshot, if I move up or down, the little rectangles get longer or shorter, respectively. This is because the "hidden" column is in a fixed position, but the visible tiles on the map move when I move the character. It's like the tiles on the map cover up the tiles in the hidden column until the map tiles move down, at which point the hidden column is uncovered.



The first column on the far left-hand side of the map is all water tiles, so it is solid blue. In the second screenshot above, I have moved all the way to the left of the map (thus generating the columns of tiles that had not been generated in the first screenshot) and then moved back to the right. If you look closely, you'll see a solid, two-pixel-wide line of blue - that is the first column of water tiles, covering up the rest of the "off-screen" tiles in the hidden column, and completely visible over the map tiles. I'm not sure why it is this way, but the top row of tiles on the map has the same effect - a solid blue line across the top of the screen.



In this screenshot I have reduced the number of visible tiles on the screen from (20, 15) to (18, 13). The highlighted row and column at the bottom-right are the hidden row and column on that side of the screen. With the original settings, these are completely off the screen and are not visible whatsoever. However, when the number of visible tiles on the screen in reduced, this hidden row/column is in clear view. Directly after I took this screenshot, I moved the player up and left one tile and took this:



As you can see, the row/column that I highlighted in the screenshot before this stayed in the same position, in what would normally be off-screen. (The reason for the misalignment of the row and column is that I first had to move up, which froze the bottom row, and then left, which then froze the right column.)

The row on the bottom and the column on the right are not important, because once I change the settings back to normal they are off-screen. However, this illustrates roughly what is happening with the hidden column on the left side, and the hidden row on the top. While they should be off-screen, as the bottom-right ones normally are, they are about two pixels further in than they should be, and so are just barely visible on the borders of the screen.

That is my dilemma. I just can't figure out how to make that stupid little border go away. For now, I'll just post all of my relevant code. Let me know if it's too much, or not enough, and I'll make changes as is necessary.

Main.h:


Main.cpp:


Player.cpp:


MapLibrary.cpp:


neguz
Marsh0
15
Years of Service
User Offline
Joined: 18th Mar 2009
Location:
Posted: 22nd Jan 2010 02:11
You could just add some code into the loop saying that if the tile is off the screen (a bigger number then is showing) then move it like 1000 pixels off the screen so its completely out of the way. Temp fix.

www.touchofdeathproductions.com
StaticSD
14
Years of Service
User Offline
Joined: 17th Jan 2010
Location:
Posted: 22nd Jan 2010 17:57
Well, that's the whole problem. I can't get it to realize that the tile is off the screen at all. I think the problem lies in the offsetX and offsetY variables, because they use modulus, so once the tiles are completely off the screen at 32 pixels, it returns 0, which puts them right back in view. I've been trying to come up with a way for it to return 32 instead of 0 when it does 32%32, but I just can't think of anything.

neguz
Tweety J
14
Years of Service
User Offline
Joined: 28th Jan 2010
Location:
Posted: 28th Jan 2010 08:02
Look in your Main.H file, in your SysVars struct...

There your view window of tiles is set to 18 * 13 tiles.

That is fine and dandy, except if you count the tiles that are being shown on your error pics, you see that 18*13 tiles are correct.

Either limit your view size to (18*32)x(13*32) pixels, or increase the number of tiles you pick and draw.

oh, By the way...

It is more difficult to change four directions than it is to change two...

look at movement on the map as if it is positive/negative movement on an axis...

something like
verticleMove = dbUpKey() - dbDownKey();
horizontalMove = dbRightKey() - dbLeftKey();

Now when you write the move code, you look at fewer variables, and if you are clever enough, knowing that you always want your guy to tend to the center of the screen, you can write one function to move the screen up AND down, then another to move the screen left AND right...

and using constant variables instead of written in numbers makes debugging a life time easier.
StaticSD
14
Years of Service
User Offline
Joined: 17th Jan 2010
Location:
Posted: 20th Feb 2010 20:53
I see what you mean, but that is not the problem. I purposely decreased the number of tiles to 18x13 to better illustrate the border problem to this thread. If you look at the first two screenshots, the number of tiles fits to the screen at 20x15, but the border problem I described is still there. I'm not quite sure what you're implying by changing two directions instead of four, but the movement code works fine for now.

neguz

Login to post a reply

Server time is: 2024-10-01 23:36:43
Your offset time is: 2024-10-01 23:36:43