True, it looks like you’re driving the camera and the ship is just a thing pinned in front of the camera – it’s always at the same position at the screen.
What @jonne says probably works but it seems a little complicated to me. Please forgive me if I’m talking nonsense, I don’t know the details of how the code is designed, but my philosophy here would be this:
Treat the camera and the ship completely separately.
Player drives the ship (car). The ship is for physics.
Camera follows the car (possibly in some clever way, such as the “rubber band”). The camera is for graphics (view).
Maybe this is obvious, I really don’t know. It just seems to me there is some unnecessary limiting relationship between the ship and the camera.
I also added to the GitLab the scripts that I use for generating the global palette and all image headers. Short instructions are in the “Examples\PZero\Tools\genhdr\readme.md” file. It is not very comprehensive explanation but I am happy to help if there are any problems.
I was also investigating the “rubber band” physics for the camera following the ship, but decided not to use it. The ship bitmap is currently viewed in one, fixed, angle only. It looked odd when the ship was moving to another angle, that is was expected to move(!). So I will stick to the configuration where the camera is always following the ship in fixed distance.
Next I will add collision checking to billboard objects, and then release a new demo, where you can try to get the best lap time
I’d personally want to make physics adjustments as well. But for an early stage I’d say it’s okay, the getting used to and learning the physics is always fun to me. As long as it’s predictable, which it is, you’ll learn to work with it and this eventually feels rewarding.
The steering ATM felt like it starts slow but gets faster, which is tricky and you have to time it, but it’s consistent. Before a curve you have to keep to the opposite side of the road and start steering early in order to make it. If there’s little room, you can cut the corner and drive offroad for a while, sometimes shorter path will compensate for a small speed loss, and if another curve follows, you’d need to brake anyway.
EDIT: (maybe I should add I never played the original so I don’t know what it’s supposed to be like)
I have put very little attention on the steering. I can make it faster if you like. Lets see how it feels after that.
Note: @spinal and @torbuntu, please put your lap times on the “P-Zero future”-thread to keep the development on-going ! There are only 2 answers so far. It is perfectly ok to say there that the game is not playable yet, so no lap time available.
I really want to come away from the ‘Pok-’ names, because I’m worried those will become really clichéd and boring.
Aside from sticking ‘Advance’ on a lot of GBA games and 64 on some N64 games, Nintendo rarely incorporated their console names into the game
I’d really love to come up with a name that incorporates some Finnish because I think Pokitto’s Finnish origins are something that should be celebrated, but I don’t know much about the language so I doubt I could do a very good job.
I kinda like the Pok prefix, my viewpoint being it creates kind of a nice namespace for clones (e.g. for my 2048 I didn’t have many other choices to consider), guaranteeing uniqueness and being informative. But if people perceive it as cliché, I don’t really care about names. The most important thing is it sounds cool and isn’t very long.
Coincidentally I’ve just found that the creator of Minetest is also Finnish. It’s becoming my favorite country because it’s just another cool thing about it besides Pokitto and Linux. I’ve also learned an interesting trivia from Minetest wiki about a block in the game that’s called a mese block:
Mese actually means “msn messenger” in Finland and is used as a silly word (it sounds silly) in the ohjelmointiputka programming community. Additionally it is thought that the glasses of the emoticons 8) and 8D are “mese glasses”.