I am currently working on a remake of 1943: The Battle of Midway
It is still in development but slowly getting there. I have implemented the roll, the power up that gives you 3-way shooting and so forth. Watch to the end of the video to see what happens when you run out of fuel.
I created the video using SIMAVR so unfortunately you will not be able to hear the cool music that goes with it.
The speed on the simulator is not quite right and the graphics on the Arduboy are a lot smoother.
This would lend itself to an Arduboy with a vertical screen (like the Tetris Microcard).
A.W.E.S.O.M.E. well done @filmote Are you using the latest version of the emulator? If yes and the speed is not satisfying then you can recompile it after changing #define USE_THREADS 0
to #define USE_THREADS 1
in sim_arduboy.c
Iām thinking that I better prioritise releasing binary buildsā¦
I didnāt think the existing video without sound really did the game justice, so I made one with sound and gameplay of the first level.
My video is pretty bad because I made it with a really old camera that films in 1440x1080, itās night here, our bulbs give off a silly orange glow, Iām bad at filming and I crushed the quality from a 77MB .mov to a 4.5MB .webmā¦
Hi there! loving it! Iām also a huge fan of the original!
Interestingly enough, my last processing minigame was a remake of this with my own graphics and a more āfuturistā theme. If you are interested by straying away from the original, Iām sure I can port my graphics to be Arduboy friendly! (including the cute little pin-up girl). See attached screenshots:
I love the idea idea but it would be an interesting challenge to get this to run in the memory constraints of the Arduboy. As it is, my program is taking up nearly all of the memory and I have spent a fair bit of time (with @Pharapās guidance and help) to minimise the overheads of the code.
To give you an idea, the enemy planes are 16 x 16 pixels and take 34 bytes of data each. I have 8 images facing north, north east and so forth, so 8 * 34 = 272 bytes. Each has a mask of equivalent size so 544 bytes. I have two different enemy types so 1,088 bytes. I also have boats, the actual playerās image (with various images of it crashing into the sea), explosions and a bunch of matching masks. It is easy to consume 3 or 4K on basic sprites and we havenāt even got to splash screens, mission end and game over screens.
Did I mention music and sound effects? More memory ā¦ and the machine only has 28K of progmem and about 1.5K of useable RAM.
I make it sound limited but in my mind this is the joy of developing in this environment, Just what can you squeeze out of it?
I have been building some routines to rotate images 90 / 180 / 270 degrees and to render sprites from RAM and / or Progmem. This will allow me to reduce the number of images significantly but will I will need some staging memory in the already limited RAM. See how we go.
@filmote I will show my ignorance, surely! (and my age also :))
for the sprites, if you go full top down, canāt you just rotate the sprites? Can you overlap two spritesā¦ some enemies could be a combination of 2 overlapped sprites, as a way to save storage space while bringing diversity? why do you need to have the 8 directions? (or is it because you want to stick to the original art style that included some sort of perspective? - or maybe rotating sprites isnāt an option in Arduboy?)
What are the masks for?
The crash: can it be done through āfakeā particles? (when I did my processing one, the explosion where the plane looks like itās dismantling is actually not a sprite but āfakeā particles (meaning instantiated pixels that fly off on collision)
About the sound: been using trackers for a big part of my life: was playing with FastTracker when I was younger, and from what Iāve seen with Team ARG, it seems that the way music is composed with Arduboy is somewhat very reminiscent of the tracker sceneā¦ if thatās the case, I may be able to help there as well, Iām still into music and still compose with trackers (using https://www.renoise.com/ now, which is a very very modern version of Fastracker)
Thatās precisely why Iām worried about learning C++: it seems that a lot of the conveniences Iām used with Processing or Unity, like sprites rotation, are a āluxuryā with the small memory footprint of Arduboy.
Please, donāt consider any of my questions as a challenge: Iām just trying to understand the production pipeline as an artist for this device, not trying to imply anything or sound that āI know whatās upā - I have no slightest clue on what it takes to make GFXs for this device yet
to make more sense about the overlaping of sprites: for example, in your game, you have enemies with colored wings, and enemies with outlined wings: could the colored wings be its own spritesheet that overlaps over the outlined planes while not including the rest of the plane shape? that would save a few bytes (or KB) in the spritesheet? Again, just spit-balling here to try to understand better the memory constraints as far as GFXs go!
Actors could easily be made from multiple parts. I have 8 positions because there is no native rotation of images in Arduboy - hence the routines that I are working on.
Spritres in the Arduboy library are an array of black / white pixels. If your sprite is non-rectangular, you may want to provide a mask which defines the āshapeā of the sprite itself - The sprite and the mask are logically combined to work out what to apply to the screen itself. If you have time, look in the previous copy of the Arduboy magazine for my article or run the following sample code > https://github.com/filmote/Pipes_Article1_SpritesDemo
You could do this ā¦ its a trade off between the amount of code required to achieve this versus the amount of images you need.
Well, Iām possibly barely a year younger than you
Thanks for your answers - it does indeed show me that I need to dive deeper in Arduinoās IDEā¦no native sprite rotation is a bummer :(ā¦ oh well, if you need help with anything while being ok providing direction, Iāll be happy to oblige
FYI Iām working on a library for rendering frames on the fly. I do not have anything to show for the time being and itās just an experiment of mine but the upside is that there is no frame buffer and you gain 1024 bytes of RAM, the downside is that without vsync signal there will be some tearing.
WOW I finally get some time to catch up on Arduboy to find this sitting here, this is amazing stuff @filmote .
I too would love to see a programmable Microcard as the Arduboy doesnāt really shine in Tate mode.
