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 Caron<caron.m...@gmail.com> wrote: > >> >>>> > >> >>>> On 6/7/2011 19:49, Ralph Versteegen wrote: > >> >>>>> > >> >>>>> 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. > >> >>>> > >> >>>> 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 _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
