wvmarle:
For comparison: that hardware will have a REALLY hard time decoding an mp3 file. In contrast, a cheap dedicated chip is doing this without breaking a sweat. Same for graphics.
But if you think you can do all that on generic hardware... go ahead. I'm not stopping you. I do know my old 486DX2-80 computer used to rely on graphics hardware to get halfway decent frame rates for games, as it was unable to do the rendering by itself.
I already wrote that I'm going to use simple buzzer, MP3 is way overkill.
can you both clear out what part of this game you think STM32 can't handle? I already gave numbers on SPI, SPI is not a problem. You think MCU can't handle few moving sprites or few events?
At the beginning I thought it will be way harder, now when I'm starting to realize how everything works I'm becoming more and more confident about hardware I will use.
I did way more CPU heavy calculations with Leonardo – few Pitagorian theorems (square roots), few circle radius calculations, reading (multiplexing) simple 38 buttons, decoding 2 rotary encoders (while multiplexing them), decoding 16 capacitive touch buttons I2C data, sending HID commands and animating 315 LEDs (software multiplexing and 3*16bit I2C chips), all at the same time at 100FPS. STM32 is ~10 times faster than Leo and Mario code definitely will not be harder than this.
Anyway, there is no point arguing, I'm going to Post office, I hope to get my logic analyzer, it will enable me to move forward and soon we all know if STM32 as good as I claim
I never said you'd be going to use mp3, just giving you an example of how what for cheap dedicated hardware is a simple task, is impossible to handle by a generic processor with ten times the processing power. Graphics is another example of this.
3Dgeo:
can you both clear out what part of this game you think STM32 can't handle?
The graphics are going to be a problem.
Rendering the complete image & collision detection is the hard part.
So you have 72 MHz, that is 72 mln clock cycles per second available for your project.
A lowly 20 fps gives you 3.6 mln clock cycles to render your image.
Keep that image limited to 240x240 pixels and you end up with just 62.5 clock clock cycles per pixel, and it won't matter much if anything if you're doing 8 or 32 bit colours on a 32-bit processor.
That's very little when it comes to calculating the pixel colour from a background file, figuring out whether there's a sprite on that pixel and if so which pixel of the sprite that is, and whether there's a collision with another sprite at the same time. Then the calculated pixel has to be stored, and transferred to the SPI bus.
Besides, you're going to need time for user input handling, sound effects, reading the background image, adding obstacles and coins or whatever Mario has to grab, keeping scores, handling the collisions, etc.
Calculations are indeed not complex, there's just lots of them to do.
wvmarle:
The graphics are going to be a problem.
Rendering the complete image & collision detection is the hard part.
So you have 72 MHz, that is 72 mln clock cycles per second available for your project.
A lowly 20 fps gives you 3.6 mln clock cycles to render your image.
Keep that image limited to 240x240 pixels and you end up with just 62.5 clock clock cycles per pixel, and it won't matter much if anything if you're doing 8 or 32 bit colours on a 32-bit processor.
That's very little when it comes to calculating the pixel colour from a background file, figuring out whether there's a sprite on that pixel and if so which pixel of the sprite that is, and whether there's a collision with another sprite at the same time. Then the calculated pixel has to be stored, and transferred to the SPI bus.
Besides, you're going to need time for user input handling, sound effects, reading the background image, adding obstacles and coins or whatever Mario has to grab, keeping scores, handling the collisions, etc.
Calculations are indeed not complex, there's just lots of them to do.
If that's really the case I can overclock STM32 to 128Mhz, if 128Mhz doesn't cut it – no biggie, I'll switch to ESP32 (160MHz or 240 MHz). Still too slow CPU? Lets just wait and see what happens.
Sadly, logic analyzer didn't came today
Due to being busy and still with no logic analyzer I didn't get far, but I get Mario sprite working (for now I'm using 80x160 LCD).
Photoshoped three LCD pictures in one:
Bottom two – strange transistion artifacts when filling screen from black to white or vice versa (Adafruit library, hope to eliminate them with my lib)
Finally, got ST7789 to work with Adafruit library:
In "Adafruit_SPITFT_Macros.h" thats located in Arduino IDE library folder in Adafruit_GFX_Library you need to replace "SPI_MODE0" with this "SPI_MODE3" in two paces to get ST7789 to work with hardware SPI.
Took me only two weeks to figure this out....
I took another look on level design and here is what I found:
Most likely they used „Meta meta tiles“ (32*32px) to construct levels for tiles that has a collision and for background elements they used simple object array with offset that repeats every 768px – it doesn't seems logic/optimal to have two ways of storing objects, but I have no better idea at the moment.
P.S. I might switch to ESP32, it has 512KB of RAM – plenty for frame buffer. Frame buffer will make coding way simpler.
I was exploring other options like adding 23K256 for frame buffer, but SPI will become a bottle neck if I do that, so no better option at the moment. Also I found that there could be only 5 enemies on a screen at one time, so this makes enemy management code a bit easier.
