@@ -502,7 +502,7 @@
Code Updated. Check the github link to keep up.
@@ -502,7 +502,7 @@
Code Updated. Check the github link to keep up.
@@ -581,6 +581,332 @@
just filling the rest of the perk data (and fixing whatever is
wrong with the action girl image) and presto, that's a screen!
+ Code Updated. Check the github link to keep up.
+ + OK I lied did a tiny bit more tonight. It's some housekeeping + code - I wanted to make sure the images displayed centrally if + they were cropped to just their actual data, any rows of empty + pixels around them removed. +
++ This turned out to be a smart decision - It saves space, it + looks nice, and it meant I redid the action girl icon with its + bit of corrupted data, a bug I would have otherwise inevtiably + ignored until the end. No photos right now because not much has + actually changed but it's good and sets us up for just + implementing the manual selection now. +
++ Good morning! I'm up bright and early to continue my vital work. +
++ Actually, I've already started. I looked up what the perk menu + looks like in Fallout 4 to check if there a) is one other than + the chart (there is) and b) if what I'm making is accurate to + that. +
++ And it mostly is, but the selection box around the perk in the + list is actually all green and the text is black, see the below + image. +
+ +
+
+ + So I kinda want to recreate that. Doing so would be useful as + it'll also bring my selection menu in line with some of the + official submenus on the device as well, making the app look + more official :) +
++ This is what I've got so far - I couldn't get the text to draw + in black so I settled on a halftone selection box instead. I'm + still not completely happy with it though and want to get as + close to accurate as I can, so I'm going to dive into the + firmware and see if I can divine how it does the black on white. +
+ +
+
+ Code Updated. Check the github link to keep up.
+ + Ooookay, a lot has happened since I said I'd check the firmware. + Here's the current state of the screen: +
+ +
+
+ + So, like I said, I dove into the firmware code. I found quite a + lot of interesting stuff in there while trying to figure out how + they did the black on white textbox. Let's run through. +
++ Top of the order - there are three foreground colours the pipboy + can draw in, 0-3. These are actually different brightnesses of + the pixels. So drawing a fullbright pixel is colour 3, an off + pixel is colour 0, but there's also colours 1 and 2 which are + slightly dimmer on colours! +
++ This is how the fading 'Attachment' and 'Aid' labels at the top + are drawn, although it's not very clear in the photos I've + taken. +
++ I actually discovered this by accident - I saw a setColor(0) in + the firmware and deduced that was black, so then I added that in + to my drawing code - but in so doing I also set the colour of + everything not black to setColor(1), which made everything + dimmer. +
++ This was a bit of a eureka moment - I'd figured out that there + were roughly 4 colours displayed on screen but earlier assumed + this was all dithering after my experiments a few days ago. + Turns out I was right all along! Ha-HA! +
++ So, using this new knowledge, I've added correct coloring to + everything. I've also chosen to dim the perk image a shade and I + think it makes it look really good. The full brightness was + overpowering some of the details of the icons. +
++ While digging, I also found an interesting function call: + setFontMonofonto18(). This was a call on the graphgics context + and was pretty self-explanatory. +
++ The thing is, I'd noticed my fonts were a bit off. They weren't + as tall as they should have been. Turns out, that's because + there's a custom font in use, but only when you specifically set + it. So because I was just using setFontVector() instead of these + Monofonto calls, the font was getting set back to the default + Espruino vector font. +
++ Ctrl-F-ing 'Monofonto' in the firmware dump showed up a few + similar calls, listed here for convenience: +
++ I assumed Monofonto was the font name, and tried to plug it in + to a few of the Espruino font functions, but got errors each + time, which was troubling. Giving it a quick duckduckgo + presented an excellent result: + DaFont Monofonto. + Turns out the font used on the pip-boy (and presumably in the + actual game!) is freely available to download. Perfect! +
++ With that in hand, I looked at the Espruino setCustomFont call, + and with a smidge more docs digging I found + this page + that converts a font and size into a graphics context function + call - just like the ones already in the firmware! +
++ This was perfect. I plugged in the font and set size to 14, + dropped the code in my file, and now my description is in the + correct font. I used the pre-existing setFontMonofonto18 for the + Title - 16 was proving a little too small, and other menus in + the device are size 18. +
++ I'm honestly over the moon about this. I had kind of already + settled for things not looking quite right, but with a bit of + digging, I solved basically all the imparities with the games. +
++ What that isn't, though, is input. Which was the title of this + update (I've changed it now). So I'll tackle that next! +
++ OK we're back again baby. And this time I swear I am going to do + input. To show willing I've even already started diving into the + firmware to work out how it's done! +
+ +
+
+ + So that firmware screenshot tells us all we need to know, + really. The Pip object has some events (in this case, 'knob1', + which is a) funny and b) the left hand wheel control) one which + you can register functions to call. +
++ This screenshot is from the portion of the code that handles + switching between the different health animations, but this + applies anywhere really. So what we need to do is: +
+Pretty simple! OK, lets go do that.
+ Code Updated. Check the github link to keep up. +And look at that! We're done.
+ ++ Nothing really special to talk about here, just some basic + increment/decrement handling and looping back to the start of + the list when necessary. +
++ There is a specific wrinkle of having to deregister the input + event. Early on in my testing I hadn't done that and it kept the + .js loaded even after removing the SD card, which meant it + looked like any edits I made weren't actually working. In order + to prevent this I added gracefulClose() which deregisters the + handler and shows the main menu again. +
++ Last thing here is really to handle what happens when we have + more perks than will fit in our available space. Then this + screen is basically done! +
+ Code Updated. Check the github link to keep up. ++ And now that's done too! Couple of bugs with loading the right + files to list (primarily loading too many) but smart use of the + modulo operator and we're done! I filled in every perk I think + is funny and applicable to me, did some manual edits to some of + the icons (new vegas icons seem to generally be less optimised + for a real monochrome display, a rare instance where Bethesda's + attention to detail is better than Obsidian's) and filled in all + their data and, well, that's it! +
+ ++ I'm pretty happy with it! This was a really enjoyable project + and let me flex a lot of the muscles I don't tend to use a lot + in my pure software day-to-day. +
++ I might come back to this later and make a second screen with + stats on it, but that's basically the same layout etc as the + perks screen just with a number, so I probably won't write it + up. +
++ So yeah, for now, I'll leave it here. Thank you for reading and + following my thought processes, if you did! +
+ Code Updated. Check the github link to keep up. ++ OK I LIED one last update. I wanted to handle the selector on + the right moving away from INV gracefully. Until now, switching + this while in the app would do nothing, and to get around this I + had the click in of the left wheel as the 'return me to the main + menu' key. That's not very accurate to how it should work, + though. +
++ So I dove into the firmware again and after a few false starts I + found checkMode(). This is called on a timer in all the other + apps every 50 milliseconds. I experimented a little with this + timeout in my app - 50ms made the perk list feel laggy (because + I'm loading data from disk so ops take a bit more time than + everything else in the system) so I tweaked it up to 100ms, + which was a nice compromise. +
++ Twiddling the mode dial triggers a menu change, but I also made + sure to gracefully shutdown when a change was detected - this + includes running showMainMenu(), which if we don't do the + control handlers don't get registered properly. Important. +
++ I also dropped in a handler for the torch button - it does + nothing other than shutdown and activate the torch normally. + While testing this I actually found a bug with the current + firmware - if you stay on the torch page and the time changes, + the footer will display over the torch screen. Neat! +
+Anyway that is really it this time. Thanks for reading <3
++ OK I WORKED ON IT A BIT MORE but as mentioned it wasn't + particularly exciting - this actually reuses basically all the + same code, with just a smidge more for drawing the skill points. +
++ I did actually have all the skills in one big JSON but it caused + an out of memory error, so I abandoned it and went back to + individual files for each skill. +
+Anyway, here's it working!
+ ++ Final update! I added the SPECIAL screen too, and reordered the + screens to match the in-game pipboy. Finally I also did some TLC + to make the app a lot more responsive and reduce redraws, so now + it feels really snappy :) +