Smooth scrolling large textures

[FRex]

Yes but the float coord of the view gets rounded to the nearest integer, it'll always go up or down 0.5 or less.

And I still find it quite amusing how complicated is this. Back in the DOS days, after you set up your video chip interface routines in Assembly, it was so easy to draw tiles and sprites. And now with all this hardware accelerated stuff, it seems to be a nightmare, with all these vertex manipulation, and "half pixel" stuff. 

Well.

[N_K]

But why does it matter when it's only possible to transform something by one pixel? Where's the "inaccuracy" in here? I mean, I can't move a sprite to (0.5f, 0.5f), I can only move it either to (0, 0) or (1, 1).

[FRex]

Virtually impossible to spot. (I think)

[eXpl0it3r]

However, all I did now is to (again) cast the float values to int, and although it works, I know it's not the way it supposed to be done.

Generally it's advised to use the functions std::ceil and std::floor to round instead of casting, although I probably won't make much of a difference in the end result.

[N_K]

Virtually impossible to spot. (I think)

Oh, well. Thanks for explaining, although it would be great if some tile expert could elaborate a bit more about this problem (if it's a problem at all).

And I still find it quite amusing how complicated is this. Back in the DOS days, after you set up your video chip interface routines in Assembly, it was so easy to draw tiles and sprites. And now with all this hardware accelerated stuff, it seems to be a nightmare, with all these vertex manipulation, and "half pixel" stuff. 

Well.

You didn't do any programming in the DOS era, did you? Back then, I wrote a simple tile engine, and it was a piece of cake compared to what I have to do today. I had a graphics library to draw bitmaps. Each tile was a bitmap/sprite. All I had to do is to test the tile map against the screen resolution, then draw the tiles that are inside of the screen rect. No vertex arrays, no complex floating-point math, no texture coordinates. Oh well, quite off topic now... 

I generally is advise to use the functions std::ceil and std::floor to round instead of casting, although I probably won't make much of a difference in the end result.

Thanks, I'll try this.

[FRex]

You didn't do any programming in the DOS era, did you? Back then, I wrote a simple tile engine, and it was a piece of cake compared to what I have to do today. I had a graphics library to draw bitmaps. Each tile was a bitmap/sprite. All I had to do is to test the tile map against the screen resolution, then draw the tiles that are inside of the screen rect. No vertex arrays, no complex floating-point math, no texture coordinates. Oh well, quite off topic now... 

Please note I'm extremely inexperienced, not formaly educated in cs and novice and take anything I say with a grain of salt. However..
You have to write a nice foundation for your program and then doing things will start to get easy. ie. In ee I no longer worry about a lot of little things, because I have classes for all that ready and (mostly ) bug free, all I'm doing is placing requests to public interfaces (or very rarely declaring class a friend) and things are mostly insulated from each other.

[N_K]

Okay, thanks, everybody. Now everything renders and moves correctly. No artifacts or gaps between tiles.

int movementVector = std::ceil(scrollSpeed * deltaTime);

if(sf::Keyboard::isKeyPressed(sf::Keyboard::Up)) { view2.move(0, -movementVector); }
else if(sf::Keyboard::isKeyPressed(sf::Keyboard::Down)) { view2.move(0, movementVector); }
else if(sf::Keyboard::isKeyPressed(sf::Keyboard::Left)) { view2.move(-movementVector, 0); }
else if(sf::Keyboard::isKeyPressed(sf::Keyboard::Right)) { view2.move(movementVector, 0); }

Plus, I noticed if I enable VSync, the map scrolls smoothly, so what I need is indeed some kind of fixed-step timer.

Please note I'm extremely inexperienced, not formaly educated in cs and novice and take anything I say with a grain of salt.

I didn't intend to offend you in any way, I'm sorry if any of my replies seemed rude. And even if you're not experienced, you know way much more about C++ than me. And that's it, one of my biggest fault is that I was unable (and still not able) to understand the point of object-oriented programming. That's why I left programming a long time ago, I was fine with C, but I failed at C++ (and not even mentioning C#...).

[FRex]

I didn't intend to offend you in any way, I'm sorry if any of my replies seemed rude. And even if you're not experienced, you know way much more about C++ than me. And that's it, one of my biggest fault is that I was unable (and still not able) to understand the point of object-oriented programming. That's why I left programming a long time ago, I was fine with C, but I failed at C++ (and not even mentioning C#...).

No, they don't seem rude.
Since you're fine with C this might be a good read to understand what is the goal of oop(but it's old so it talks about c++98 as 'standard').
http://www.stroustrup.com/new_learning.pdf