Re: [Ohrrpgce] No, THIS is how Parallax should work
On 30 May 2011 11:13, James Paige wrote: > On Sat, May 28, 2011 at 11:29:12PM +1200, Ralph Versteegen wrote: >> The plotscript interface for parallaxing map layer 0 could be as simple >> as: >> >> parallax map layer(layer number, width, height) >> >> And the rest could happen internally through fairly simple magic. >> >> This would assume that the layer you want to parallax has tiles only in >> the upper left width x height tiles, and that tiles outside that range >> wouldn't show up through normal scrolling. >> >> I have to disagree with this. I don't see any reason for such a >> command: it would allow changing map layer size dynamically, and why >> would we want to go to all that trouble? Now a script command to >> adjust the parallax scrolling multiplier, sure, but this is a terribly >> crude command. > > Yes, now that we have been discussing parallax as a built-in feature > more, I am inclined to agree that my "parallax map layer" script command > is probably a bad idea. If i want to do parallax soon, I can script the > map layer movement manually. I retract the suggestion for this > particular command. > >> >>> Wrapping can be handled the same way as normal map wrapping, but the >> >>> game maker needs to ensure that it wraps properly (just like with any >> >>> other map layer). >> >> (Speaking of which, I will add camera wrapping to the map editor) > > This reminds me: I would love to merge the ~ minimap and the TAB > map-scale-box Yes, definitely. It's far less useful than it should be. (Though in the zone editor the TAB box is actually useful). Incidentally, that's one of the things I would love to have multiple windows for (or at least increasing the window size, so that there's room to draw such things off to the side.) >> >> parallax map layer(0, 50, 20) >> >> >> >> The rightmost 100 columns and bottommost 40 rows of tiles would be >> >> discarded. >> > >> > Okay, I understand. I don't know whether this would be useful to do at >> > runtime (as opposed to creating the layers in Custom and just hiding >> > them until needed), but again, I'm sure there would be cases. >> >> We don't need this command... > > Yes I am convinced. > >> ...However, you should be able to set the >> scroll multipliers and automatic scrolling velocity by script. This >> would allow turning type 1 paralayers into type 1 or vice versa, and Opps, I meant to say "allow turning type 1 paralayers into type 2 or vice versa". >> also regular layers into type 1, and there's no problem with that. >> Also I think you should be able to do manual parallax by moving layer >> slices, like James did in his first script. > > Yes. I like that better. > >> >>> - Maybe allow other maps to be used as paralayers? That would handily >> >>> solve the editor problem, at the expense of having to wrangle multiple >> >>> maps at once. Also, would the NPCs on the parallaxed map be meaningful, >> >>> etc? >> >> >> >> Hmmm... that has an elegance to it... and simplifies the editor >> >> implementation... but I am still wary. I definitely would not want to >> >> have to deal with two different map's NPCs simultaneously (or 8 >> >> different maps NPCs simultaneously) >> > >> > Well, I was /kind/ of joking about the NPCs :) Obviously, thinks like >> > wallmaps would be irrelevant. >> > >> > But, an interesting use case could be an area with multiple floors, >> > like the cave in Final Fantasy 4 where Rydia stays: You can see the >> > lower floor scrolling beneath you as you walk around. In this case, >> > you wouldn't need to reproduce the other floor, you could just add the >> > map itself! >> > >> > Just some thoughts... >> > >> > -- >> > Mike Caron >> >> James suggested loading multiple maps at once long ago, and I've been >> thinking about it ever since. Loading/keeping just tilemaps from >> another map is the simplest special case of this, and I think it's >> doable without too much major reorganisation. > > Oh, I think I do remember that. I was thinking about split-screen where > each half is showing a different map... but I kinda forgot about that > idea. I think that one falls into the category of a "cool" idea that > isn't actually needed. Yes, and it would be a lot of work: it would require a huge amount of reorganisation of all map, hero and NPC related code and raises lots of problems for how scripts would deal with the different maps simultaneously. On the other hand, allowing you to load (or hang onto) tilemaps from other maps requires just that the TileMap (and tileset) become reference counted objects (probably managed by the new script interpreter) which MapLayer slices and scripts can hold references to. But I'm not arguing that that's a needed feature either :) >> In another map engine (ika) I saw that individual TileLayer objects >> can be loaded, manipulated, and drawn by scripts independently of any >> associated maps (in my recollection). I think this is a great idea, >>
Re: [Ohrrpgce] No, THIS is how Parallax should work
On Sat, May 28, 2011 at 11:29:12PM +1200, Ralph Versteegen wrote: > The plotscript interface for parallaxing map layer 0 could be as simple > as: > > parallax map layer(layer number, width, height) > > And the rest could happen internally through fairly simple magic. > > This would assume that the layer you want to parallax has tiles only in > the upper left width x height tiles, and that tiles outside that range > wouldn't show up through normal scrolling. > > I have to disagree with this. I don't see any reason for such a > command: it would allow changing map layer size dynamically, and why > would we want to go to all that trouble? Now a script command to > adjust the parallax scrolling multiplier, sure, but this is a terribly > crude command. Yes, now that we have been discussing parallax as a built-in feature more, I am inclined to agree that my "parallax map layer" script command is probably a bad idea. If i want to do parallax soon, I can script the map layer movement manually. I retract the suggestion for this particular command. > >>> Wrapping can be handled the same way as normal map wrapping, but the > >>> game maker needs to ensure that it wraps properly (just like with any > >>> other map layer). > > (Speaking of which, I will add camera wrapping to the map editor) This reminds me: I would love to merge the ~ minimap and the TAB map-scale-box > >> parallax map layer(0, 50, 20) > >> > >> The rightmost 100 columns and bottommost 40 rows of tiles would be > >> discarded. > > > > Okay, I understand. I don't know whether this would be useful to do at > > runtime (as opposed to creating the layers in Custom and just hiding > > them until needed), but again, I'm sure there would be cases. > > We don't need this command... Yes I am convinced. > ...However, you should be able to set the > scroll multipliers and automatic scrolling velocity by script. This > would allow turning type 1 paralayers into type 1 or vice versa, and > also regular layers into type 1, and there's no problem with that. > Also I think you should be able to do manual parallax by moving layer > slices, like James did in his first script. Yes. I like that better. > >>> - Maybe allow other maps to be used as paralayers? That would handily > >>> solve the editor problem, at the expense of having to wrangle multiple > >>> maps at once. Also, would the NPCs on the parallaxed map be meaningful, > >>> etc? > >> > >> Hmmm... that has an elegance to it... and simplifies the editor > >> implementation... but I am still wary. I definitely would not want to > >> have to deal with two different map's NPCs simultaneously (or 8 > >> different maps NPCs simultaneously) > > > > Well, I was /kind/ of joking about the NPCs :) Obviously, thinks like > > wallmaps would be irrelevant. > > > > But, an interesting use case could be an area with multiple floors, > > like the cave in Final Fantasy 4 where Rydia stays: You can see the > > lower floor scrolling beneath you as you walk around. In this case, > > you wouldn't need to reproduce the other floor, you could just add the > > map itself! > > > > Just some thoughts... > > > > -- > > Mike Caron > > James suggested loading multiple maps at once long ago, and I've been > thinking about it ever since. Loading/keeping just tilemaps from > another map is the simplest special case of this, and I think it's > doable without too much major reorganisation. Oh, I think I do remember that. I was thinking about split-screen where each half is showing a different map... but I kinda forgot about that idea. I think that one falls into the category of a "cool" idea that isn't actually needed. > In another map engine (ika) I saw that individual TileLayer objects > can be loaded, manipulated, and drawn by scripts independently of any > associated maps (in my recollection). I think this is a great idea, > for example you could create a temporary 3x3 tilemap and use it to > paste trees all over a map, or randomly generate multiple dungeon > levels at once, lining up the pits and stairs. > > This, along with the parallax and resolution independence stuff, are > the reasons I also want to remove the minimum 16x10 map size limit. I believe I may have argued against tilemaps smaller than 16x10 at some point back in the past, but I now think any objections I might have had to them were silly. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] No, THIS is how Parallax should work
On 25 May 2011 05:44, Mike Caron wrote: > On Tue, May 24, 2011 at 12:46 PM, James Paige > wrote: >> On Tue, May 24, 2011 at 01:06:26AM -0400, Mike Caron wrote: >>> On 5/24/2011 0:21, James Paige wrote: Okay, so eventually, it would be cool if we could allow certain map layers to have a size that is different than the map size, and they would automatically parallax scroll. Oh good, saved me from raising these complaints! Completely implementing that will be pretty tricky, because of the map file format changes that would have to be implemented, and the complexity of making the map editor handle layers of different sizes. The file format for map layers is going to be pretty simple. The question is whether this "file" should be a separate lump, or a node in a single RELOAD document for the whole map. However, on the map display side of things in game, the implementation would actually be pretty simple and straightforward. The plotscript interface for parallaxing map layer 0 could be as simple as: parallax map layer(layer number, width, height) And the rest could happen internally through fairly simple magic. This would assume that the layer you want to parallax has tiles only in the upper left width x height tiles, and that tiles outside that range wouldn't show up through normal scrolling. I have to disagree with this. I don't see any reason for such a command: it would allow changing map layer size dynamically, and why would we want to go to all that trouble? Now a script command to adjust the parallax scrolling multiplier, sure, but this is a terribly crude command. Of course this wouldn't automatically handle wrapping... actually I am not sure what to think about parallax on a wrapping map... I don't think wrapping map layers will be much of an issue. >>> The way I see it, there are two kinds of parallaxing effects one might >>> want to use: >>> >>> 1. The "treetop" kind. The parallaxing layers (hence forth, the >>> "paralayer") are relatively small, but tile to fill up the screen. Some >>> times, they have a constant movement vector (clouds), sometimes they >>> scroll with the camera (leaves), sometimes they do both (rain). However, >>> in all cases, they don't need more than a screen's worth of graphics. Opps, I had not realised that layer_width / x_scrolling_speed_multiplier = map_width was not a requirement for these uses of parallax. Hmm, that makes things trickier in the map editor, because there really will have to be two kinds of parallax layers. >>> Wrapping is irrelevant, as the paralayer's location is not tied the >>> camera's location. >> >> Ah, interesting. I had only been thinking of type 2, I had neglected >> thinking about type 1. >> >>> 2. The "scenic background" kind. The paralayer never scrolls >>> automatically, and always scrolls at a fixed multiplier to the camera >>> speed. This is when the graphics on the paralayer are supposed to >>> correspond to graphics on other layers. A classic example is a cliff >>> with a castle or something in the background that only reveals itself >>> when the camera pans up. >>> >>> The size of the paralayer is directly proportional to the movement speed >>> multiplier. If the paralayer moves twice as fast as the camera, then it >>> needs to be twice as big (along each axis). >> >> I was thinking you would only specify the size of the paralayer, and >> then it would automatically figure out the correct movement speed... but >> this would only work for a background layer that is smaller than the map >> size. It would not work for a foreground layer that is smaller than the >> map size, like the type 1 "forest" layer you described above. > > Type 1 isn't necessarily foreground. A Link to the Past, for example, > uses such a layer on Death Mountain in the Dark World to do lavafloes > in certain places by having the lava in the background scroll, and > having rocks and such in the foreground with transparent areas, making > it look like the lava is coming from the rocks. > > The defining feature of Type 1 is that it doesn't really have a size > -- for all intents and purposes, it's unbounded. > > Anyway, as long as you allow for speeds < 1.0, then there shouldn't be > a problem supporting layers of any size: > > Consider a base map of size 64x64. A paralayer of this size will have > a scroll factor of 1. Now, consider a paralayer that's 32x32. This > layer will scroll at a speed of 0.5 (slower). A third paralayer, > 128x128, would scroll at a speed of 2 (faster). > > Essentially, as long as the layers scroll such that each edge lines up > when the camera is 1/2 screen distance away from that side of the map, > it should be okay. > >>> Wrapping can be handled the same way as normal map wrapping, but the >>> game maker needs to ensure that it wraps properly (just like with any >>> other map layer). (Speaking of which, I will add camera wra
Re: [Ohrrpgce] No, THIS is how Parallax should work
On Tue, May 24, 2011 at 12:46 PM, James Paige wrote: > On Tue, May 24, 2011 at 01:06:26AM -0400, Mike Caron wrote: >> On 5/24/2011 0:21, James Paige wrote: >>> Okay, so eventually, it would be cool if we could allow certain map >>> layers to have a size that is different than the map size, and they >>> would automatically parallax scroll. >>> >>> Completely implementing that will be pretty tricky, because of the map >>> file format changes that would have to be implemented, and the >>> complexity of making the map editor handle layers of different sizes. >>> >>> However, on the map display side of things in game, the implementation >>> would actually be pretty simple and straightforward. >>> >>> The plotscript interface for parallaxing map layer 0 could be as simple >>> as: >>> >>> parallax map layer(layer number, width, height) >>> >>> And the rest could happen internally through fairly simple magic. >>> >>> This would assume that the layer you want to parallax has tiles only in >>> the upper left width x height tiles, and that tiles outside that range >>> wouldn't show up through normal scrolling. >>> >>> Of course this wouldn't automatically handle wrapping... actually I am >>> not sure what to think about parallax on a wrapping map... >> >> The way I see it, there are two kinds of parallaxing effects one might >> want to use: >> >> 1. The "treetop" kind. The parallaxing layers (hence forth, the >> "paralayer") are relatively small, but tile to fill up the screen. Some >> times, they have a constant movement vector (clouds), sometimes they >> scroll with the camera (leaves), sometimes they do both (rain). However, >> in all cases, they don't need more than a screen's worth of graphics. >> >> Wrapping is irrelevant, as the paralayer's location is not tied the >> camera's location. > > Ah, interesting. I had only been thinking of type 2, I had neglected > thinking about type 1. > >> 2. The "scenic background" kind. The paralayer never scrolls >> automatically, and always scrolls at a fixed multiplier to the camera >> speed. This is when the graphics on the paralayer are supposed to >> correspond to graphics on other layers. A classic example is a cliff >> with a castle or something in the background that only reveals itself >> when the camera pans up. >> >> The size of the paralayer is directly proportional to the movement speed >> multiplier. If the paralayer moves twice as fast as the camera, then it >> needs to be twice as big (along each axis). > > I was thinking you would only specify the size of the paralayer, and > then it would automatically figure out the correct movement speed... but > this would only work for a background layer that is smaller than the map > size. It would not work for a foreground layer that is smaller than the > map size, like the type 1 "forest" layer you described above. Type 1 isn't necessarily foreground. A Link to the Past, for example, uses such a layer on Death Mountain in the Dark World to do lavafloes in certain places by having the lava in the background scroll, and having rocks and such in the foreground with transparent areas, making it look like the lava is coming from the rocks. The defining feature of Type 1 is that it doesn't really have a size -- for all intents and purposes, it's unbounded. Anyway, as long as you allow for speeds < 1.0, then there shouldn't be a problem supporting layers of any size: Consider a base map of size 64x64. A paralayer of this size will have a scroll factor of 1. Now, consider a paralayer that's 32x32. This layer will scroll at a speed of 0.5 (slower). A third paralayer, 128x128, would scroll at a speed of 2 (faster). Essentially, as long as the layers scroll such that each edge lines up when the camera is 1/2 screen distance away from that side of the map, it should be okay. >> Wrapping can be handled the same way as normal map wrapping, but the >> game maker needs to ensure that it wraps properly (just like with any >> other map layer). > > Yeah... that seems sensible. I think the map drawing code would already > be capable of drawing some layers wrapping even if the rest of the map > was not wrapping. > >> -- >> >> While I think that it would be possible to unify the two kinds, I wonder >> if it is necessary? I remember way back (circa 2006ish) having a >> discussion about the first kind of parallaxing, using Backdrops as the >> graphics. I guess that it would be pretty easy to simulate it with a >> slice and some scripting, so I guess we can ignore it. >> >> The second kind would be a bit more difficult, so it should definitely >> get engine support. >> >> I don't think that the editor should need to support editing multiple >> layer sizes: It would get very messy and confusing (for everyone >> involved) if two layers were not tile-aligned, for example. > > I was thinking the editor could just align itself with the layer you > were currently working on. Right, but if the scroll factor is not a whole number, then
Re: [Ohrrpgce] No, THIS is how Parallax should work
On Tue, May 24, 2011 at 01:06:26AM -0400, Mike Caron wrote: > On 5/24/2011 0:21, James Paige wrote: >> Okay, so eventually, it would be cool if we could allow certain map >> layers to have a size that is different than the map size, and they >> would automatically parallax scroll. >> >> Completely implementing that will be pretty tricky, because of the map >> file format changes that would have to be implemented, and the >> complexity of making the map editor handle layers of different sizes. >> >> However, on the map display side of things in game, the implementation >> would actually be pretty simple and straightforward. >> >> The plotscript interface for parallaxing map layer 0 could be as simple >> as: >> >>parallax map layer(layer number, width, height) >> >> And the rest could happen internally through fairly simple magic. >> >> This would assume that the layer you want to parallax has tiles only in >> the upper left width x height tiles, and that tiles outside that range >> wouldn't show up through normal scrolling. >> >> Of course this wouldn't automatically handle wrapping... actually I am >> not sure what to think about parallax on a wrapping map... > > The way I see it, there are two kinds of parallaxing effects one might > want to use: > > 1. The "treetop" kind. The parallaxing layers (hence forth, the > "paralayer") are relatively small, but tile to fill up the screen. Some > times, they have a constant movement vector (clouds), sometimes they > scroll with the camera (leaves), sometimes they do both (rain). However, > in all cases, they don't need more than a screen's worth of graphics. > > Wrapping is irrelevant, as the paralayer's location is not tied the > camera's location. Ah, interesting. I had only been thinking of type 2, I had neglected thinking about type 1. > 2. The "scenic background" kind. The paralayer never scrolls > automatically, and always scrolls at a fixed multiplier to the camera > speed. This is when the graphics on the paralayer are supposed to > correspond to graphics on other layers. A classic example is a cliff > with a castle or something in the background that only reveals itself > when the camera pans up. > > The size of the paralayer is directly proportional to the movement speed > multiplier. If the paralayer moves twice as fast as the camera, then it > needs to be twice as big (along each axis). I was thinking you would only specify the size of the paralayer, and then it would automatically figure out the correct movement speed... but this would only work for a background layer that is smaller than the map size. It would not work for a foreground layer that is smaller than the map size, like the type 1 "forest" layer you described above. > Wrapping can be handled the same way as normal map wrapping, but the > game maker needs to ensure that it wraps properly (just like with any > other map layer). Yeah... that seems sensible. I think the map drawing code would already be capable of drawing some layers wrapping even if the rest of the map was not wrapping. > -- > > While I think that it would be possible to unify the two kinds, I wonder > if it is necessary? I remember way back (circa 2006ish) having a > discussion about the first kind of parallaxing, using Backdrops as the > graphics. I guess that it would be pretty easy to simulate it with a > slice and some scripting, so I guess we can ignore it. > > The second kind would be a bit more difficult, so it should definitely > get engine support. > > I don't think that the editor should need to support editing multiple > layer sizes: It would get very messy and confusing (for everyone > involved) if two layers were not tile-aligned, for example. I was thinking the editor could just align itself with the layer you were currently working on. > Instead, editing a paralayer should take place in its own map editor > with only the paralayer visible. That does seem simpler. > To make editing easier, there could be a paralayer preview that /did/ > allow the maker to scroll around the map and make sure everything was > okay. > > Other random thoughts that I'm not sure how to put in prose format since > it's 1:00 am and I have to be up at 6:30 am: > > - Since the scroll speed and the required paralayer size are directly > related, setting one should also set the other. Yes, usually. Maybe the case where the paralayer size and scroll speed are directly related is the only case we want to handle as a built-in feature? > - Because of this, I don't think allowing a script to parallaxize an > existing layer would be useful. It would, in effect, either create a > paralayer with the wrong dimensions (either it will need to draw the > blank area past the edge of the map, or some will never be seen [which > would wreak havoc with wrapping!]), or create paralayer with a 1:1 > scroll ratio, which is pointless I was thinking that if you did:
Re: [Ohrrpgce] No, THIS is how Parallax should work
On 5/24/2011 0:21, James Paige wrote: Okay, so eventually, it would be cool if we could allow certain map layers to have a size that is different than the map size, and they would automatically parallax scroll. Completely implementing that will be pretty tricky, because of the map file format changes that would have to be implemented, and the complexity of making the map editor handle layers of different sizes. However, on the map display side of things in game, the implementation would actually be pretty simple and straightforward. The plotscript interface for parallaxing map layer 0 could be as simple as: parallax map layer(layer number, width, height) And the rest could happen internally through fairly simple magic. This would assume that the layer you want to parallax has tiles only in the upper left width x height tiles, and that tiles outside that range wouldn't show up through normal scrolling. Of course this wouldn't automatically handle wrapping... actually I am not sure what to think about parallax on a wrapping map... The way I see it, there are two kinds of parallaxing effects one might want to use: 1. The "treetop" kind. The parallaxing layers (hence forth, the "paralayer") are relatively small, but tile to fill up the screen. Some times, they have a constant movement vector (clouds), sometimes they scroll with the camera (leaves), sometimes they do both (rain). However, in all cases, they don't need more than a screen's worth of graphics. Wrapping is irrelevant, as the paralayer's location is not tied the camera's location. 2. The "scenic background" kind. The paralayer never scrolls automatically, and always scrolls at a fixed multiplier to the camera speed. This is when the graphics on the paralayer are supposed to correspond to graphics on other layers. A classic example is a cliff with a castle or something in the background that only reveals itself when the camera pans up. The size of the paralayer is directly proportional to the movement speed multiplier. If the paralayer moves twice as fast as the camera, then it needs to be twice as big (along each axis). Wrapping can be handled the same way as normal map wrapping, but the game maker needs to ensure that it wraps properly (just like with any other map layer). -- While I think that it would be possible to unify the two kinds, I wonder if it is necessary? I remember way back (circa 2006ish) having a discussion about the first kind of parallaxing, using Backdrops as the graphics. I guess that it would be pretty easy to simulate it with a slice and some scripting, so I guess we can ignore it. The second kind would be a bit more difficult, so it should definitely get engine support. I don't think that the editor should need to support editing multiple layer sizes: It would get very messy and confusing (for everyone involved) if two layers were not tile-aligned, for example. Instead, editing a paralayer should take place in its own map editor with only the paralayer visible. To make editing easier, there could be a paralayer preview that /did/ allow the maker to scroll around the map and make sure everything was okay. Other random thoughts that I'm not sure how to put in prose format since it's 1:00 am and I have to be up at 6:30 am: - Since the scroll speed and the required paralayer size are directly related, setting one should also set the other. - Because of this, I don't think allowing a script to parallaxize an existing layer would be useful. It would, in effect, either create a paralayer with the wrong dimensions (either it will need to draw the blank area past the edge of the map, or some will never be seen [which would wreak havoc with wrapping!]), or create paralayer with a 1:1 scroll ratio, which is pointless - Maybe allow other maps to be used as paralayers? That would handily solve the editor problem, at the expense of having to wrangle multiple maps at once. Also, would the NPCs on the parallaxed map be meaningful, etc? - Otherwise, the paralayers can be stored as additional blobs of tilemap data. - etc -- - Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] No, THIS is how Parallax should work
Okay, so eventually, it would be cool if we could allow certain map layers to have a size that is different than the map size, and they would automatically parallax scroll. Completely implementing that will be pretty tricky, because of the map file format changes that would have to be implemented, and the complexity of making the map editor handle layers of different sizes. However, on the map display side of things in game, the implementation would actually be pretty simple and straightforward. The plotscript interface for parallaxing map layer 0 could be as simple as: parallax map layer(layer number, width, height) And the rest could happen internally through fairly simple magic. This would assume that the layer you want to parallax has tiles only in the upper left width x height tiles, and that tiles outside that range wouldn't show up through normal scrolling. Of course this wouldn't automatically handle wrapping... actually I am not sure what to think about parallax on a wrapping map... --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
