Stab in the dark - the object path value - here we go. In fact to check I have the rotation correct, I’m simply going to replace my width and height settings (which seem to go wrong) with the path stuff, should help me understand the ordering and rotation (fingers crossed top left and clockwise, as that’s what I’ll set up for first).
Ok I have the ground sorta working (road and scenery is disabled for now). Values are a bit weird though - am thinking this is because of the offset stuff again, treating 0, 0 as the center…
A few tweaks and I have my bars scrolling along properly, hurrah! Encouring, now for the road sections…
Bit confused though - I can specify the Y values of the path in absolute screen coords, but the X ones not, they are relative. Hope this is just me doing something wrong:
[lua] – Long hand!
sprite.path.x1 = 0
sprite.path.x2 = screenWidth
sprite.path.x3 = 0
sprite.path.x4 = -screenWidth
sprite.path.y1 = oldScreenY
sprite.path.y2 = oldScreenY
sprite.path.y3 = screenY
sprite.path.y4 = screenY[/lua]
I am beginning to suspect that a sprite’s X and Y values are recalculated after setting the path, to maintain it in the center. Time to track down that offset help methinks, hopefully there is a way to disable it because the simplest means of controlling the shape is to dump the sprite at X,Y = 0,0 and then just set the path corners in screen coordinates.
Looks like I got my ordering wrong. Seems like x1, y1 is top left but it goes counter-clockwise. Probably my memory at fault here, I did think OGL ordering was clockwise but clearly not!
Oh dear me I think I have twigged it. The path values are offsets from the normal size of the image used.
My terrain lines are images as wide as the screen, but 1 pixel high. I couldn’t work out why if I set all the X values to 0, it was filling the screen still. OK… they are relative. I am err… not sure why they’ve done that but I can work with it now I know.
NOW onto the track sections.
I should point out that if I place two distorted rectangles touching along an edge (IE sharing 2 corners) - no matter what I do to distort the pair together, the joined edge never shows gaps - this is awesome (thanks OGL!) and prevents sparklies, something I had to factor in before with my other hacked method.
Track sections in as rectangles, about to make them quads and viola, lovely track!
Making the path relative to the size of the image though is really striking me as odd.
The path is essentially a list of offsets, rather than definitive coordinates.
This means every time I want to draw an image and distort it, I need to know the width and height of the source image, which is rather frustrating:
[lua] sprite.path.x1 = left
sprite.path.x2 = left
sprite.path.x3 = right - size.width
sprite.path.x4 = right - size.width
sprite.path.y1 = oldScreenY
sprite.path.y2 = screenY - size.height
sprite.path.y3 = screenY - size.height
sprite.path.y4 = oldScreenY[/lua]
And we can haz road! Looking extremely nice and fluid!
I have noticed a bug with the sprites - if I turn on the road tilting (for when you go around corners) the track disappears - I imagine this is down to some sort of culling issue with rotated quads. Not a killer for now though, I just disable it.
An addition to the previous message - they only vanish if the images are rotated more than a slight amount clockwise - anticlockwise they don’t vanish.
Scenery is in but goes rather majorly wrong when you start to move down the road. I am wondering them going off screen affects things, or if having the sprite drawn above left of its registra… sorry - anchor, causes problems.
Will try offsetting by a couple of 1000 pixels now to see if that helps at all.
Nothing gets drawn when I try offsetting, so now I’m going to try moving the sprite’s X and Y to the top left and make everything relative to that - just in case it helps.
OK so, I have scenery in and (mostly) working.
What helped most was moving the sprites’ X and Y to where I was setting the x1 and y1 values before (so leaving them at 0, 0) and making the remaining 3 points relative to that. More code, but it works!
Culling appears to be an issue though, as things vanish if they get too big, or if they go offscreen too much. This also leads to problems that I didn’t have before (not all the closest track sections are drawn now), but it solved others (far less culling when not needed, and things don’t vanish when you rotate in a certain direction).
Built and tested on ipad.
I was a bit optimistic - I set the draw distance to 300 meters (it was previously at 60!) and it ran at 60fps most of the time on the ipad 2, but not always. That was me being silly, I wouldn’t necessarily up the draw distance anyway, even 60 meters shows you plenty ahead (it feels further), and I need some CPU for AI etc 
If corona gives me permission, I’ll testflight out the build to interested people. Not going to bother sticking up a video simply because the video at the top is close enough to what it looks like now, and framerate isn’t going to improve in the video as my comp is the limit!
@Corona guys - if you want to see the bugs, let me know, I can testflight you in or even send you the source code.
So, conclusions:
-
There are still some bugs. Big wow on that one. Given this was marked as an alpha, I can’t say it has frustrated me with the bugs, there are fewer than I’d expect given the big undertaking that is graphics 2
-
It *works*. No show-stopping bugs. To be honest the only problem is the culling, and that is all - if it wasn’t for that the demo would be running identically to what I had before (albeit a great deal quicker!).
-
The implementation of the paths for me leaves a lot to be desired. Having path be a series of offsets doesn’t strike me as useful. I think it would be better to have it contain the actual image corners, which you can then modify directly. Needing to know the width and height of the image to position corners is absolutely horrible. This above all else is what I’d change as a design decision, as it is going to cause a lot of headaches in the future for people.
-
Positioning the X and Y to the top left corner is also a pain, but I only had to do this because of culling bugs (and even then I only managed to minimise it). Hopefully this wouldn’t be necessary at the end, so I’m not going to lose any sleep over this.
The end result of this is instead of being able to do this, for example:
[lua] sprite.path.x1 = x1
sprite.path.x2 = x2
sprite.path.x3 = x3
sprite.path.x4 = x4
sprite.path.y1 = y1
sprite.path.y2 = y2
sprite.path.y3 = y3
sprite.path.y4 = y4[/lua]
I have to do something like this:
[lua]
local size = sizes[imageName]
local width = size.width
local height = size.height
sprite.x = x1
sprite.y = y1
sprite.path.x1 = 0
sprite.path.x2 = x2 - x1
sprite.path.x3 = x3 - x1 - width
sprite.path.x4 = x4 - x1 - width
sprite.path.y1 = 0
sprite.path.y2 = y2 - y1 -height
sprite.path.y3 = y3 - y1 - height
sprite.path.y4 = y4 - y1[/lua]
Cleary more code slowing stuff down, and a probable major hindrance for any generic 3D engine.
- I notice some jerkiness in the movement of the sprites when up close - am going to play a bit more later on to see if I am math.floor()-ing where I shouldn’t, or something else. Also going to disable the pixelated draw modes - just anything I can see that might cause pixels to misbehave.
OK I removed math.floor() and what-not and I am sure that the juddering is a bug with either graphics 2 or OGL, which means I’m naturally leaning towards G2 as I doubt OGL would have come this far with such a bug. Again, corona guys - if you are interested I can send the code and add you in testflight to see the actual problem - it is gonna be impossible to show it in a video.
I should point out (as I just noticed) that in the simulator I don’t see the jerkiness, only on the device.
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).