mmm... moving the car instead of the road... a bit radical, but it could work...
the thing is I had a 'mental block' for the road always coming down the screen (so that the car's left and right are always the same), but if I move and rotate the camera relative to the car I should get the same effect...
and when you realize that, the previous alternative is a bit over-complicated (and silly)... sometimes you get obsessed with one way of doing things and it's just a matter of a fresh pair of eyes to solve it

thanks!

Hi,

I've been a while trying to figure this one out for a prototype I'm working on: I have a racing car that remains static, with a top view camera on it and the ground moves as necessary. The ground (racetrack) needs to translate according to speed and rotate according to bearing. The rotation needs to be made relative to the point over the racetrack where the car is, so I understand I need to change the pivot point. I set the new pivot point relative to the transformed center (car started at center of world, and background was instanced and never relocated, so it should initially have it's center at world(0,0,0)). I think I'm close to solve to problem, and I guess it relates to the transformed center inversion, but after trying many variations I just can't find the issue... maths/geometry is not my thing.
So the piece of code below has a test bit to change steering by 45 (Math.PI/4) degrees every 20 ticks and places a cube at the calculated pivot point. First iteration works fine with pivot point set to (0, -20, 0), no previous rotations so only the translation is relevant. Second iteration, after the previous 45 degrees rotation, the pivot point is calculated correctly aprox. (-14, -34, 0), the test cube is placed on the right place but the background kind of translates twice, so the car appears off by double the distance on the previous direction... and then it just gets worse:

    public void tick(Car car){
        count++;
        if (count%20 == 0){
            car.angleChangeRatio = (float) (Math.PI / 4);
        }
        model.translate(0, car.speed, 0);
        if (car.angleChangeRatio != 0){
            model.getTransformedCenter(tmpVector);
            //tmpVector.scalarMul(-1);
            tmpVector.y = -tmpVector.y;
            model.setRotationPivot(tmpVector);
            model.rotateZ(car.angleChangeRatio);
            Utils.log(model.getRotationPivot().toString());
//            model.rotateMesh();
            car.angleChangeRatio = 0;
            Object3D show = Primitives.getCube(1);
            show.translate(model.getRotationPivot());
            model.addChild(show);
            Utils.world.addObject(show);
        }
    }


any suggestions?

very nice work, congratuleishons

I got it, there was something wrong with the signed version (as it was working on the development build), might have to do with the static values in R class or so. Clean build and it's working fine now, thank you very much for spotting this!
(also tested the free signed version and this one seems fine)

Crap! I wanted to have a nice clean release :S
On which level are you getting the error? (I made a quick test for all levels and they loaded fine)
thanks

Hi!

Just published the final version of the game (two versions actually, free and full). Here's a video showing the action:
http://www.youtube.com/watch?v=qoI2kOvJVd4

thanks for the stack trace, should be fixed for next release (I don't want to update just for one bug, should get a few more ). In the meantime, it should work as long as you don't touch the screen between level success and next level loading (that's the only way I got it).

ok, I have made a quick release including directions (N, SE, W, etc.), a bit vague but should be a good balance between lost and too easy search...
and I think I am done with the main development. Unless there are bugs reported or other suggestions I will now focus on adding levels for a full release!

I thought of it at an early stage of development (adding an arrow for direction) but ditched the idea because this way, having to search around and finding the spot while avoiding the monsters is part of the challenge... it would be too straightforward and easy otherwise. Does this 'lost' factor make it dull, tedious or boring?
if it is, I might think of something less obvious and for the easier difficulty levels...

I have this polygon that I want to shrink/expand on one axis. It is meant to represent a sea wake. I am currently just translating it (see current version of Run!) but I think it would be a nicer effect with scaling.
As far as I can tell, the scaling method applies to all coordinates... and the only alternative I can find is using a vertex controller but I'd rather avoid doing this kind of modifications constantly during runtime (added cost of mesh modification plus I guess there are SimpleVectors created that would then increase gc time)... is there any other option to scale one axis?

I wasn't dealing very well with the screen capture process... should be better now (new release published)

done, haven't seen the issue again so far so... new release out!

turns out me playing with the setsortoffset didn't fix the transparency problem :S
the ground layer is added first to the world, then the trees... in any case, the issue shows up randomly...
any hints/details on how that method actually works (values I should set)?
in my last attempt, I set -2000 (negative values getting closer to the camera) for the trees and 0 for the ground layer
I'm ready for a new release with a few nice details and fixes, but would like to include this... and, while I thought of having opaque leaves, I would still have the same problem with future features.
on a side note, I'm using png's with alpha channel...

now it's failing at java.i--- oh, wait, it's working now thanks

now it's java.io.NotSerializableException: com.threed.jpct.Plane