Perhaps a visual representation would help? Like dimming rows, and highlighting just those that clash?
Is it possible to change colours: red → reddish-orange (more yellow) and green → blue. This helps with colour blindness and also removes the misunderstanding that the hash is green for ‘good’ (it doesn’t actually fix a a collision).
No but it is good in the sense that the user will not have weird results - like ridiculously high scores when they have never actually played the game and so on. It would reinforce the ‘please look after your EEPROM use’.
Each tick is actually four bytes, not four bits. Removing every second tick results in 8 bytes - which is as meaningless as 4 bytes I guess.
Sorry… my mistake!
So your scale runs 1 to 1024 (not 0 to 1023), and each number is the decimal address in bytes +1 (max is 1024 bytes - but some bugs might exceed the available EEPROM).
This will be really useful when understanding interactions of existing games.
Would it be possible to provide a different view for developers planning to use EEPROM? Something like a heat map? Even better, the facility to enter the number of bytes to store- and be given a start address to minimise byte collisions, and ensure the address and the length, won’t collide.
Just to double-check, is Harambe’s Revenge accurate there?
Last I checked it used a system that consumed more or less all of EEPROM.
I remember there being an intent to change it to use just what it needed, but I don’t remember if that actually happened.
I had a quick look and I think perhaps Akkera might have produced a .hex with some kind of fix, which might be the one that ended up on the cart.
I must say, I’m surprised at how many titles take up such huge chunks of EEPROM. Just goes to show how futile it would be to try to prevent clashes. All we can truly do is detect and manage them.
Ultimately levelling out the wear is more important than trying to prevent clashes anyway.
It occurs to me that the rest of the world probably don’t realise you meant a vegetable and not someone from Sweden. :P
I agree with Filmote here.
It’s not worth worrying about problems that don’t exist in practice.
(At least, not when this is our spare time we’re giving up. Start paying me a wage and I’ll gladly consider every last ridiculous edge case. :P)
I said more or less the same thing to @acedent the day before:
Though I think I remember Tuxinator telling me that he was intending the player to bring their character across from the first game. I might be misremembering though.
Either way, it was never finished, and even if it were that’s still only two games. I think you’d need at least a handful to justify the additional legwork.
Yeah, there’s probably a better option than a tooltip.
I’d say some kind of pop-up window with an actual list, and then maybe make the tooltip say ‘click to see clashes’ or something?
As far as I can tell, as long as it’s red and blue instead of red and green, making the red more yellowish wouldn’t be necessary because red and blue are distinct for all three forms (tritanopia, deuteranopia and protanopia).
GitHub changed the closed marker from red to purple for a similar reason - ‘closed’ is not a bad thing.
Though I agree with Filmote that a hash is better than no hash because it lets you know when a clash has occurred, so in that respect it’s still ‘good’.
If it’s important to keep the green, then green and yellow is another pairing that would seem to be acceptable from a colourblind point of view.
You forgot to specify that the heatmap shouldn’t use red and green to indicate ‘heat’. :P
(Though actually, blue and red makes more sense for ‘heat’ anyway. Blue = cold, yellow = warm, red = hot.)
If I had all the data I and an hour or two to do it in, I could probably make a desktop tool to do something like that in Haskell, C++, C#, or Lua (take your pick). (Well, as long as that’s all you’d want it to do. No ‘one more thing…’ features.)
No thanks - getting the algorithm working would be only half the battle, manipulating the UI would be a separate battle entirely.
I really don’t envy @filmote being the one to have to do all this web UI stuff, he’s done more than I’d have patience for.
I’m going to presume the one acedent used was the one @akkera102 modified somehow, though I’m not sure Akkera made the source public.
I half understand some of the software ones using a fair bit of EEPROM, though others I wonder why they’d need it. E.g. I wonder why Calendar needs so much.
The BrainFuck one worries me slightly because I wonder if it’s using EEPROM like RAM or something.
I’m not quite sure what Chie Magari Ita is doing either.
Looking at the code, I think it might be saving entire board configurations?
I’d need some time to pick it apart, and that’s time I can’t spare this morning.
Though, based on a quick skim, if I’m reading this right, its start address should actually be 864?
Nothing to apologise for, my point was just that if we’ve both said it then it’s probably accurate. (My memory isn’t always the best.)
Possibly, though that sounds like a fair bit more effort.
Also, it depends on how many of the games are actually on-screen at the moment. Highlighting rows may not be useful if one of the games is currently on an off-screen row, whereas a popup window with a list would show only the relevant information.
Unless instead of highlighting the clashing games it hid all the non-clashing games, leaving the user with a list of clashing games? Though that sounds like it might be more difficult.
Me too. I started trying to design myself a website once and gave up shortly after figuring out how to make a ‘theme’ feature. It’s a far cry from using a desktop GUI API.
Half the problem, as far as I see it, is that the technology underlying the web is being required to do things it was never originally designed for. As far as I understand web history, HTML was really designed for things that would have originally been books or print (e.g. encyclopaedias, newspapers), not for so-called ‘web apps’. More or less everything else was bolted on top as an afterthought.
At this stage, I’d like to share the glory (and blame!) with @Mr.Blinky who did the vast majority of the analysis used to produce the original spreadsheet.
It’s very possible there are mistakes – and this data is 2yrs old now…
@Pharap - please feel free to modify the original spreadsheet with any errors, or just post here and I will try to maintain it and post fixes for the CartBuilder.
Some original discussion with the author starts here.
Presumably a calendar entry is a large blob of text or something?
I mean in a less cumbersome way than used to be the case.
The thing is I’m still not entirely sure if it is an error. I’m kind of confused about what’s what in regards to Harambe’s Revenge and need a second pair of eyes to confirm what I’m seeing.
So far I’ve managed to establish that Akkera made a version of Harambe’s Revenge (which I struggled to find because it wasn’t in a proper fork), and I’m presuming it’s that version that’s ended up being accounted for because the original was never updated.
(That possibly suggests some of the other entries in the chart using the range 16-16 might not be accurate? I.e. that these entries haven’t actually had their range counted, and that 16-16 range was a placeholder?)
Also, I’ve suddenly realised Akkera’s version of Harambe’s Revenge is using EEPROM.write, not EEPROM.update.
(For the record, this is exactly why I was against having both a write and an update on the Arduboy2EEPROM API - programmers who don’t deal with EEPROM expect to have a read and a write, they don’t expect an update function. If they don’t know any better, they’ll instinctively use write because it’s what all the other APIs have, so it’s better for that to be the right choice, or indeed for there to be no choice to make.)
Fanboat’s safe because it’s using put, and Calendar is actually using update.
Not quite as useful as you were expecting I’m afraid.
It just says that Mr Blinky accidentally overlooked that bitfields were in use, and that Obono was using a checksum (and me being pleased/impressed that someone else had attempted a checksum/hash to protect their game).
Upon a second look at the actual code I’m fairly certain that 864 is the start address, though I’ll have to sit down and calculate the size in a minute, I need to dash off for a moment.
Edit: How are the titles sorted? I presume not alphabetic – ok, it’s by start address. Would it be possible to sort by start address and then also by end address? e.g. the many collisions at 16 will the cascade better.
I also presume you have a very wide monitor! It may be worth putting the Close window ‘X’ to the left of the title… there was a moment of confusion before I scrolled to find it…
… would you consider ~900px width and a horizontal scroll bar?
Edit: using it a bit more, works fine. It would be nice to add back the text box for the selected game, showing just its start/end/hash details. Bonus feature: Add a tick box to ‘hide whales’ – anything over 256(?) bytes in size gets hidden. Currently everything seems to clash because of a few large titles.
Out of interest, is that a tablet or just a really old laptop?
My old laptop had that awkward 1366×768 resolution that would have only just fit a 1300px box.
As things currently stand I have a single 1920x1080 monitor, but I like to have my browser windows snapped to one half of the screen, making them portrait, which tends to confuse some websites.
Either way the moral of the story is that developers are hilariously prone to false assumptions (e.g. “clocks always move forward”, “people always have a forename and a surname”, “nobody uses 32-bit computers anymore”).