Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release Readyness Checklist #376

Open
7 of 13 tasks
Gadgetoid opened this issue Sep 30, 2020 · 4 comments
Open
7 of 13 tasks

Release Readyness Checklist #376

Gadgetoid opened this issue Sep 30, 2020 · 4 comments

Comments

@Gadgetoid
Copy link
Contributor

Gadgetoid commented Sep 30, 2020

With release hardware on the horizon we're ramping up toward a launchable codebase with wrinkles ironed out and a small wishlist of day-1 features:

  1. The blit API should be reasonably stable but as long as no. 2 is enforced this shouldn't be a huge deal, + known bugs fixed (How does/should ParticleGenerator work? #354 Random API inconsistencies #344 sprite transform R90 is 1 pixel out of alignment when scaled 2x #221 Surface::line algorithm is.. jank? #504)
  2. The firmware->user code API should be FINAL (or relatively so). Changing this potentially makes binaries incompatible with the firmware.
  3. We should be building/releasing firmware for Beta and Final units (merge Add support for LIS3DH accelerometer #360 and do a test release)
  4. Examples should be tidied up and converted to asset pipeline where appropriate (Assets pipeline for palette-cycle/swap and shmup #365)
  5. Examples should all have metadata config, icon and splash
  6. PIC should be finalised and merged though I'm keenly aware how heavily we're leaning on @Daft-Freak for this! (WIP: PIC for games #388)
  7. Documentation should be given a shakeup
  8. Releases should include license and documentation (Add README.txt, LICENSE.txt (and possibly CHANGELOG.txt) for releases #145)
  9. Ensure 32blit Python flash tool implements all features and can replace the C++ one (Deprecate C loader, revisit 32blit docs #395)
  10. Split Firmware into Firmware and Launcher, add file association support (Splitting "Firmware" into "Firmware" and "Launcher" #435) (WIP)
  11. Lua interpeter with file association support, runs the .lua file in persistent state (WIP)

Nice to have's:

  1. Some method of updating firmware without DFU (Investigate firmware update feature #192) (WIP)
  2. A more complete set of easing functions and corresponding demo (Add common easing functions and cool demo to browse them #350)

Example todo:

  1. Platformer needs to work... like a platformer
  2. What even is matrix-demo?
@Daft-Freak
Copy link
Collaborator

For the firmware API, I think we need a version field there and somewhere in game headers so that it can possibly be extended.

I started on an easing demo somewhere...

For PIC there are a few things left:

  • Need to fix CDC flashing (doesn't handle relocations)
  • Sort out the stdlib build, currently requires that you either build most of GCC, or needs 100MB of libs to be downloadable from somewhere. (~20MB zipped)
  • Fix the travis build
  • There's a script to prepend a header with relocation info, that probably needs something doing to it (https://github.com/Daft-Freak/32blit-beta/blob/pic-returns/tools/gather-relocs)
  • Will need a little adjusting after the metadata stuff

Should replacing the flash tool with the new one be on the list somewhere? I think it's close.

@Gadgetoid
Copy link
Contributor Author

Agreed regarding versioning the firmware API, at least that would give us some way to feed back the incompatibility rather than just crashing outright. Games would need to define a "target fw version" or something, I guess.

  • We could earmark CDC flashing as a "dev only" thing and not worry too much about it for now, if it helps.
  • stdlib is 😬 I guess it's easy enough just to host the libs somewhere- maybe tagged onto github releases? Guess they'd ideally need to be fetched automagically for building.
  • Should gather-relocs be part of the 32blit Python tooling?

Added flash tool to the list! Good point.

@Daft-Freak
Copy link
Collaborator

I don't think CDC flashing should be too hard, at worst it could just drop the relocs and flash to 0... (I haven't touched it yet, it's probably flashing somewhere weird)

If the stdlibs are hosted somewhere I think CMake has commands for downloading and extracting them. There are also the scripts I used to build them in the branch.

gather-relocs was a bit of a hacked together tool, not sure where it should end up... I guess every other tool for a game build is there. Its only dependency is pyelftools.

@Gadgetoid
Copy link
Contributor Author

As of 32blit/32blit-tools#31 the tools will have all the pieces in place to understand the reloc structure. I'll look at getting the relocs tool merged in as part of this.

Now we have a dependency on Construct in the tools, the DFU tool can come along for the ride too.

Gadgetoid added a commit that referenced this issue Dec 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants