OK, I don’t often finish coding games and this is no exception. I have however got it to a point where I’m happy to show off about it.
It’s my Arduboy remake (demake?) of my fav. C64 game Sensitive by Oliver Kirwa.
I couldn’t get a decent video of it running because I’m doing very silly things with the screen, but I did manage a couple of photos.
The title screen has two shades of grey and the levels have one shade.
Here is the source for anyone who wants to test it out on their Arduboy.
I thought this would be the first ‘grey’ game, but Remz beat me to it with 'Ard Drivin.
On the technical side, the music uses A.R.G’s music lib. The greys are done with screen flickering. I used a slightly different method to Remz, but trhe effect is still the same, approx 67fps to line up as good as possible with the screen refresh.
There doesn’t seem to be any delay at all when refreshing the screen, so we don’t have any vblank time to play with, so the GFX are done as fast as possible, all 8x8 tiles rendered by hand, with the exception of a single sprite.
A nice small 3x8 custom font to fit the required information on screen.
Neat. Flicker is pretty apparent on my unit. Also you should be able to try a puzzle an unlimited # of times. I don’t think your lives should be finite. Just my 0.02.
@spinal I also figured out how you could use the existing frame stuff to get your greyscale timing much much more consistent. Hit me up on chat if you want to know. Essentially your frames need to run a little “fast” and then your padding needs to be at the beginning of the loop, not the end.
#pseudocode
arduboy.setFrameRate(130); // slightly faster than you want
...
loop()
if (!(arduboy.nextFrame()))
return;
// at this point we're an even 7ms lets say
delayMicros(657)
// at this point we're at an even 7.657ms and we need to draw NOW
arduboy.display()
// code goes here to prepare the next frame for rendering in 7ms or so
This all presumes that you’re only using 50% CPU black/white to allow for 100% CPU for greyscale. If your loop is too slow then your timing will always be off. You can test that with the new function built into the library that causes the LED to light up if your code is too slow.
And of course this code knows nothing about greyscale… you’ll just be drawing white/grey/white/grey frames at ~120 FPS which will end up around ~60FPS.
The title screen will flicker a lot more as it’s using 3 frames for an extra grey. It doesn’t work weel enough for that, just an experiment.
As for the number of lives, I disagree, infinite tries would make the game far too easy imho.
I’m pretty sure we did 3 shades pretty smoothly before - although not as smooth as two, for sure. Let me add a 3rd shade to my demo and see what it looks like perfectly synced.
Just did, and wow
That’s really the kind of games I like: good puzzle game with awesome intro music.
It took me some time to get the gameplay but now it’s real fun. And the gray really adds something to the game.
Congrats! Really like it!
Just a small improvement would be to either remember the last level you played and resume on next game, or be able to select the level from the intro screen.
The intro music will loop some day, probably once team a.r.g add reloading music into their tracker, it’s not fun recomposing the music every time I want to change a bit.
I LOVE these kinds of games, but I just have been too busy to test it out. It’s on the top of my list. I’ll play it tonight and leave some good feedback.
All it really needs is for the music to loop. The gameplay is finished and there are plenty of levels.
Please don’t let the. ‘wip’ part prevent you from enjoying a great game.
Flicker in the intro screen is more apparent than when playing but noticeable no matter how you slice it.
I would like more contrast between the player and the background but maybe that makes it too easy
If you recreate the music in the editor (yes I know … again) and you save the file as an .atm file and post it here (or a link) I’ll help you making it loop. I need the saved .atm not the exported .h
Congrats on the game, well done, smooth, polished, great music, and fun to play! (Of course I’m going to “cheat/edit” the code and add of couple of lives because I want to see all the puzzles :))
Your grayscale title screen looks great and antialiased. The bottom half part flickers visibly, but could be made to be “by design” as a sort of sci-fi look.
I love your fullscreen fades too, using screen brightness.
Overall your grayscale technique shows the same “moving scanline” glitch than mine in Ard’ Drivin’. Is it a coincidence we both ended up at exactly 67 fps?
The title screen flickering is because it takes too long to render. For 4 shades, you need 3 frames and of course a much higher refresh rate. More lives is simple enough, just comment out the lives–; in movePlayer().
I don’t currently have any intentions of adding sfx to the game, I think it’s OK the way it is
No, because you’re trying to match the hardware refresh rate… but you can also change that by asking the OLED to refresh at different rates… so if you wanted closer to 60fps you can have that also. I keep the OLED PDF handy for reference.
