Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualSuperVGA

Posted 07 January 2013 - 08:00 AM


While you can still change things around, try picturing these layers, scrolling at different speeds, being drawn on the top of oneanother. If you could fit any size graphic in any of the layers, like a simplistic jigsaw puzzle, I'm sure you'll find it very flexible. This is the representation i suggest (I'm imagining it written in XML in a file, but it could be any data structure, really.)

<!-- level_00.gfx -->
<layer level="-2" parallax="1.05">
 <sprite file="somesprite.png" position="0, 128" />
 <sprite file="anothersprite.png" position="32, 0" />
</layer>
<layer level="0" parallax="1.0">
 <sprite file="graffiti.png" position="96, 64" />
 <sprite file="vine.png" position="8, 16" />
</layer>
<layer level="1" parallax="-1.3">
 <sprite file="somesprite.png" position="480, 64" />
 <sprite file="anothersprite.png" position="128, 16" />
</layer>
You could have more strict tile layouts and/or collision information defined elsewhere.
Layers -n..-1 could be painted before the basic level layout, and layers 1..n on the top of.
The layers would each be offset by scroll * layer.parallax when drawn.
It's only a suggestion, -it will still take a slightly more refined editor, but I think it could make you more productive later on.


Huh, I missed your post the first time. data structure type to use isn't really my concern, as you said, any data structure would do.
Your definition here though got me thinking - one, I've been wondering whether to allow for different parallax amounts for different sprites, or whether to have just 1 parallaxed layer of images behind the main level display. I'm not a fan of layers that show up in front of the main level, cause they usually just get in the way. 
What's interesting in your definition - I suppose the position is the position of the object relative to the level's 0,0 - and that when the view is centered on 0,0, those background objects should appear at that given position. I think i can picture how to handle this in my head right now. I don't know if what i said made sense, but it's helped me at least.


smile.png That's the main point! I'm glad I could help! Anyways, i guess if the position of the parallax layers are scaled, the level may fall short of parallax level space (the landscape layer being a total of 1600x128 should cover a level that's 3000x2048), and as such it might be nice to have the layers wrap around, one you reach the end of a fast-scrolling layer, ex.
if(seen_layer.offset + seen_layer.visible_size.x > actual_layer.width)
{
   seen_layer.offset = seen_layer.offset % actual_layer.width;
}
Again, this is more meant as pseudocode, but the point is that you might want to recycle layers that are repetative, or scroll really fast.
Is for the foreground thing, me neither, but some games have managed to implement this in a way that doesn't become too annoying. (fast scrolling, so a small movement on the "action" layer results in the disappearance of the obstructing layer, few occurrances etc.)
These are screenshots from Claw and DKC. Claw has these pillars obscuring the player, and DKC has chains hanging down in front of the "action" layer. It can be done in an unintrusive fashion IMO, but it's probably a matter of taste.

#4SuperVGA

Posted 07 January 2013 - 08:00 AM


While you can still change things around, try picturing these layers, scrolling at different speeds, being drawn on the top of oneanother. If you could fit any size graphic in any of the layers, like a simplistic jigsaw puzzle, I'm sure you'll find it very flexible. This is the representation i suggest (I'm imagining it written in XML in a file, but it could be any data structure, really.)

<!-- level_00.gfx -->
<layer level="-2" parallax="1.05">
 <sprite file="somesprite.png" position="0, 128" />
 <sprite file="anothersprite.png" position="32, 0" />
</layer>
<layer level="0" parallax="1.0">
 <sprite file="graffiti.png" position="96, 64" />
 <sprite file="vine.png" position="8, 16" />
</layer>
<layer level="1" parallax="-1.3">
 <sprite file="somesprite.png" position="480, 64" />
 <sprite file="anothersprite.png" position="128, 16" />
</layer>
You could have more strict tile layouts and/or collision information defined elsewhere.
Layers -n..-1 could be painted before the basic level layout, and layers 1..n on the top of.
The layers would each be offset by scroll * layer.parallax when drawn.
It's only a suggestion, -it will still take a slightly more refined editor, but I think it could make you more productive later on.
 
 
 
 


 
Huh, I missed your post the first time. data structure type to use isn't really my concern, as you said, any data structure would do.
Your definition here though got me thinking - one, I've been wondering whether to allow for different parallax amounts for different sprites, or whether to have just 1 parallaxed layer of images behind the main level display. I'm not a fan of layers that show up in front of the main level, cause they usually just get in the way. 
What's interesting in your definition - I suppose the position is the position of the object relative to the level's 0,0 - and that when the view is centered on 0,0, those background objects should appear at that given position. I think i can picture how to handle this in my head right now. I don't know if what i said made sense, but it's helped me at least.
 
 
 
 


smile.png That's the main point! Anyways, i guess if the position of the parallax layers are scaled, the level may fall short of parallax level space (the landscape layer being a total of 1600x128 should cover a level that's 3000x2048), and as such it might be nice to have the layers wrap around, one you reach the end of a fast-scrolling layer, ex.
if(seen_layer.offset + seen_layer.visible_size.x > actual_layer.width)
{
   seen_layer.offset = seen_layer.offset % actual_layer.width;
}
Again, this is more meant as pseudocode, but the point is that you might want to recycle layers that are repetative, or scroll really fast.
Is for the foreground thing, me neither, but some games have managed to implement this in a way that doesn't become too annoying. (fast scrolling, so a small movement on the "action" layer results in the disappearance of the obstructing layer, few occurrances etc.)
These are screenshots from Claw and DKC. Claw has these pillars obscuring the player, and DKC has chains hanging down in front of the "action" layer. It can be done in an unintrusive fashion IMO, but it's probably a matter of taste.

#3SuperVGA

Posted 07 January 2013 - 07:58 AM


While you can still change things around, try picturing these layers, scrolling at different speeds, being drawn on the top of oneanother. If you could fit any size graphic in any of the layers, like a simplistic jigsaw puzzle, I'm sure you'll find it very flexible. This is the representation i suggest (I'm imagining it written in XML in a file, but it could be any data structure, really.)

<!-- level_00.gfx -->
<layer level="-2" parallax="1.05">
 <sprite file="somesprite.png" position="0, 128" />
 <sprite file="anothersprite.png" position="32, 0" />
</layer>
<layer level="0" parallax="1.0">
 <sprite file="graffiti.png" position="96, 64" />
 <sprite file="vine.png" position="8, 16" />
</layer>
<layer level="1" parallax="-1.3">
 <sprite file="somesprite.png" position="480, 64" />
 <sprite file="anothersprite.png" position="128, 16" />
</layer>
You could have more strict tile layouts and/or collision information defined elsewhere.
Layers -n..-1 could be painted before the basic level layout, and layers 1..n on the top of.
The layers would each be offset by scroll * layer.parallax when drawn.
It's only a suggestion, -it will still take a slightly more refined editor, but I think it could make you more productive later on.
 
 
 


 
Huh, I missed your post the first time. data structure type to use isn't really my concern, as you said, any data structure would do.
Your definition here though got me thinking - one, I've been wondering whether to allow for different parallax amounts for different sprites, or whether to have just 1 parallaxed layer of images behind the main level display. I'm not a fan of layers that show up in front of the main level, cause they usually just get in the way. 
What's interesting in your definition - I suppose the position is the position of the object relative to the level's 0,0 - and that when the view is centered on 0,0, those background objects should appear at that given position. I think i can picture how to handle this in my head right now. I don't know if what i said made sense, but it's helped me at least.
 
 
 


smile.png That's the main point! Anyways, i guess if the position of the parallax layers are scaled, the level may fall short of parallax levels, and as such it might be nice to have the layers wrap around, one you reach the end of a fast-scrolling layer, ex.
if(seen_layer.offset + seen_layer.visible_size.x > actual_layer.width)
{
   seen_layer.offset = seen_layer.offset % actual_layer.width;
}
Again, this is more meant as pseudocode, but the point is that you might want to recycle layers that are repetative, or scroll really fast.
Is for the foreground thing, me neither, but some games have managed to implement this in a way that doesn't become too annoying. (fast scrolling, so a small movement on the "action" layer results in the disappearance of the obstructing layer, few occurrances etc.)
These are screenshots from Claw and DKC. Claw has these pillars obscuring the player, and DKC has chains hanging down in front of the "action" layer. It can be done in an unintrusive fashion IMO, but it's probably a matter of taste.

#2SuperVGA

Posted 07 January 2013 - 07:57 AM


While you can still change things around, try picturing these layers, scrolling at different speeds, being drawn on the top of oneanother. If you could fit any size graphic in any of the layers, like a simplistic jigsaw puzzle, I'm sure you'll find it very flexible. This is the representation i suggest (I'm imagining it written in XML in a file, but it could be any data structure, really.)

<!-- level_00.gfx -->
<layer level="-2" parallax="1.05">
 <sprite file="somesprite.png" position="0, 128" />
 <sprite file="anothersprite.png" position="32, 0" />
</layer>
<layer level="0" parallax="1.0">
 <sprite file="graffiti.png" position="96, 64" />
 <sprite file="vine.png" position="8, 16" />
</layer>
<layer level="1" parallax="-1.3">
 <sprite file="somesprite.png" position="480, 64" />
 <sprite file="anothersprite.png" position="128, 16" />
</layer>
You could have more strict tile layouts and/or collision information defined elsewhere.
Layers -n..-1 could be painted before the basic level layout, and layers 1..n on the top of.
The layers would each be offset by scroll * layer.parallax when drawn.
It's only a suggestion, -it will still take a slightly more refined editor, but I think it could make you more productive later on.
 
 


 
Huh, I missed your post the first time. data structure type to use isn't really my concern, as you said, any data structure would do.
Your definition here though got me thinking - one, I've been wondering whether to allow for different parallax amounts for different sprites, or whether to have just 1 parallaxed layer of images behind the main level display. I'm not a fan of layers that show up in front of the main level, cause they usually just get in the way. 
What's interesting in your definition - I suppose the position is the position of the object relative to the level's 0,0 - and that when the view is centered on 0,0, those background objects should appear at that given position. I think i can picture how to handle this in my head right now. I don't know if what i said made sense, but it's helped me at least.
 
 


smile.png That's the main point! Anyways, i guess if the position of the parallax layers are scaled, the level may fall short of parallax levels, and as such it might be nice to have the layers wrap around, one you reach the end of a fast-scrolling layer, ex.
if(seen_layer.offset + seen_layer.visible_size.x > actual_layer.width)
{
   seen_layer.offset = seen_layer.offset % actual_layer.width;
}
Again, this is more meant as pseudocode, but the point is that you might want to recycle layers that are repetative, or scroll really fast.
Is for the foreground thing, me neither, but some games have managed to implement this in a way that doesn't become too annoying. (fast scrolling, so a small movement on the "action" layer results in the disappearance of the obstructing layer, few occurrances etc.)

#1SuperVGA

Posted 07 January 2013 - 07:56 AM


While you can still change things around, try picturing these layers, scrolling at different speeds, being drawn on the top of oneanother. If you could fit any size graphic in any of the layers, like a simplistic jigsaw puzzle, I'm sure you'll find it very flexible. This is the representation i suggest (I'm imagining it written in XML in a file, but it could be any data structure, really.)

<!-- level_00.gfx -->
<layer level="-2" parallax="1.05">
 <sprite file="somesprite.png" position="0, 128" />
 <sprite file="anothersprite.png" position="32, 0" />
</layer>
<layer level="0" parallax="1.0">
 <sprite file="graffiti.png" position="96, 64" />
 <sprite file="vine.png" position="8, 16" />
</layer>
<layer level="1" parallax="-1.3">
 <sprite file="somesprite.png" position="480, 64" />
 <sprite file="anothersprite.png" position="128, 16" />
</layer>
You could have more strict tile layouts and/or collision information defined elsewhere.
Layers -n..-1 could be painted before the basic level layout, and layers 1..n on the top of.
The layers would each be offset by scroll * layer.parallax when drawn.
It's only a suggestion, -it will still take a slightly more refined editor, but I think it could make you more productive later on.


 
Huh, I missed your post the first time. data structure type to use isn't really my concern, as you said, any data structure would do.
Your definition here though got me thinking - one, I've been wondering whether to allow for different parallax amounts for different sprites, or whether to have just 1 parallaxed layer of images behind the main level display. I'm not a fan of layers that show up in front of the main level, cause they usually just get in the way. 
What's interesting in your definition - I suppose the position is the position of the object relative to the level's 0,0 - and that when the view is centered on 0,0, those background objects should appear at that given position. I think i can picture how to handle this in my head right now. I don't know if what i said made sense, but it's helped me at least.


smile.png That's the main point! Anyways, i guess if the position of the parallax layers are scaled, the level may fall short of parallax levels, and as such it might be nice to have the layers wrap around, one you reach the end of a fast-scrolling layer, ex.
if(seen_layer.offset + seen_layer.visible_size.x > actual_layer.width)
{
   seen_layer.offset = seen_layer.offset % actual_layer.width;
}
Again, this is more meant as pseudocode, but the point is that you might want to recycle layers that are repetative, or scroll really fast.
Is for the foreground thing, me neither, but some games have managed to implement this in a way that doesn't become too annoying. (fast scrolling, so a small movement on the "action" layer results in the disappearance of the obstructing layer, few occurrances etc.)

PARTNERS