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

PicoVision #829

Merged
merged 23 commits into from
Oct 19, 2023
Merged

PicoVision #829

merged 23 commits into from
Oct 19, 2023

Conversation

Daft-Freak
Copy link
Collaborator

@Daft-Freak Daft-Freak commented Jul 18, 2023

Opening this to keep track of things now that the dependencies have been merged. Most things are at least working at this point. The biggest limitation is that screen.data is null, so anything that directly reads/writes screen data is going to be broken. (The recently added get_pixel helps with reading a little)

Potential breakages:

  • 28ac10d likely breaks VGA board (needs a limit on samples generated each update)
  • 7553ae4
  • Screen mode changes (c275eb2, 322adce) affect everything and definitely require an api version bump
  • Branch is a bit broken in the middle (wrote the code on top of a bunch of WIP screen changes)

PicoVision-specific unfinished-ness:

  • Currently claims the screen is RGB565, which is wrong but you can't directly access the data anyway
  • Small blits/blends are very unoptimised
  • Large blits with no transparency are also suboptimal (always reads old data)
  • pimoroni-pico usage is uh, questionable (using one and a half drivers, see 32blit-pico/CMakeLists.txt changes)
  • Clock override (34ac6b7)

I also have plans to allow more screen modes (and 640x480 without recompiling). That shouldn't involve huge changes though... and I need to add some way to write a bunch of raw data to I can port DaftBoy (if only blits from 16-bit formats were supported. Not sure I want to add a format that's only supported as a blit source on one device...)

if(new_mode == ScreenMode::hires_palette)
set_screen_mode(ScreenMode::hires, PixelFormat::P);
else
set_screen_mode(new_mode, (PixelFormat)-1);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should probably define a PixelFormat::Default or something instead of the magic -1...

@Daft-Freak
Copy link
Collaborator Author

Now with less breakage to other things and actually compiles before the end! (Now I just need to fix audio and maybe make it not depend on core1... for uh, reasons)

@Daft-Freak
Copy link
Collaborator Author

Just need to merge the screen and audio PRs and rebase then this should be safe.

@Gadgetoid
Copy link
Contributor

I think Mike has rained on your parade a little by adding vertical scrolling and changing the number of available scroll whatsits, but I guess in principle you can just target whatever prior version of the pico-stick driver since you don't use fancy stuff anyway?

@Daft-Freak
Copy link
Collaborator Author

The unfancy-ness should mean it's not too hard to fix hopefully. Though this does make me wonder if I should make it automatically grab the picovision repo to simplify setup 🤔

Need to do a rebase/tidy tomorrow (probably) anyway...

@Gadgetoid
Copy link
Contributor

Ugh that reminds me I need to get Mike to fix permissions on the pico-stick repo so releases can upload! Or maybe I can...

@Daft-Freak Daft-Freak force-pushed the picovision branch 2 times, most recently from 2d36ca7 to 6e0d533 Compare September 29, 2023 14:26
For when we need to do something special to write to the framebuffer
It works and can do full 640x480 (with additional changes)
Write straight to the RAM instead of going through DVDisplay. This also handles mode switches now. (with display size set to 640x480)
Roughly 115 to 70ms in rotozoom, improves tilemap-test slightly (around -10ms)
-11ms in rotozoom with the always_inline
Now there's at least some way to read from the screen surface
The existing formats are

bytes                                  n-bit value
RRRRRRRR GGGGGGGG BBBBBBBB                     BBBBBBBBGGGGGGGGRRRRRRRR
RRRRRRRR GGGGGGGG BBBBBBBB AAAAAAAA    AAAAAAAABBBBBBBBGGGGGGGGRRRRRRRR
GGGRRRRR BBBBBGGG                              BBBBB   GGGGGG  RRRRR

This is
GGGBBBBB xRRRRRGG                      x       RRRRR   GGGGG   BBBBB

So as it's the other way around, call it BGR.

(Even though our RGB565 is a bit backwards, though if you consider them
as packed formats, they're ALL backwards)
@Gadgetoid
Copy link
Contributor

Just in case it's useful: I have added a new release for pico-stick, which includes both normal and widescreen firmware headers and elf files: https://github.com/MichaelBell/pico-stick/releases/tag/v0.1.0

@Daft-Freak Daft-Freak marked this pull request as ready for review September 29, 2023 14:38
@Daft-Freak
Copy link
Collaborator Author

Might decide to copy the relevant drivers instead of the dependency... but probably not right now. 🤔

Anyway this should have no risk of affecting anything else now, so un-drafted. Also, claiming a more accurate format... it uh, may be named differently to the official code though...

Other branch unconditionally flushes anyway
We're not waiting for the DMA to finish before refilling the buffer. Double-buffer the batches instead
This is mostly intended as a fast-path to get existing data into the
screen Surface. With a slower fallback for lores and/or blending.
@Daft-Freak
Copy link
Collaborator Author

Now with more blend/blit fixes/improvements for https://github.com/Daft-Freak/Pico3D/tree/picovision (Also need the "special blit" patch for DaftBoy)

@Gadgetoid
Copy link
Contributor

Are there .blit builds for PicoVision anywhere, or was that too borken?

@Gadgetoid
Copy link
Contributor

Patch for Geometry to support the 8bitdo Zero 2 (ie: re-enabled and tweaked joystick support that totally doesn't allow 32blit users to press the dpad and joystick at the same time noooo)-

diff --git a/examples/geometry/geometry.cpp b/examples/geometry/geometry.cpp
index 970dc8e..7178619 100644
--- a/examples/geometry/geometry.cpp
+++ b/examples/geometry/geometry.cpp
@@ -415,12 +415,12 @@ void update(uint32_t time) {
 
     if (pressed(Button::DPAD_LEFT))  { player1.rotational_velocity += rotation_speed; }
     if (pressed(Button::DPAD_RIGHT)) { player1.rotational_velocity -= rotation_speed; }
-    //player1.rotational_velocity -= joystick.x * pi / 720;
+    player1.rotational_velocity -= joystick.x * pi / 1440;
 
     if(player1.energy >= MOVEMENT_COST) {
         if (pressed(Button::DPAD_UP))    { movement.y -= 0.03f; }
         if (pressed(Button::DPAD_DOWN))  { movement.y += 0.03f; }
-        //movement.y += joystick.y / 10.0f;
+        movement.y += joystick.y / 40.0f;
 
         if(pressed(Button::DPAD_UP) || pressed(Button::DPAD_DOWN)) {
             player1.energy -= MOVEMENT_COST;

@Daft-Freak
Copy link
Collaborator Author

Are there .blit builds for PicoVision anywhere, or was that too borken?

Should still be over here: https://github.com/Daft-Freak/32blit-beta/tree/picovision-and-everything-else (if I didn't break it). It's stuck behind an uh, somewhat large API refactor...

Patch for Geometry to support the 8bitdo Zero 2 (ie: re-enabled and tweaked joystick support that totally doesn't allow 32blit users to press the dpad and joystick at the same time noooo)-

... or press Up + Select for 5 seconds (Left + Select to undo, super-well-documented feature 😆)

@Gadgetoid
Copy link
Contributor

... or press Up + Select for 5 seconds (Left + Select to undo, super-well-documented feature 😆)

Wait is this a feature of the controller or the build? 😆

@Daft-Freak
Copy link
Collaborator Author

The controller, it's hidden in the FAQs. (Can also map to the right stick, not that that is useful here)

Of course, I found that detail after writing a bunch of code to remap...

@Daft-Freak Daft-Freak merged commit eb56a53 into 32blit:master Oct 19, 2023
9 checks passed
@Daft-Freak Daft-Freak deleted the picovision branch May 31, 2024 11:16
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

Successfully merging this pull request may close these issues.

2 participants