It’s quite refreshing to see colour spelled correctly online keep up the good work!
…I am so used to work on a tiny screen that i made it way too small i think LOL
Right now it’s white numbers with a shade in them and a darker contour… But yeah, it’s small
Thanks! I will try that. The screen mode is 110x88 so it is not necessarily too small.
@Vampirics will probably do a better job anyway.
I only pretend to be an artist, he actually is an artist.
Also I don’t mind other people chipping in,
I never intended to be the only artist working on this,
I’ve just sort of ended up becoming the de facto artist.
(Also, sorry I haven’t made that tree yet, I’ve been a bit under the weather lately and I’ve only just picked up a bit in the last day or so.)
If/when we get round to revamping the PokittoLib, I’d like all identifiers with the word ‘color’ to also have a ‘colour’ variant.
I’ve lost count of the number of times my code doesn’t compile because I’ve instinctly written something with ‘colour’ and it won’t compile because the API uses the American spelling.
The only library I can think of (off the top of my head) that permits both is SDL2.
That extra bit of catering has always stuck with me.
(Despite being a C library, SDL2 is quite well designed.)
I have big countdown numbers 1, 2 and 3 from my older game, you’d probably need to scale them down, I’m too lazy now
I’ve also made a few bitmap fonts of various sizes with numbers, they’re in my collection.
Feel free to steal, modify or whatever, it’s all CC0.
I also need to put my scripts for generating bitmaps to Github.
Thanks for that!
Hmmm, would variable height road be possible? The gameplay could also benefit if it affected the car physics, because you’d have to break before hills in order not to fly off the road.
What do you think, would it be difficult to add? (Just hypothetically, possibly in distant future.)
Perhaps, but it would be difficult with the current system where everything is a huge plane that is moved and rotated. In most Outrun clones the road is not really rotated, but the scanlines are just sheared. That would make it easier to implement variable height.
I also currently would like to implement more game related features, like lap timing, and leave the engine related improvements to the future.
I would like to see a game based around that idea. Make it arcade like where you could even jump over other cars a bit like San Francisco Rush 2049.
I was trying to solve the wrong problem with billboard mipmaps. The problem is that when scaling a billboard image (e.g. just a few pixels smaller), the image “lives”, i.e. looks different on each scaling level. That is caused by a nearest-neighbor scaling. To get rid of it I would have to use filtered scaling. Or use “continuous” images: images which do not have sharp edges or thin lines.
Mipmaps can be used to improve the quality if the scaling differs a lot from the original, e.g. scaling to 50% of size.
So I decided to forget billboard image mipmapping (but still use it with textures), and consentrate on other things.
Maybe for the sprites you could have an additional info that would say e.g. “when scaling down, try to keep this column as it contains and edge”. Kind of a super smart, heuristic scaling. The info could be optional (just for the problematic sprites) and created either manually or automatically precomputed (edge detection is easy). But dunno if this would work at all, it’s just a thought. Would take a lot of time to think through and implement, would be for a separate demo.
Or maybe with the right palette and some precomputing interpolated scaling could be implemented – fast filtered scaling would be another great achievement on Pokitto. I’ll try to think about the details. Interesting problem you have here.
It’s a good idea to move on for a while though.
Here is the latest version in action. There are cactuses, stones, and other cars. No collision detection thought.
pzero.bin (73.7 KB)
Hanski you need to change the rotation point of the view. It does not look right. The scene has to rotate around the ship.
IIRC before you draw, transform the camera to the point where the ship is. Then calculate rotation and mapping.
I’ve done it once and got it to work, I need to check if I can find the code somewhere.
Yep, now I remember. In addition to camera position and direction vectors you should have a 3rd person view transform vector (initial vhoriz = 0, vdistance into screen = z distance from camera to the ship).
Then, when you calculate the rotation of your camera, you also rotate the 3rd person view transform vector.
Now, when the scene is rendered, instead of calculating the mapping from the point the camera is actually in, you add the 3rd person view transform vector to the camera location vector and you calculate your scene from that point
Magically, your game will look so much more realistic
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.
You are both right, rotating looks weird. I will think about it. Probably, I will try how the “rubber band” following works for the camera.
I added the binary file under the video above.
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.
A small update.
I have now added lap timing.
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
Nice to hear about the progress
About the camera – that’s okay – when the code’s open-source, someone else can try to tackle that. I’d like to play around with it myself.
The first version, where you can try to beat yourself, is now here! There is now the lap time, which is saved to EEPROM. My daughter got 27.0 sec.
pzero.bin (75.7 KB)
- The start menu
- You can hit to the objects now
- Changed terrain to yellow (desert) to make cactuses more visible.
- Corrected the center of rotation