Sub-pixel Positioning Question - Smooth Scroll / Parallax (solved)

[SSH]

Can't you just blow up all the sprites and BG by 10x, draw at appropriate place and then scale it all down again?

[Snarky]

You missed something. - convolution is by definition a Fourier-space based approach and not a per-pixel approach (although many of the same effect can be achieved in a loop, as you described, but it will be very ineffective).

This is not quite accurate. Convolution is a coordinate-space operation that is usually (in this context) implemented by converting to frequency-space using a Fourier transform, multiplying, and converting back, which works because of a theorem that says convolution in coordinate-space is equivalent to multiplication in frequency-space.

[Misj']

This is not quite accurate. Convolution is a coordinate-space operation that is usually (in this context) implemented by converting to frequency-space using a Fourier transform, multiplying, and converting back, which works because of a theorem that says convolution in coordinate-space is equivalent to multiplication in frequency-space.

Even that is not quite correct - Convolution is strictly speaking the result of two functions that are 'combined' into a third (by summation in real space which equals multiplication in frequency/Fourier space).

In image processing this normally means that the first 'function' is the original image and the second function is the distortion (point spread function) which together result in a 3rd function (the distorted image). One can, however, argue that the original image is only (described as) a function upon converting it to frequencies/Fourier space and not while it's still in real/coordinate space. As a result, only the frequency-space operation is convolution, while the coordinate-space operation produces the same result but is not convolution - in the strictest sense - because the operation of combining two functions was not performed. That is of course a discussion on semantics.

And I'm afraid we (or at least I) are not really helping Ali anymore

[Snarky]

One can, however, argue that the original image is only (described as) a function upon converting it to frequencies/Fourier space and not while it's still in real/coordinate space.

You could argue that, but you'd be wrong. An image is a perfectly respectable function from x*y coordinate space into color space (or color + alpha, if you have transparency).

[Misj']

You could argue that, but you'd be wrong. An image is a perfectly respectable function from x*y coordinate space into color space (or color + alpha, if you have transparency).

One could argue that (I won't concede my defeat, but won't deny you your victory on this either* )

Still...ideally AGS would support FFT and some basic convolution algorithms to achieve these kinds of effects (like blurring and sub-pixel movement) on RGBa images. On the other hand I also understand - and agree - that (the core) AGS might not be the right place to include this since it doesn't really add to the actual AGS business which is: making adventure games.



* My wife is a mathematician/statistician. She agrees with you that you can consider an image a function...since I'm not allowed to disagree with my wife (it was somewhere in the marriage fine-print) I have to agree with her and thus (indirectly) with you...darn

[Snarky]

Mathmo 4 Life!

We actually discussed sub-pixel positioning (and transformations) at Mittens, and I was surprised that even ProgZmax (who I always thought of as a hardcore pixel-art guy who'd have no time for anything that messed with the individual pixels) thought it's an important area for improvement in AGS.

As AGS games get more ambitious and polished, the number of useful applications for sub-pixel operations and rendering (as well as other effect and filters, like blurring, desaturation, etc.) increase. (Another obvious one is for scrolling credits, which look jerkier than they ought to in the current, whole-pixel implementation.) And with AGS becoming more cross-platform, implementing them in plug-ins becomes less desirable. So I think it's worth to consider adding it to the engine.

[Calin Leafshade]

This would be trivial to implement if we discontinued the DD5 rendering mode.

In DX9 you can just draw the texture at a sub pixel position and you dont have to worry about anything. The filtering is done on the GPU.

Then we just set the object and character positions to be floats and not ints.

Problem solved.

[Shane 'ProgZmax' Stevens]

I was surprised that even ProgZmax (who I always thought of as a hardcore pixel-art guy who'd have no time for anything that messed with the individual pixels) thought it's an important area for improvement in AGS.

I was rather surprised that you were surprised since I don't think I've ever given the sense to people that I'm against improvements of this nature .

In DX9 you can just draw the texture at a sub pixel position and you dont have to worry about anything. The filtering is done on the GPU.

This is true, though the current d3d 9 implementation in the engine feels a bit sluggish and inefficient to me for certain operations and could do with a look at first.  I just have my doubts when I watch 50-frame 320x240 looped animations skip and stutter occasionally on a dual core 3 ghz with 8 gb of ddr3, not to mention fullscreen translucent images.  This is a discussion for another thread, though.

[Snarky]

I was rather surprised that you were surprised since I don't think I've ever given the sense to people that I'm against improvements of this nature .

Not that you'd be against it; I just didn't think it was something you'd have any personal interest in.

Can't you just blow up all the sprites and BG by 10x, draw at appropriate place and then scale it all down again?

In-engine? No. You would need to do a nearest-neighbor upscaling and a bilinear downscaling (otherwise the process ends up blurring the result), and the AGS scaling functions don't give you control over what sort of sampling function to use.

[Monsieur OUXX]

Can't you just blow up all the sprites and BG by 10x, draw at appropriate place and then scale it all down again?

In-engine? No. You would need to do a nearest-neighbor upscaling and a bilinear downscaling (otherwise the process ends up blurring the result), and the AGS scaling functions don't give you control over what sort of sampling function to use.

I'd also add that I tried that manually using a Paint program, and I was not very happy with the result. when the movement is really really slow, then it's like each row of pixels slowly fades in, one after the other. As soon as a row has finished fading in, the next one starts fading in above it (if the sea is moving up). In the end it looks like a weird Tetris game (with rows of pixels piling up) rather than an actual movement.
But I must admit there is virtually no other solution.

[Snarky]

That's probably unavoidable whatever method you use, though. (All the methods discussed should give "pretty much"/exactly the same result.) When you place a sprite by sub-pixel, it'll cover only a fraction of the pixels on the edges, which must be rendered as part transparency. As you keep moving it up, it will cover more and more of the top edge pixels, so the effect will be that the row is slowly fading in. When the resolution is low and the pixels big, that becomes noticeable.

I get a similar artifact with my blending method. I tried to counter it by reducing the update frequency to about 10 frames per second (so that it would fade in step-wise rather than smoothly, but still more smoothly than full-pixel movement). I didn't end up using it, but maybe you'll like it better that way.

The other point to keep in mind is that when movement is that slow it doesn't draw the eye (you know those psych experiments where you stare at a picture to try and see what part is changing and it's almost impossible because it's so slow that you have to look at the same spot for several seconds to notice it), so it's not going to be as noticeable to a player watching the scene as a whole as it is to the designer staring at it, particularly if you add other, more dramatically animated elements to the scene as a distraction. Or just animate the sea itself: if it' actually changing as it's sliding up and down, I don't think it will look like it's fading any more.

[Monsieur OUXX]

My point was (advice to Ali) : Avoid a straight-line sea. Maybe use an animated sea, or something. Or a trick of any sort. A sub-pixel movement applied to a straight line looks crap, and a sub-pixel movement applied to a texture movement looks blurry.

[Snarky]

Although if this is for Nelly Cootalot 2, which I think is being made in 800x600, I don't think those problems will be very noticeable.

[Ali]

I was away from the internet for two days and a debate about maths I don't understand kicked off!

My point was (advice to Ali) : Avoid a straight-line sea. Maybe use an animated sea, or something. Or a trick of any sort. A sub-pixel movement applied to a straight line looks crap, and a sub-pixel movement applied to a texture movement looks blurry.

It was actually foreground objects that were most noticeably jerky, but as Snarky says the sub-pixel fading is not noticeable at 800x600 and at the speeds I'm moving the screen. I have a hack that works, and if I can find the time to get to grips with convolution, I'll try integrating something much cleverer into the engine. Although I'm secretly hoping that this will happen and I don't have to:

This would be trivial to implement if we discontinued the DD5 rendering mode.

[BigMc]

One more reason to consider porting the engine to Allegro 5, which is inherently sub-pixel accurate.