X-Git-Url: https://fortfriendship.online/gitweb/gnargle.github.io.git/blobdiff_plain/d2b0f527920d3abcc9c2ac0bd5d2c6b4c0da1a6f..0b7bdf14a94e474a58cbccc4c1d34adddcbe785d:/projects/pipboy.html?ds=sidebyside diff --git a/projects/pipboy.html b/projects/pipboy.html index 391e2ac..c96592f 100644 --- a/projects/pipboy.html +++ b/projects/pipboy.html @@ -354,9 +354,233 @@ />
- So we want tio draw something to screen that isnt just text, + So we want tio draw something to screen that isn't just text, next. So I need to dive into some docs. More updates in a bit...
+ Code Updated. Check the github link to keep up. ++ OK, first thing I want to do is draw a square. Which means we + need to understand how the graphics buffer is working. See, + right here, in the dump of the buffer of the main portion of the + screen, is some interesting evidence. +
+ +
+
+ + The interesting thing here is 'UInt8.' This is an array of 8bit + integers. This could mean the pixels are rendered as 3-byte RGB + values, with the r and b just ignored, or it could mean each bit + in the byte is a pixel, and the different tones is achieved + using dithering. Right now, I'm not sure! +
+So, to find out, we're gonna draw three squares.
+ +
+
+ + And there we have it! Three squares. Now if we look at the code + I've written, and note that the middle square is the dimmest of + the three, we can deduce... +
+ +
+
+ + That I was completely wrong and the screen is compeltely + monochrome, and any dimming is done by dithering. I'm so glad + I'm liveblogging this so everyone can see how stupid I am. +
++ That's ok though! We're here to learn, and this actually makes + things relatively nice and easy. I'm sure there are monochrome + image -> uint arrays somewhere out there one the web already, + thisn is a very common format on embedded platforms, so I just + need to find one and run the icons for various perks etc through + them, and we can get one displaying. +
+In fact, maybe that's what we do next. BRB...
+ Code Updated. Check the github link to keep up. ++ Excellent, here's one, first hit on google. + image2cpp + Let's run the Cherchez La Femme image through it and upload it + to the machine aaaand... +
+ +
+
+ + So, that's not good. In fairness, I am loading a 167x167 bitmap + into memory here, I suppose it makes sense that that wouldn't + exactly work. But it is going to make this more difficult. +
++ Next question then. What is a reasonable maximum array size we + can use here? Time to experiment. We'll start with half the + resolution, 83x83. +
+ +
+
+ + OK, it's displaying, but that's clearly not right. Here's what + it's supposed to look like: +
+ +
+
+ + That's ok though, there's options on the converter for just this + predicament. This was the default (Horizontal - 1bpp), and + Vertical - 1bpp landed similar results, so let's move on from + that converter and use the one hosted on + Espruino's website + instead. Man I'm really proving myself soooo smart today. +
++ Using the right tool for the job gives us this! And it's even + full resolution! Huzzah! +
+ +
+
+ + OK, that's real, genuine progress. We can encode images and + display them, which we need for the perks screen. They are + pretty big though, so I think next order of business is going to + be keeping those strings in text files and loading them in when + we need to. Back to the docs... Although I might leave it there + tonight, my back hurts. No wonder Zuck had to be 19 to do this + live. +
+Evening! Let's get right back to work.
++ Yesterday, we figured out how to correctly convert and display + an image on the screen. Today,we're going to figure out storing + those images, loading them at runtime, and switching to another + image later. +
++ So, first up: storing and loading the image. This is gonna need + me to look up how the espruino fs library works. BRB... +
+ Code Updated. Check the github link to keep up. + +
+
+ + Well that was tremendously easy. First try baby, finally I'm not + completely stupid about something! We're gaming! I would take a + photo of the screen but I didn't change the image's position so + it looks exactly the same. but rest assured it is there! +
+OK, next up, we swap images on the fly.
+ Code Updated. Check the github link to keep up. + ++ Done! Again! Wow we're going win after win today. Apart from the + weird bit of artifacting in the top left of the image there, + but, er... I'm sure that's fine. Let's ignore it for now. We'll + see if it continues with other images. +
++ OK, so this is actually a fair cut through the work we need to + do here. So let's structure the screen a bit, and add the name + and descriptions. +
+ Code Updated. Check the github link to keep up. ++ Hoooo boy I spent a while here huh! So much for 'live' blogging. +
+ +
+
+ + While I've been gone I basically drew the rest of the fucking + owl. Look! It's the screen from the game! Pretty much + completely! +
++ There's some artistic license; in-game the perk description + displays in the same column as the image, but the available area + there is too small to display it readably on screen, so I've + bannered it at the bottom instead. +
++ But yeah, we've got the basics of the screen here! The list of + perks, the box around the selected one, the image, the + description. They're all loaded dynamically from the list of + files on the SD card, and I've just gone in and tested the + reselection with a timeout, and hot damn, it works. +
+ +
+
+ + Additionally, if you're code digging, you'll see I've done a + bunch of reorganisation. While I was hacking before, I've gone + in and refactored and made all of this actually functionally + useful for building up the application proper. +
++ Next thing, then, is input. Which hopefully, shouldn't be too + bad? I'll tackle that at some point over the weekend. Then it's + just filling the rest of the perk data (and fixing whatever is + wrong with the action girl image) and presto, that's a screen! +