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 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
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
