As accurate as @acedent’s keying 
I get that some (like the coder’s toolbox) are storing large objects in there but some of the other games really surprised me too.
Ah, sorry. I must have missed that.
I think highlighting the rows might be better as then you can visually see the clashes.
If you looked under the covers you would see that my JS and jQuery is very basic. This is a bit of a mess. I hate web work as a rule.
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.
My knowledge of jQuery extends to the fact they decided to declare a global variable named $ (which seems a bit self-important to me), and that a fair bit of what it does can be done with JavaScript’s DOM API. I’ve never actually used it for anything, just skimmed sample code (and frowned).
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.
It allows you to add calendar entries- but obviously not many 
Everything can be done. It’s just a helper library.
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.
From what I’ve skimmed, jQuery used to be used a lot because the JavaScript DOM API used to be quite crap, but it vastly improved sometime around the EcmaScript 6 standard.
(I wonder how many people realise that JavaScript is actually an implementation of the EcmaScript standard…)
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.
However, if Akkera’s version is what’s in use, I count 11 bytes of progmem in use, from addresses 16 to 26 (inclusive). Three bytes here and 8 bytes worth of HighScoreEntry. (I mentioned this in my comment on the other thread.)
(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.
I checked the rest and so are Evade, and Arduloop.
(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.
That is flipping awesome!! Love it! 
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…
The popup is only about 1300px wide and should be visible on most normal monitors.
I do have a 4K monitor (3840px wide) so it looks quite narrow for me
Mmm … I guess so.
Yep Have done that now.
I cannot control that as its done by the jQuery library. How small is your screen?
1152 px wide… first time I’ve been screen shamed… 
Yep … sorry. How do you call yourself a lover of technology and have such a small monitor.
You are supposed to respond with a ‘its not the size but what you do with it’ sort of joke.
… 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.
Assume you mean the tool tip / alt text?
You can see that by hovering over the bar itself … but I can put it over the text as well.
This is true.
I am open to PRs
And only because I had a go at you, go and try the cart site now (you may need to refresh the browser).
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”).
Can you try it now @pharap? Are you seeing the large or small version of the popup? I have also added a scroll bar (up / down) as it was very tall.
I already tried it, hence the like on the post above.
If I look at it with a maximised window I get a horizontal scrollbar as well, and the names are a tad squashed.
(Not that that matters to me, since I probably won’t be using a maximised view anyway.)
Ah … I thought you had done that before I added the scroll bar. I had only added it moments before you posted.
Its an interesting problem with jQuery dialogues or - more likely - my understanding of them and how best to handle sizing.
I check the window’s width as I initialize the dialogues (onDocReady) but when I render the content of the dialogue (on clicking of the button), I check the window size again to see whether to use the narrow or wide rulers. If you had refreshed the page (or come into it full sized) then the second version would have worked - its a result of you resizing the window after the initial onDocReady(). Not sure best way to fix that …
I could always store the initial width away somewhere and use it when rendering the content but that seems a little backwards. Would be better to re-initialise the dialogue on clicking the button.
You could store the window dimensions and reinitialise only if they’ve changed?
It depends how expensive it is to build the dialogue I guess.
As I’ve never used jQuery, I have no idea how it goes about building/handling these things.
I don’t do web dev very often, but when I do I prefer to be very minimalist and stick to the built-in tools, so I’d typically use CSS tricks like media queries, flexboxes, using percentages for width and height or margin: 0 auto; to respond to changing window sizes.
Perhaps there’s a way you can use those to make the dialogue automatically resize itself as the window resizes?
