Tile based scrolling

[TechnoCat]

Oh right, I misunderstood "divisible by 2" for "power of 2". My mistake. Though that code make my player/enemy images blink on and off?

Change the size of your animation cells I would guess.

[Ryne]

Oh right, I misunderstood "divisible by 2" for "power of 2". My mistake. Though that code make my player/enemy images blink on and off?

Change the size of your animation cells I would guess.

My player/enemy animations are all 32x32 images. It won't matter anyway. Once I get my code all settled I'm going to start from scratch and clean up a lot of the code as well as start with a new set of images.

Actually, this may be a stupid question, but to be "po2 safe" does it HAVE to be a power of 2(meaning 8x8, 9x9, 10x10) or just divisible by 2? Is the resolution I'm using for my game 320x180 po2 safe, or should it be 324 x 196?

Anyway, I don't want to get my thread sidetracked so in case Robin comes back please check the previous page for the reply to your question

[kikito]

Actually, this may be a stupid question, but to be "po2 safe" does it HAVE to be a power of 2(meaning 8x8, 9x9, 10x10) or just divisible by 2? Is the resolution I'm using for my game 320x180 po2 safe, or should it be 324 x 196?

Power of two means that it can only be either 2, or the previous number multiplied by two. In other words, it's made only by multiplying 2s.

• 2
• 2*2 = 4
• 2*2*2 = 8
• 2*2*2*2 = 16
• 2*2*2*2*2 = 32
• 64,128,256,512,1024,2048, etc

8x8 is po2-safe, but 9x9 or 10x10 are NOT.

Both dimensions have to be po2, but they don't have to be the same. For example, a 32x64 image is po2-safe.

This applies to images and quads, but I don't think it applies to screen resolutions; those can be more or less arbitrary AFAIK.

[Ryne]

Thanks for explaining that kikito, so if I have a resolution of 320x180 it will be fine as long as all of my images are po2 safe?

Edit: I also just noticed that I "edited" one of my post's earlier, though when I submitted it, it submitted it as a different post. Very odd.

[nevon]

Thanks for explaining that kikito, so if I have a resolution of 320x180 it will be fine as long as all of my images are po2 safe?

Yup.

[Robin]

Anyway, I don't want to get my thread sidetracked so in case Robin comes back please check the previous page for the reply to your question

I looked at it, and it should work. Are you changing the player position somewhere else?

[Ryne]

Anyway, I don't want to get my thread sidetracked so in case Robin comes back please check the previous page for the reply to your question

I looked at it, and it should work. Are you changing the player position somewhere else?

I checked my code. I don't think that the player position changes EVER (except for when he jumps, and even then its only y, not x). Player.x is declared in player.lua as x=130. The keyboard controls only move the map.

Code: Select all

	if love.keyboard.isDown('right') then
		curranim = anim.runright
		player.dir = "right"
		map_x = map_x + 100 * dt
	elseif love.keyboard.isDown('left') then
		curranim = anim.runleft
		player.dir = "left"
		map_x = map_x - 100 * dt
	end

In case you're wondering, I didn't use this code that you suggested on the previous page because it didnt work:

Code: Select all

-- this in love.update, after the player position is changed:
map_x = player.x
map_y = player.y

if it helps, the follow player code only breaks after adding "- map_x" to the enemy draw code here:

Code: Select all

	for i=1, #enemies do			 
		enemies[i].anim:draw(enemies[i].x - map_x, enemies[i].y)
	end

at this point in time, the player.x never changes. If I print the enemies x, that never changes either. So If they never move then the follow code can't work because they will never be within 100px of each other.


... this is frustrating. Thanks again for the reply.

[Robin]

You're nearly there, but you're not seeing one thing.

You are changing the variable map_x when the player moves. I see two options:

1. Discard map_x altogether, use player.x in places map_x was used previously. Remember to draw the player at the right position.
2. Use player.x in the updating code, and map_x in drawing code. Set map_x to player.x at the end of love.update. This might be useful if you want to do cutscenes ore the like later on.

[Ryne]

Thanks for the reply, but I'm still really confused by what you mean by BOTH of those options.

Discard map_x altogether, use player.x in places map_x was used previously. Remember to draw the player at the right position.

when you say "use player.x in places map_x was previously used" do you mean everywhere? Including the map draw code? What do you mean by "Remember to draw the player at the right position"?

Use player.x in the updating code, and map_x in drawing code. Set map_x to player.x at the end of love.update. This might be useful if you want to do cutscenes ore the like later on.

You mean remove player.x from my player table (located in player.lua) into my game update?

I'm sorry if this is easier than I'm making it, though I'm still confused..

[Robin]

when you say "use player.x in places map_x was previously used" do you mean everywhere? Including the map draw code?

Yes. It was about banishing map_x and using player.x instead.

What do you mean by "Remember to draw the player at the right position"?

Well, of the top of my head I'm not sure what would happen, but it is very possible that it would wreak havoc on your drawing code, so I thought I'd prepare you for that. Unfortunately, I was being very vague.

You mean remove player.x from my player table (located in player.lua) into my game update?

No, I mean a conceptual split: player.x represents the true position of the player, like enemies[1].x represents the true position of the 1st enemy. map_x represents the offset at which things are drawn, the position in the real world that is drawn at (0, 0).

I'm sorry if this is easier than I'm making it, though I'm still confused..

No worries, we'll figure this out.