-
Notifications
You must be signed in to change notification settings - Fork 4
Alan/image refactor #36
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
base: master
Are you sure you want to change the base?
Conversation
Need to finish integrating into pico8. And need to expand functionality.
…ld be done, but not stdout. Refactor is because I think pico8 is behaving weirdly. With sending/receiving data. I expect it to block on serial reads but it doesn't and I expect a serial read to always return the specified amount of data, but it doesn't.
… from rust to pico8 working.
Maybe this shouldn't be merged, a bit outdated. But things could be taken from it. I'm not really working on this anymore. |
urlencoding = "2.1" | ||
scraper = "0.19" | ||
futures = "0.3" | ||
moka = { version = "0.12.10", features = ["future"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moka is a cache system. The idea is that when parsing images, we async read from the file system then cache the image in moka, so when picolauncher requests for another image, no file system read is needed and the image can be loaded quickly.
|
||
cart_dir='games' | ||
label_dir='labels' | ||
label_dir='bbs' -- TODO: currently bbs is a symlink because I want to test p8.png loading. This should not be a symlink and instead games should have p8.png files when possible since those have more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this was a hack, because I wanted to test loading actual carts instead of image files.
start_time = 0, | ||
duration = 0, | ||
elapsed = 0, | ||
frame = 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be a hack. There is a tween when loading images. Frame is needed because the protocol for getting an image takes in how many bytes to read and the offset. That's because you can't load a full image in a single frame without getting fps throttle, so the idea was, read like 1/8th of the image each frame of an animation. A new cart image could load in like 8 frames while you are doing a screen swipe animation, so it could make it look seamless especially if the image is cached.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought here was to split out image related logic into a file.
[255, 119, 168], | ||
[255, 204, 170] | ||
]); | ||
static ref EXTENDED_PALETTE: Array2<u8> = arr2(&[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Label images can actually have 32 colors. They can have extended palette colors or normal palette colors. Goal is to have a protocol that supports any colored image. The protocol could send the palette colors to pico8, and pico8 could change the screen palette to show the correct colors for the image.
Technically a label image could have an impossible image in pico8, because pico8 has a scanline limitation on the palettes, but the label does not. So it would be cool to have a protocol that does a best approximation for this extreme edge case.
No description provided.