Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Updating a 2.5D game to graphics 2
Started by rakoonic2 Sep 08 2013 02:39 PM

34 replies to this topic
[TOPIC CONTROLS]
Page 2 of 2 1 2
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#26

rakoonic2

[GLOBAL: userInfoPane.html]
rakoonic2
  • Contributor

  • 503 posts
  • Corona SDK

One last point - I do now see sparklies amongst the track sections in the ipad (but not in the simulator). When I next have time I'll see if they go if I math.floor() all the path coordinates, but for now I shall relax, I am quite pleased with how this went tonight!

 

For what it is worth (not a lot!) here is a terrible quality video (but it lets you see some of the culling bugs at least).

 



[TOPIC: post.html]
#27

walter

[GLOBAL: userInfoPane.html]
walter
  • Moderator

  • 726 posts
  • Alumni

This is really really cool!

 

Would be great to get more info on your culling bug. Does it only happen when it rotates? Code would be great --- preferably a stripped down project. 

 

I didn't quite understand why you were basing everything off top-left --- is this a workaround for the culling bug?

 

For the corner offset stuff, we can't really make it actual values b/c we need to have a consistent origin, and anchor/ref points change that. Maybe having offsets expressed as percentages, e.g. ranging from -1.0 to 1.0 would make things more convenient? 



[TOPIC: post.html]
#28

rakoonic2

[GLOBAL: userInfoPane.html]
rakoonic2
  • Contributor

  • 503 posts
  • Corona SDK

Hey Walter.

You can see the culling bug in the video. The trackside objects vanish before they are in front of my cull plane (basically when things get too close). You can see another way the culling bug kicks in in the video when I brake to a stop and move left and right - the nearer I am to the left edge of the road the less track sections that get culled (in fact if I stay at the left edge, it draws all the track sections correctly).

The reason I base everything off top left is for simplicity. While a sprite retains its square shape, things like width, height, rotation, offsets etc make sense, but when you can move any of the corners to where you want, this relationship begins to break down. For example, what is the angle of rotation of an image if I also rotate the corners arbitrarily?

That's not to say these things aren't useful but they are complimentary.

Anyway, bottom line is, when dealing with 3d calculations like this, you don't think of each polygon as a seperate entity, but as part of a whole. So the easiest way to set things up is to position all the sprites at 0, 0 (top left of the screen) and just calculate all the coordinates of the various polygons together - that is to say, ey all use a common reference point or origin.
For whatever reason, the culling goes rather haywire, hence why instead of doing this I choose the top left corner (convenient because it is the first in order, and also the top left, ignoring massive distortions). However, that is likely to be unneccesary when the culling bug is fixed, so doesnt really worry me now.

The fact that the path is an offset is what concerns me.
For a system like this, where each sprite is a face you run into problems almost immediately. Anything but the most simple of 3d representations will require faces using different images. As my code shows (and it didnt show all of it) the difference between being able to specify the corners by pure coordinates, or having to do them via offsets based on the size of the source image is rather drastic - something that will certainly add up on the overhead per face and how many you can throw around.

For the origin method I proposed, the anchor point is also the sprite's position - that is to say I place the sprite at 0, 0 and make the anchor 0, 0 as well. At this point, having spent only a few hours in graphics 2 I must admit I'm not quite following the reason for not allowing direct placement of the corners - my suggestion was that the path, instead of being offsets, would be the actual values of the corners (relative to the anchor and x y pos of the sprite). You could 'easily' make the path be the real values rather than offsets (ie fill them with the width and height of an image when created or you change frame), which would allow for easier and more direct control.

I understand the difficulties of using real values rather than offsets - it can cause problems if you change the frame of a sprite and the frame is a different size, but in reality what would be the expected result in this case? I think this sort of issue is far more likely to be relevant where people are arbitrarily changing the path and frame of a sprite and want to maintain the path between changes.

Now, having said that, I've not looked into the other uses of paths - errr polygons I think use them too? I will take a gander is week as time permits, but I don't expect to find any anomolies there making offsets make more sense than actual coordinates, but any help in understanding this would be gratefully accepted.

I'll sort out the code tomorrow I think - I'll include the whole project but will chuck everything you don't need to look at into functions at the end of the main.lua, and hilight where the nice bits happen. One question - where do I send this stuff soit gets to the right people?

[TOPIC: post.html]
#29

rakoonic2

[GLOBAL: userInfoPane.html]
rakoonic2
  • Contributor

  • 503 posts
  • Corona SDK

Another thing, just to make sure I understood your comment. When I refer to actual coordinates, I am referring to them being absolute relative to the origin. Obviously if I set a sprite to 0, 0 ajd change the path, then add 10 pixels to its X value, the whole thing should move 10 pixels to the right :)

[TOPIC: post.html]
#30

walter

[GLOBAL: userInfoPane.html]
walter
  • Moderator

  • 726 posts
  • Alumni

"So the easiest way to set things up is to position all the sprites at 0, 0 (top left of the screen) and just calculate all the coordinates of the various polygons together - that is to say, ey all use a common reference point or origin.
For whatever reason, the culling goes rather haywire, hence why instead of doing this I choose the top left corner (convenient because it is the first in order, and also the top left, ignoring massive distortions)."

 

So I'm unclear on the above because you mention top-left in both the desired workflow and also in the workaround for culling.

 

 

"The fact that the path is an offset is what concerns me.
For a system like this, where each sprite is a face you run into problems almost immediately. Anything but the most simple of 3d representations will require faces using different images. As my code shows (and it didnt show all of it) the difference between being able to specify the corners by pure coordinates, or having to do them via offsets based on the size of the source image is rather drastic - something that will certainly add up on the overhead per face and how many you can throw around."

 

In our model, each object is local/relative to the parent group, not absolute. Sounds like you want absolute coordinates? Maybe I'm not understanding, but this seems like a big departure from our model (graphics 1.0 and graphics 2.0)

 

 

"For the origin method I proposed, the anchor point is also the sprite's position - that is to say I place the sprite at 0, 0 and make the anchor 0, 0 as well. At this point, having spent only a few hours in graphics 2 I must admit I'm not quite following the reason for not allowing direct placement of the corners - my suggestion was that the path, instead of being offsets, would be the actual values of the corners (relative to the anchor and x y pos of the sprite). You could 'easily' make the path be the real values rather than offsets (ie fill them with the width and height of an image when created or you change frame), which would allow for easier and more direct control."

 

By default, the path is centered around the object's origin (anchor defaults to 0.5,0.5). This is true for polygons as well. If you change, the anchor then the path is re-positioned. So in this case, offsets make the most sense.

 

 

 

Also, the offsets give us the flexibility to do an optimization where we could turn off 2.5D for objects that don't use it. Not everyone uses it.

 

Sounds like you have a particular workflow in mind. I still don't quite understand it, so hard for me to comment on specifics.

 

"I understand the difficulties of using real values rather than offsets - it can cause problems if you change the frame of a sprite and the frame is a different size, but in reality what would be the expected result in this case? I think this sort of issue is far more likely to be relevant where people are arbitrarily changing the path and frame of a sprite and want to maintain the path between changes."

 

 

Can you give me a simple code snippet that demonstrates how this changes over a series of enterFrames? That would help me understand what's hard about managing offsets.



[TOPIC: post.html]
#31

rakoonic2

[GLOBAL: userInfoPane.html]
rakoonic2
  • Contributor

  • 503 posts
  • Corona SDK

Walter Ill try to find time to sort out some simple demos for you as soon as I can. I think we are gonna keep having a misunderstanding until I can show what I mean. Give me a day or so to work up some demos and possibly an image or two and I think we should be able to resolve everything :)

[TOPIC: post.html]
#32

rakoonic2

[GLOBAL: userInfoPane.html]
rakoonic2
  • Contributor

  • 503 posts
  • Corona SDK

Walter - I have the code for this demo waiting for you guys to look at, and have simplified it as much as possible (moved everything irrelevant into functions at the bottom of the main.lua, and highlighted where the 'interesting' bits happen).

 

 

Now, where do I send them to? :)



[TOPIC: post.html]
#33

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Nice! Awesome job!



[TOPIC: post.html]
#34

walter

[GLOBAL: userInfoPane.html]
walter
  • Moderator

  • 726 posts
  • Alumni

Awesome!

 

You can send to me: walter at coronalabs dot com. Attach, or send me a private link, etc.



[TOPIC: post.html]
#35

rakoonic2

[GLOBAL: userInfoPane.html]
rakoonic2
  • Contributor

  • 503 posts
  • Corona SDK

Walter - files sent. Have fun :)

 

I did include a longish discussion of the path value and how I feel the implementation is wrong, but of more concern for you I believe (as it is an actual bug) is the culling of images. Do a comparision of the old and new versions - it will become readily apparent where the errors are happening.




[topic_controls]
Page 2 of 2 1 2
 
[/topic_controls]