Add a _stage module

[deshipu]

This module is a part of the "stage" library, which is a tile and sprite engine for games using SPI-based RGB displays. The library is part of the µGame project (https://hackaday.io/project/27629-game), and contains optimized low-level code for rendering the data and sending it to the display as fast as possible. It's not enabled by default in any ports, even though in general it could be useful outside the µGame.

[deshipu]

I'm still working on documenting and releasing the "stage" library itself.

[dhalbert]

@deshipu This is very interesting. Let's wait for the stage library to be ready, since you may want more changes here in the process of finishing that.

[deshipu]

That was my intention, I just wanted to put the code out there as soon as it's ready.

[deshipu]

The first version of the Stage library is now available at: https://github.com/pewpew-game/circuitpython-stage

[tannewt]

I'm super excited about this! It reminds me of this talk: https://www.youtube.com/watch?v=HyzD8pNlpwI

It looks good to me. The one thing I wonder is if its worth thinking about how it work if the display was QSPI instead of SPI because the SAMD51 has a QSPI peripheral. Would it be worth delegating the actual write back to Python to gain flexibility on where the frame is written to after its rendered?

[microbuilder]

@tannewt Feel free to correct me, but I've never seen a QSPI display ... it's normally only used for very high speed flash memory access, such as an MCU with external flash where you want to execute code directly off the SPI flash device. As such, for anything display related I don't think it's worth waiting or reworking anything around QSPI.

[tannewt]

Thanks for the info! I didn’t look just thought there might be.

…

On Mon, Nov 6, 2017 at 5:49 PM Kevin Townsend ***@***.***> wrote: @tannewt <https://github.com/tannewt> Feel free to correct me, but I've never seen a QSPI display ... it's normally only used for very high speed flash memory access, such as an MCU with external flash where you want to execute code directly off the SPI flash device. As such, for anything display related I don't think it's worth waiting or reworking anything around QSPI. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#398 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqSKE41Zwg1BIUNTYziI4-V7pByb1ks5sz7ccgaJpZM4QO3oN> .

[deshipu]

This is a great talk, and GameBoy is certainly a very well engineered system — though they drove their LCD display directly, not with a luxurious chip that we have nowadays, so the timings had to be exactly right.
I haven't heard about quad-spi displays — I think at that point you would simply use a parallel 8-bit or 16-bit interface, that most such displays support. We might add support for that at some point, but it will have to be in the C module. I did try to make it just fill the buffer, and then send the contents of the buffer using Python initially — that's why you still have to explicitly pass it the buffer to use. The problem is that switching between C and Python takes a long time, and moving the call to C sped the whole thing up considerably, so I decided to go for less flexibility and more speed.
This is not the only place where I'm making this kind of decision. The fact that the sprites and tiles are only 16-color, and that they have fixed size of 16x16, the fact that fonts are all 8x8 and 4 color, the fact that you have exactly 16 tiles per bank, etc. — those are all design decisions that I made to speed up and simplify things. A much more general and flexible library is possible, but it wouldn't be as small and fast.

[tannewt]

Ok I'm happy with this! I can't wait to see it evolve!