Re: [Ohrrpgce] The parallax problem
On 9 June 2011 03:19, James Paige b...@hamsterrepublic.com wrote: On Wed, Jun 08, 2011 at 01:15:54PM +1200, Ralph Versteegen wrote: On 8 June 2011 13:06, James Paige b...@hamsterrepublic.com wrote: On Wed, Jun 08, 2011 at 12:53:56PM +1200, Ralph Versteegen wrote: On 8 June 2011 12:48, Mike Caron caron.m...@gmail.com wrote: On 6/7/2011 20:46, James Paige wrote: On Wed, Jun 08, 2011 at 12:43:12PM +1200, Ralph Versteegen wrote: On 8 June 2011 11:52, Mike Caroncaron.m...@gmail.com wrote: On 6/7/2011 19:49, Ralph Versteegen wrote: On 8 June 2011 07:34, Mike Caroncaron.m...@gmail.com wrote: On 07/06/2011 10:44 AM, James Paige wrote: Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. I meant solved in the sense that Mike (Willis) already gave the formula for that. First, let us suppose a few things: MapWidth := 3000 LayerWidth := 1000 ScreenWidth := 320 You want the layer to butt up against the left side of the map when the camera is at X = 0, and to butt up against the right side of the map when the camera is as X = (MapWidth - ScreenWidth). When on the left side of the map, the camera's X, the map's X and the layer's X are all 0. This case is easy. On the right side of the map, however, it's not so easy. The camera stop at 2680 (MapWidth - ScreenWidth), while the layer needs to stop at 2000 (MapWidth - LayerWidth). You mean the layer needs to stop at LayerWidth - ScreenWidth = 680. You get marks for correcting working-through, but this makes the rest of your post wrong. Huh? If the layer stops at 680, that means its right edge is at 1680, which puts it squarely off the screen. I thought the idea was to have the right edge stop at 3000, like the other right edges. It looks like we were talking about completely different things: I was talking about the camera position on the parallax map layer, and you about the offset of the parallax map layer to the map root slice. Either way, I am still completely confused. My attempt to use Mike's suggested formula resulted in the parallax layer being correctly placed at the bottom and right edges of the map, and being at 0,0 for all other camera positions :( set slice x(sl, (camera pixel x / (mapw -- screenw)) * (mapw -- layerw)) set slice y(sl, (camera pixel y / (maph -- screenh)) * (maph -- layerh)) No no! set slice x(sl, (camera pixel x * (mapw -- layerw) / (mapw -- screenw)) set slice y(sl, (camera pixel y * (maph -- layerh) / (maph -- screenh)) Yay! That works! Thank you! I'll spend some time messing with it and try to mentally internalize it. Another problem is that the movement is jerky when you start and stop walking. This problem is (as far as I know) common to all attempts to manually position slices relative to the map using a timer that repeats once per tick. Oh no! There are lots of different scripted effects which suffer this problem. We should consider allowing scripts to run at one of two different points each tick: at the current point before anything else happens, and also immediately before drawing the screen (specifically, after the walkabout and map layer slice positions are updated, which is currently at the beginning of displayall). Each script thread could select when it is run (having a global flag to toggle between the two would be terrible). This could potentially fit into the plans for script thread scheduling management quite well. I wouldn't want to add an approximation of this feature before we get script threads, though. So basically, scripts could be marked as before update or before draw Makes good sense to me. --- James Oh, wait. Scripts run immediately before drawing should definitely be each-frame, while other scripts may only be each-tick (if we were to end up with ticks not being the same as frames). In which case it wouldn't be just like normal script scheduling. I can't remember the conclusions of the last discussion on customisable framerate, but I'll review that before I start. I'm thinking of working on it next month. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On Tue, Jun 07, 2011 at 01:19:27PM +1200, Ralph Versteegen wrote: On 7 June 2011 12:04, James Paige b...@hamsterrepublic.com wrote: On Tue, Jun 07, 2011 at 11:39:51AM +1200, Ralph Versteegen wrote: On 7 June 2011 07:45, James Paige b...@hamsterrepublic.com wrote: On Mon, Jun 06, 2011 at 03:23:26PM -0400, Mike Willis wrote: So I don't know how to reply on those archives, but here is the crux of the parallax problem I think: You want the x coordinate of the top left of the screen to be the dividing factor, NOT the tiles. In other words, you don't want (parallax 'map' final tile x-coord) == 1/3 * (real map final tile x-coord) I haven't used tile coordinates for anything. pixel coordinates only. You want (parallax 'map' final pixel x-coord -- screen pixel size) == 1/3 * (real map final pixel x-coord -- screen pixel size) Then the script would work as intended, I think...? Alternatively, you want to work out the actual ratio of sizes RATIO as follows: RATIO:= (parallax 'map' final pixel x-coord -- screen pixel size) / (real map final pixel x-coord -- screen pixel size) and then use this RATIO in your script instead of 1/3 This all looks correct. And to be honest it hadn't occurred to me that the screen size matters (it applies only for one of the two types of parallax layers). But if fact you don't really need to worry about correcting for the size of the screen, you just need to draw a large enough corner of the map layer (a bit more than a third). Yeah, I realized I could just add 6 rows and 10 columns to my background layer to make this work the easy way, but I really wanted to figure out how to make it work when the background layer is exactly 1/3 the size of the map. I imagine that the real reason that your script isn't working is that the map root slice is placed at (-camera x, -camera y) relative to the screen, so to get the map layer to display at (camera x/3, camera y/3), you actually need to place it at offset (camera x * 2/3, camera y * 2/3) relative to the map root. Yes, absolutely right. I actually should have posted the version of that script where I was doing: camera pixel x -- camera pixel x / 3 That is as close as I got to making it work right :) --- James So, is the problem solved now? Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On 8 June 2011 07:34, Mike Caron caron.m...@gmail.com wrote: On 07/06/2011 10:44 AM, James Paige wrote: Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. I meant solved in the sense that Mike (Willis) already gave the formula for that. First, let us suppose a few things: MapWidth := 3000 LayerWidth := 1000 ScreenWidth := 320 You want the layer to butt up against the left side of the map when the camera is at X = 0, and to butt up against the right side of the map when the camera is as X = (MapWidth - ScreenWidth). When on the left side of the map, the camera's X, the map's X and the layer's X are all 0. This case is easy. On the right side of the map, however, it's not so easy. The camera stop at 2680 (MapWidth - ScreenWidth), while the layer needs to stop at 2000 (MapWidth - LayerWidth). You mean the layer needs to stop at LayerWidth - ScreenWidth = 680. You get marks for correcting working-through, but this makes the rest of your post wrong. To get a smooth interpolation, you simply need to map the camera's X% (defined as CameraX / (MapWidth - ScreenWidth)) to the layer's X% (defined as LayerX / (MapWidth - LayerWidth)). This formula is most easily expressed as: LayerX = (CameraX / (MapWidth - ScreenWidth)) * (MapWidth - LayerWidth) Correction (what msw already said): LayerX = (CameraX / (MapWidth - ScreenWidth)) * (LayerWidth - ScreenWidth) We know that when the CameraX% is 50% (1340), the LayerX should be at 1000. Let's verify that: LayerX = (1340 / (3000 - 320)) * (3000 - 1000) LayerX = (1340 / 2680) * 2000 LayerX = 0.5 * 2000 LayerX = 1000 I can't seem to find the original email in which I presume you listed the script, but if you plug that formula in, it should work. -- - Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On 6/7/2011 19:49, Ralph Versteegen wrote: On 8 June 2011 07:34, Mike Caroncaron.m...@gmail.com wrote: On 07/06/2011 10:44 AM, James Paige wrote: Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. I meant solved in the sense that Mike (Willis) already gave the formula for that. First, let us suppose a few things: MapWidth := 3000 LayerWidth := 1000 ScreenWidth := 320 You want the layer to butt up against the left side of the map when the camera is at X = 0, and to butt up against the right side of the map when the camera is as X = (MapWidth - ScreenWidth). When on the left side of the map, the camera's X, the map's X and the layer's X are all 0. This case is easy. On the right side of the map, however, it's not so easy. The camera stop at 2680 (MapWidth - ScreenWidth), while the layer needs to stop at 2000 (MapWidth - LayerWidth). You mean the layer needs to stop at LayerWidth - ScreenWidth = 680. You get marks for correcting working-through, but this makes the rest of your post wrong. Huh? If the layer stops at 680, that means its right edge is at 1680, which puts it squarely off the screen. I thought the idea was to have the right edge stop at 3000, like the other right edges. To get a smooth interpolation, you simply need to map the camera's X% (defined as CameraX / (MapWidth - ScreenWidth)) to the layer's X% (defined as LayerX / (MapWidth - LayerWidth)). This formula is most easily expressed as: LayerX = (CameraX / (MapWidth - ScreenWidth)) * (MapWidth - LayerWidth) Correction (what msw already said): LayerX = (CameraX / (MapWidth - ScreenWidth)) * (LayerWidth - ScreenWidth) We know that when the CameraX% is 50% (1340), the LayerX should be at 1000. Let's verify that: LayerX = (1340 / (3000 - 320)) * (3000 - 1000) LayerX = (1340 / 2680) * 2000 LayerX = 0.5 * 2000 LayerX = 1000 I can't seem to find the original email in which I presume you listed the script, but if you plug that formula in, it should work. -- - Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org -- - Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On 8 June 2011 11:52, Mike Caron caron.m...@gmail.com wrote: On 6/7/2011 19:49, Ralph Versteegen wrote: On 8 June 2011 07:34, Mike Caroncaron.m...@gmail.com wrote: On 07/06/2011 10:44 AM, James Paige wrote: Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. I meant solved in the sense that Mike (Willis) already gave the formula for that. First, let us suppose a few things: MapWidth := 3000 LayerWidth := 1000 ScreenWidth := 320 You want the layer to butt up against the left side of the map when the camera is at X = 0, and to butt up against the right side of the map when the camera is as X = (MapWidth - ScreenWidth). When on the left side of the map, the camera's X, the map's X and the layer's X are all 0. This case is easy. On the right side of the map, however, it's not so easy. The camera stop at 2680 (MapWidth - ScreenWidth), while the layer needs to stop at 2000 (MapWidth - LayerWidth). You mean the layer needs to stop at LayerWidth - ScreenWidth = 680. You get marks for correcting working-through, but this makes the rest of your post wrong. Huh? If the layer stops at 680, that means its right edge is at 1680, which puts it squarely off the screen. I thought the idea was to have the right edge stop at 3000, like the other right edges. It looks like we were talking about completely different things: I was talking about the camera position on the parallax map layer, and you about the offset of the parallax map layer to the map root slice. To get a smooth interpolation, you simply need to map the camera's X% (defined as CameraX / (MapWidth - ScreenWidth)) to the layer's X% (defined as LayerX / (MapWidth - LayerWidth)). This formula is most easily expressed as: LayerX = (CameraX / (MapWidth - ScreenWidth)) * (MapWidth - LayerWidth) Correction (what msw already said): LayerX = (CameraX / (MapWidth - ScreenWidth)) * (LayerWidth - ScreenWidth) We know that when the CameraX% is 50% (1340), the LayerX should be at 1000. Let's verify that: LayerX = (1340 / (3000 - 320)) * (3000 - 1000) LayerX = (1340 / 2680) * 2000 LayerX = 0.5 * 2000 LayerX = 1000 I can't seem to find the original email in which I presume you listed the script, but if you plug that formula in, it should work. -- - Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org -- - Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On Wed, Jun 08, 2011 at 12:43:12PM +1200, Ralph Versteegen wrote: On 8 June 2011 11:52, Mike Caron caron.m...@gmail.com wrote: On 6/7/2011 19:49, Ralph Versteegen wrote: On 8 June 2011 07:34, Mike Caroncaron.m...@gmail.com wrote: On 07/06/2011 10:44 AM, James Paige wrote: Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. I meant solved in the sense that Mike (Willis) already gave the formula for that. First, let us suppose a few things: MapWidth := 3000 LayerWidth := 1000 ScreenWidth := 320 You want the layer to butt up against the left side of the map when the camera is at X = 0, and to butt up against the right side of the map when the camera is as X = (MapWidth - ScreenWidth). When on the left side of the map, the camera's X, the map's X and the layer's X are all 0. This case is easy. On the right side of the map, however, it's not so easy. The camera stop at 2680 (MapWidth - ScreenWidth), while the layer needs to stop at 2000 (MapWidth - LayerWidth). You mean the layer needs to stop at LayerWidth - ScreenWidth = 680. You get marks for correcting working-through, but this makes the rest of your post wrong. Huh? If the layer stops at 680, that means its right edge is at 1680, which puts it squarely off the screen. I thought the idea was to have the right edge stop at 3000, like the other right edges. It looks like we were talking about completely different things: I was talking about the camera position on the parallax map layer, and you about the offset of the parallax map layer to the map root slice. Either way, I am still completely confused. My attempt to use Mike's suggested formula resulted in the parallax layer being correctly placed at the bottom and right edges of the map, and being at 0,0 for all other camera positions :( set slice x(sl, (camera pixel x / (mapw -- screenw)) * (mapw -- layerw)) set slice y(sl, (camera pixel y / (maph -- screenh)) * (maph -- layerh)) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On 6/7/2011 20:46, James Paige wrote: On Wed, Jun 08, 2011 at 12:43:12PM +1200, Ralph Versteegen wrote: On 8 June 2011 11:52, Mike Caroncaron.m...@gmail.com wrote: On 6/7/2011 19:49, Ralph Versteegen wrote: On 8 June 2011 07:34, Mike Caroncaron.m...@gmail.comwrote: On 07/06/2011 10:44 AM, James Paige wrote: Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. I meant solved in the sense that Mike (Willis) already gave the formula for that. First, let us suppose a few things: MapWidth := 3000 LayerWidth := 1000 ScreenWidth := 320 You want the layer to butt up against the left side of the map when the camera is at X = 0, and to butt up against the right side of the map when the camera is as X = (MapWidth - ScreenWidth). When on the left side of the map, the camera's X, the map's X and the layer's X are all 0. This case is easy. On the right side of the map, however, it's not so easy. The camera stop at 2680 (MapWidth - ScreenWidth), while the layer needs to stop at 2000 (MapWidth - LayerWidth). You mean the layer needs to stop at LayerWidth - ScreenWidth = 680. You get marks for correcting working-through, but this makes the rest of your post wrong. Huh? If the layer stops at 680, that means its right edge is at 1680, which puts it squarely off the screen. I thought the idea was to have the right edge stop at 3000, like the other right edges. It looks like we were talking about completely different things: I was talking about the camera position on the parallax map layer, and you about the offset of the parallax map layer to the map root slice. Either way, I am still completely confused. My attempt to use Mike's suggested formula resulted in the parallax layer being correctly placed at the bottom and right edges of the map, and being at 0,0 for all other camera positions :( set slice x(sl, (camera pixel x / (mapw -- screenw)) * (mapw -- layerw)) set slice y(sl, (camera pixel y / (maph -- screenh)) * (maph -- layerh)) Hmm, this is a thing that I didn't think about until just now. At which points does the script engine round off decimals? You may need to add a few (x * 10) and (y / 10)s in there... --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org -- - Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On Wed, Jun 08, 2011 at 12:53:56PM +1200, Ralph Versteegen wrote: On 8 June 2011 12:48, Mike Caron caron.m...@gmail.com wrote: On 6/7/2011 20:46, James Paige wrote: On Wed, Jun 08, 2011 at 12:43:12PM +1200, Ralph Versteegen wrote: On 8 June 2011 11:52, Mike Caroncaron.m...@gmail.com wrote: On 6/7/2011 19:49, Ralph Versteegen wrote: On 8 June 2011 07:34, Mike Caroncaron.m...@gmail.com wrote: On 07/06/2011 10:44 AM, James Paige wrote: Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. I meant solved in the sense that Mike (Willis) already gave the formula for that. First, let us suppose a few things: MapWidth := 3000 LayerWidth := 1000 ScreenWidth := 320 You want the layer to butt up against the left side of the map when the camera is at X = 0, and to butt up against the right side of the map when the camera is as X = (MapWidth - ScreenWidth). When on the left side of the map, the camera's X, the map's X and the layer's X are all 0. This case is easy. On the right side of the map, however, it's not so easy. The camera stop at 2680 (MapWidth - ScreenWidth), while the layer needs to stop at 2000 (MapWidth - LayerWidth). You mean the layer needs to stop at LayerWidth - ScreenWidth = 680. You get marks for correcting working-through, but this makes the rest of your post wrong. Huh? If the layer stops at 680, that means its right edge is at 1680, which puts it squarely off the screen. I thought the idea was to have the right edge stop at 3000, like the other right edges. It looks like we were talking about completely different things: I was talking about the camera position on the parallax map layer, and you about the offset of the parallax map layer to the map root slice. Either way, I am still completely confused. My attempt to use Mike's suggested formula resulted in the parallax layer being correctly placed at the bottom and right edges of the map, and being at 0,0 for all other camera positions :( set slice x(sl, (camera pixel x / (mapw -- screenw)) * (mapw -- layerw)) set slice y(sl, (camera pixel y / (maph -- screenh)) * (maph -- layerh)) No no! set slice x(sl, (camera pixel x * (mapw -- layerw) / (mapw -- screenw)) set slice y(sl, (camera pixel y * (maph -- layerh) / (maph -- screenh)) Yay! That works! Thank you! I'll spend some time messing with it and try to mentally internalize it. Another problem is that the movement is jerky when you start and stop walking. This problem is (as far as I know) common to all attempts to manually position slices relative to the map using a timer that repeats once per tick. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On 8 June 2011 13:06, James Paige b...@hamsterrepublic.com wrote: On Wed, Jun 08, 2011 at 12:53:56PM +1200, Ralph Versteegen wrote: On 8 June 2011 12:48, Mike Caron caron.m...@gmail.com wrote: On 6/7/2011 20:46, James Paige wrote: On Wed, Jun 08, 2011 at 12:43:12PM +1200, Ralph Versteegen wrote: On 8 June 2011 11:52, Mike Caroncaron.m...@gmail.com wrote: On 6/7/2011 19:49, Ralph Versteegen wrote: On 8 June 2011 07:34, Mike Caroncaron.m...@gmail.com wrote: On 07/06/2011 10:44 AM, James Paige wrote: Well, solved in the sense that I can add six more rows and 10 more columns to my background layer and it will look okay, but I still really want to understand the math needed to make the parallax work with the 1/3 size layer, since that is the same math that will be required when parallax scrolling is a built-in feature on different-sized map layers in the future. I meant solved in the sense that Mike (Willis) already gave the formula for that. First, let us suppose a few things: MapWidth := 3000 LayerWidth := 1000 ScreenWidth := 320 You want the layer to butt up against the left side of the map when the camera is at X = 0, and to butt up against the right side of the map when the camera is as X = (MapWidth - ScreenWidth). When on the left side of the map, the camera's X, the map's X and the layer's X are all 0. This case is easy. On the right side of the map, however, it's not so easy. The camera stop at 2680 (MapWidth - ScreenWidth), while the layer needs to stop at 2000 (MapWidth - LayerWidth). You mean the layer needs to stop at LayerWidth - ScreenWidth = 680. You get marks for correcting working-through, but this makes the rest of your post wrong. Huh? If the layer stops at 680, that means its right edge is at 1680, which puts it squarely off the screen. I thought the idea was to have the right edge stop at 3000, like the other right edges. It looks like we were talking about completely different things: I was talking about the camera position on the parallax map layer, and you about the offset of the parallax map layer to the map root slice. Either way, I am still completely confused. My attempt to use Mike's suggested formula resulted in the parallax layer being correctly placed at the bottom and right edges of the map, and being at 0,0 for all other camera positions :( set slice x(sl, (camera pixel x / (mapw -- screenw)) * (mapw -- layerw)) set slice y(sl, (camera pixel y / (maph -- screenh)) * (maph -- layerh)) No no! set slice x(sl, (camera pixel x * (mapw -- layerw) / (mapw -- screenw)) set slice y(sl, (camera pixel y * (maph -- layerh) / (maph -- screenh)) Yay! That works! Thank you! I'll spend some time messing with it and try to mentally internalize it. Another problem is that the movement is jerky when you start and stop walking. This problem is (as far as I know) common to all attempts to manually position slices relative to the map using a timer that repeats once per tick. Oh no! There are lots of different scripted effects which suffer this problem. We should consider allowing scripts to run at one of two different points each tick: at the current point before anything else happens, and also immediately before drawing the screen (specifically, after the walkabout and map layer slice positions are updated, which is currently at the beginning of displayall). Each script thread could select when it is run (having a global flag to toggle between the two would be terrible). This could potentially fit into the plans for script thread scheduling management quite well. I wouldn't want to add an approximation of this feature before we get script threads, though. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On Mon, Jun 06, 2011 at 03:23:26PM -0400, Mike Willis wrote: So I don't know how to reply on those archives, but here is the crux of the parallax problem I think: You want the x coordinate of the top left of the screen to be the dividing factor, NOT the tiles. In other words, you don't want (parallax 'map' final tile x-coord) == 1/3 * (real map final tile x-coord) I haven't used tile coordinates for anything. pixel coordinates only. You want (parallax 'map' final pixel x-coord -- screen pixel size) == 1/3 * (real map final pixel x-coord -- screen pixel size) Then the script would work as intended, I think...? Alternatively, you want to work out the actual ratio of sizes RATIO as follows: RATIO:= (parallax 'map' final pixel x-coord -- screen pixel size) / (real map final pixel x-coord -- screen pixel size) and then use this RATIO in your script instead of 1/3 This isn't boding well for users to set layer sizes and parallax speeds in custom, is it? This has nothing to do with parallax as a built-in feature, this is just about manually scripting parallax now, before such a built-in feature becomes available. This is all assuming the map doesn't wrap. If it does, then I'm not sure what is best... It does not. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On 7 June 2011 07:45, James Paige b...@hamsterrepublic.com wrote: On Mon, Jun 06, 2011 at 03:23:26PM -0400, Mike Willis wrote: So I don't know how to reply on those archives, but here is the crux of the parallax problem I think: You want the x coordinate of the top left of the screen to be the dividing factor, NOT the tiles. In other words, you don't want (parallax 'map' final tile x-coord) == 1/3 * (real map final tile x-coord) I haven't used tile coordinates for anything. pixel coordinates only. You want (parallax 'map' final pixel x-coord -- screen pixel size) == 1/3 * (real map final pixel x-coord -- screen pixel size) Then the script would work as intended, I think...? Alternatively, you want to work out the actual ratio of sizes RATIO as follows: RATIO:= (parallax 'map' final pixel x-coord -- screen pixel size) / (real map final pixel x-coord -- screen pixel size) and then use this RATIO in your script instead of 1/3 This all looks correct. And to be honest it hadn't occurred to me that the screen size matters (it applies only for one of the two types of parallax layers). But if fact you don't really need to worry about correcting for the size of the screen, you just need to draw a large enough corner of the map layer (a bit more than a third). I imagine that the real reason that your script isn't working is that the map root slice is placed at (-camera x, -camera y) relative to the screen, so to get the map layer to display at (camera x/3, camera y/3), you actually need to place it at offset (camera x * 2/3, camera y * 2/3) relative to the map root. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On Tue, Jun 07, 2011 at 11:39:51AM +1200, Ralph Versteegen wrote: On 7 June 2011 07:45, James Paige b...@hamsterrepublic.com wrote: On Mon, Jun 06, 2011 at 03:23:26PM -0400, Mike Willis wrote: So I don't know how to reply on those archives, but here is the crux of the parallax problem I think: You want the x coordinate of the top left of the screen to be the dividing factor, NOT the tiles. In other words, you don't want (parallax 'map' final tile x-coord) == 1/3 * (real map final tile x-coord) I haven't used tile coordinates for anything. pixel coordinates only. You want (parallax 'map' final pixel x-coord -- screen pixel size) == 1/3 * (real map final pixel x-coord -- screen pixel size) Then the script would work as intended, I think...? Alternatively, you want to work out the actual ratio of sizes RATIO as follows: RATIO:= (parallax 'map' final pixel x-coord -- screen pixel size) / (real map final pixel x-coord -- screen pixel size) and then use this RATIO in your script instead of 1/3 This all looks correct. And to be honest it hadn't occurred to me that the screen size matters (it applies only for one of the two types of parallax layers). But if fact you don't really need to worry about correcting for the size of the screen, you just need to draw a large enough corner of the map layer (a bit more than a third). Yeah, I realized I could just add 6 rows and 10 columns to my background layer to make this work the easy way, but I really wanted to figure out how to make it work when the background layer is exactly 1/3 the size of the map. I imagine that the real reason that your script isn't working is that the map root slice is placed at (-camera x, -camera y) relative to the screen, so to get the map layer to display at (camera x/3, camera y/3), you actually need to place it at offset (camera x * 2/3, camera y * 2/3) relative to the map root. Yes, absolutely right. I actually should have posted the version of that script where I was doing: camera pixel x -- camera pixel x / 3 That is as close as I got to making it work right :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] The parallax problem
On 7 June 2011 12:04, James Paige b...@hamsterrepublic.com wrote: On Tue, Jun 07, 2011 at 11:39:51AM +1200, Ralph Versteegen wrote: On 7 June 2011 07:45, James Paige b...@hamsterrepublic.com wrote: On Mon, Jun 06, 2011 at 03:23:26PM -0400, Mike Willis wrote: So I don't know how to reply on those archives, but here is the crux of the parallax problem I think: You want the x coordinate of the top left of the screen to be the dividing factor, NOT the tiles. In other words, you don't want (parallax 'map' final tile x-coord) == 1/3 * (real map final tile x-coord) I haven't used tile coordinates for anything. pixel coordinates only. You want (parallax 'map' final pixel x-coord -- screen pixel size) == 1/3 * (real map final pixel x-coord -- screen pixel size) Then the script would work as intended, I think...? Alternatively, you want to work out the actual ratio of sizes RATIO as follows: RATIO:= (parallax 'map' final pixel x-coord -- screen pixel size) / (real map final pixel x-coord -- screen pixel size) and then use this RATIO in your script instead of 1/3 This all looks correct. And to be honest it hadn't occurred to me that the screen size matters (it applies only for one of the two types of parallax layers). But if fact you don't really need to worry about correcting for the size of the screen, you just need to draw a large enough corner of the map layer (a bit more than a third). Yeah, I realized I could just add 6 rows and 10 columns to my background layer to make this work the easy way, but I really wanted to figure out how to make it work when the background layer is exactly 1/3 the size of the map. I imagine that the real reason that your script isn't working is that the map root slice is placed at (-camera x, -camera y) relative to the screen, so to get the map layer to display at (camera x/3, camera y/3), you actually need to place it at offset (camera x * 2/3, camera y * 2/3) relative to the map root. Yes, absolutely right. I actually should have posted the version of that script where I was doing: camera pixel x -- camera pixel x / 3 That is as close as I got to making it work right :) --- James So, is the problem solved now? ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
