Accurate zooming out

[shadowmouse]

I've been using multiple sprites to make a single object with several independent moving parts and it all works fine. However I've realised that the images are twice as big as they should be. I tried using view.zoom(2), and while this zooms out fine, it means that every few frames, the sprites move and gaps appear. I also tried doubling the resolution of the spritesheet with gimp and getting rid of the zoom, thinking that if the pixels are half the size, then they should be half as big on the screen, but it had no effect. Is there any way I can solve this? What I'm saying is, is there any way to increase the resolution of an image/texture?

[Nexus]

What I'm saying is, is there any way to increase the resolution of an image/texture?

Strictly speaking, resolution is the number of data points (pixels) per area, and is only a meaningful metric for things like display or print devices. An image is merely a collection of pixels without a length metric.

Often, the word "resolution" is also used when it simply means "size", i.e. width*height. Of course, the size of an image/texture is the one you give it.

it means that every few frames, the sprites move and gaps appear.

Then you're not moving them at the same pace. Make sure the positions and origins are all correctly aligned with each other.

[shadowmouse]

I specifically run the same code block which applies a predetermined constant to each of the sprites' positions relative to the object holding them which is the thing that moves every time the move function is run. I have a feeling it might be because some of the positions are odd and some are even so when I zoom the view out they don't line up. Is there any way to solve this, seeing as some sprites have to have an odd offset from each other?

[Nexus]

Round the positions to a multiple of 2 before rendering.

Your game logic position shouldn't be stored in the sprite anyway.

[shadowmouse]

It isn't, but what I'm saying is if I have a gap of an odd width and a sprite of an odd width to go in it, will they always be rounded down to the same size? Or a gap which is at an odd position, will both edges of that always move in the same direction?
EDIT: Never mind I got it working by having a makePosEven function that rounded all sprites' positions down by 1 if they were odd.

[shadowmouse]

That's started working fine but there's a new problem I've noticed now. I initialise my object (500,132), which is near the top of the window. But then when I zoom the view out, it appears twice as far down the window, rather than, as you would expect, half as far, as the new view is showing twice the area as before, so the offset of 132 from the top should cover half as much distance. Am I missing something?

[Hapax]

When you zoom out, things get closer to the centre. When you zoom in, they get further away from the centre.

[shadowmouse]

Ah, okay, I thought that 0,0 would stay 0,0 and the bottom right would be twice what it was when you zoom out. Forgot about views operating about their centre. Just me having another one of my idiot moments.

[Hapax]

I find views rather confusing and unintuitive as a coder but obvious when visualising it as an real view. The 'switching between realities' can be confusing and I often forget to allow for this but it makes sense in its way and is pretty easy in the most common cases.

Just in case you prefer the view to zoom at (0, 0) - or indeed any pixel - you may want to take a look at this function that I posted on the wiki a few months ago.

[shadowmouse]

Thank you. I've always found the mapPixelToCoords function rather confusing, especially because the name means nothing to me. If I was making a function for converting between absolute coords of the window and coords in the view I would have called it windowCoordsToView or viewCoordsToWindow but I guess that's just personal preference. I solved it by finding the coordinates at the top left of the window (via maths) and just using that to account for the zooming out in all my calculations. Of course I'm going to hate it when I have to cater for maximising.

[Hapax]

You're welcome.
Pixel is a specific physical pixel whereas coordinates are positions in a view and are not locked to those pixels. This would mean that "pixel" is more obvious than "window coords" and "coords" is more clear than "view", as all (most) SFML positions are coordinates in the view, not the actual pixels themselves.
I would probably name is "coordsFromPixel" or "getCoordsFromPixel" or something like that though as I prefer the 'from' function style to the 'to' sub-routine style.

Catering for the resizing of windows is my most hated design task.

p.s. Anyway, I suppose I should get back to the jam...