Difference between revisions of "Talk:Who's Cuter"

From Pin Eight
Jump to: navigation, search
(0xabad1dea: new section)
Line 81: Line 81:
Is [http://forums.nesdev.com/viewtopic.php?p=141464#p141464 this] a genuine proposal for a new revision of Who's Cuter? --[[User:Eighty5cacao|Eighty5cacao]] ([[User talk:Eighty5cacao|talk]]) 19:47, 19 February 2015 (UTC)
Is [http://forums.nesdev.com/viewtopic.php?p=141464#p141464 this] a genuine proposal for a new revision of Who's Cuter? --[[User:Eighty5cacao|Eighty5cacao]] ([[User talk:Eighty5cacao|talk]]) 19:47, 19 February 2015 (UTC)
:It was as of March 30, 2012, but not enough #nesdev members were willing to provide self-portraits. --[[User:Tepples|Tepples]] ([[User talk:Tepples|talk]]) 03:38, 22 February 2015 (UTC)

Revision as of 03:38, 22 February 2015

Refusing to pick either

My conservative aunt tried this once. When faced with Al Gore vs. Marilyn Manson: "I'm not drinking the Kool-Aid; I'm not picking either one." Plus she didn't know when it would end. The progress bar thing I agree with, but I guess it might happen occasionally when both are so disgusting that the player refuses to pick either. --Tepples 17:12, 6 November 2011 (MST)


Split from here

I can confirm that the new build fixes the flickering issue I reported in the old build. Eighty5cacao 13:25, 7 November 2011 (MST)

Thanks for testing. I've got a new build out at the same URL with a few more changes: switched to merge sort for 15-20% fewer pairs, added a progress bar, and experimented with a clearer art style. --Tepples 13:52, 7 November 2011 (MST)

The only person

Am I really the only person ever to send you results from Who's Cuter? Or did I misunderstand the article?

Notwithstanding emails that may have been lost by Spamcop or other providers, my hypothesis for the poor response rate is that many people downloaded the ROM image from less-legal sites which do not supply the documentation from your official distribution package. (It doesn't help that Cowering misspelled your surname as "Yeppick" or "Terrick," either.) Since they're unlikely familiar with your other works, they wouldn't know how to contact you.

Hence my next enhancement request: Consider displaying some form of contact information at the end of the results, or failing that, on the title screen. Eighty5cacao 23:19, 8 November 2011 (MST)

Yes, you're the only person who has sent results. But a problem just as big as the contact information is how to copy the rankings out of the NES and into the e-mail client. I don't think people are going to want to have to copy out a 32-character password, and UNROM doesn't normally have a .sav file unless one adds the circuit from Family BASIC. As for the "Yeppick" problem, Nova continues to tease me about it. This is part of why I settled on one font used in every recent NES release of mine save LJ65. I think the name "Damian Yerrick" on the title screen is written clearly enough; would you agree? --Tepples 11:10, 9 November 2011 (MST)
To clarify: As of GoodNES 3.10 (IIRC), "Terrick" applies to Who's Cuter. "Yeppick" was the misspelling Cowering used for your Nibbles homebrew. I seem to recall the latter stemming from a misreading of a font resembling half-uncial script, but upon reading that Wikipedia article, I'm not sure that half-uncial is the right term.
I agree that the current fonts are satisfactorily legible. Eighty5cacao 11:59, 9 November 2011 (MST)
Insular is probably the closest description of the style of type used in my project template from the Nibbles era. I abandoned Nibbles when I found that Super NeSnake 2 was doing the same thing but better. --Tepples 12:07, 9 November 2011 (MST)

Back to the first question: So if I am the only person to send you results, then who are the people who mixed up Hanson and Manson? Were you referring to tests that you witnessed personally? Eighty5cacao 12:40, 9 November 2011 (MST)

Yes, there were some in-person tests. I'm working on a few changes to the build process, specifically the compression, before I put up another test ROM. --Tepples 14:09, 9 November 2011 (MST)

The build with CHN

I've got a new build introducing three new technologies codenamed CHN, PB8, and VWF.

  • CHN: Don't store identical tiles of a portrait twice. It's like CHARlie and CHR2NAM, except with a clever way of storing runs of unique tiles and runs of repeated tiles.
  • PB8: Compress a portrait one tile at a time; later this will let me decompress one portrait while the other is displayed, taking full advantage of merge sort's tendency to repeat cards.
  • VWF: Draw the name of a character in small text next to the portrait.

Anyone want to give it a try? --Tepples 20:46, 16 November 2011 (MST)

Ok. Expect results around the middle of this coming Saturday. Eighty5cacao 22:15, 16 November 2011 (MST)
Cross-posted from User:Eighty5cacao/misc/Who's Cuter results#19 November 2011: Possible bug: In the "now the whole lineup" section of the results display (i.e., the graphical display after the text), the progress meter is visible showing 95%. (The exact number may vary between tests, but I was too lazy to repeat the test just for this.) Logically, it should either display 100% or not display at all. Eighty5cacao 13:29, 19 November 2011 (MST)
You're right that I should hide percentage during lineup review; thanks for this suggestion.
Why didn't it reach 100% during the test? When the program starts, the data comes sorted to roughly my own tastes; you're re-sorting them to match yours. And in a merge sort, the bottom half (stuff that I consider ugly) and the top half (stuff that I consider cute) are sorted separately, and then the two halves are merged. So if the incoming data is nearly sorted to begin with, the last pass will stop early.
Why is it so easy to manipulate? For much the same reason: the ordering from ugly to cute is precisely the order in which characters are selected in the last pass. Notice how much of the last pass is down presses because you share my most of my tastes: ugly half as ugly and cute half as cute. And it feels easier to manipulate for much the same reason: the ordering from ugly to cute is precisely the order of the not-displayed characters in the last pass. I can randomize this a bit by shuffling the rankings before the test begins. Is this needed? --Tepples 19:04, 19 November 2011 (MST)
I was unaware that the program did not already pre-shuffle the items before the test questions; sorry for not reading your source code. I would strongly prefer for this to be implemented. In this case, please disregard my suggestion for two or three extraneous swaps. Eighty5cacao 19:20, 19 November 2011 (MST)

Decorate and sort

In private testing with family, the switch to merge sort and the progress bar helped fight user fatigue. But there are log(32!)/log(2) = 117 bits of information in a permutation of 32 elements, and as long as we're sorting with comparisons, we can't get more than one bit per pair. (Here, merge sort is no worse than 10% inefficient.) The only way to beat 120-odd comparisons on a randomized initial condition is by start by gaining more than one bit per user action, that is, some variant of bucket sort. But to use this, we first need to decorate the elements by gathering some sort of machine-comparable cuteness metric carrying more structure than the total order that comparison sorting uses. I thought about letting the user rate each picture 1–5, but then I remembered why YouTube switched from a 1–5 range to a binary like/dislike: people would almost always choose 1 or 5. Thoughts? --Tepples 11:47, 24 November 2011 (MST)

Perhaps decorating with 1–3 (or equivalently "cute/neutral/ugly") might be acceptable? Eighty5cacao 16:54, 26 November 2011 (MST)

Digression (test builds)

You mentioned "randomized initial condition" — does this mean you have accepted my last enhancement request? (Comments on the rest of this section to come later) Eighty5cacao 12:09, 24 November 2011 (MST)

Yes. New build --Tepples 11:52, 25 November 2011 (MST)
Two bugs, one of which is a blocker (hence I have no test results to post):
  1. The program is entirely unresponsive to the up arrow.
  2. When the program starts, the first thing it displays is a picture of Big Bird near the upper-left corner of the screen, with the rest of the screen filled by garbage tiles that look like dashes. Pressing A at this point proceeds to the expected "Pin Eight Presents..." text.
I have tried both Nestopia (1.40.1-IndyFix5) and CaH4e3's FCEU-mm (8 Nov 2011 build) and exactly the same symptoms appear in each. Eighty5cacao 13:32, 26 November 2011 (MST)

Why is the ROM smaller? More efficient graphics compression combined with a more compressible art style. I noticed that only 56 KiB of the 128 KiB PRG ROM was in use, so I rearranged things to cut out half the file size.
Why Big Bird? It was a test screen to make sure CHN was still loading correctly after some changes I made for incremental drawing, and I had forgotten to turn it off.
Why does up not work? An oversight on my part; thanks for finding it. Because I had left my PowerPak at a relative's house on Thanksgiving, I didn't do as thorough of a job at smoke testing as I ordinarily do before putting out a build. Fixed in a new build at the same URL. --Tepples 16:06, 26 November 2011 (MST)

Done. No bugs noted. Eighty5cacao 12:36, 27 November 2011 (MST)
And thanks for the Zarro Boogs report. Now I just have to get more people on IRC to send me pics. --Tepples 19:38, 28 November 2011 (MST)


If I aggregated people's rankings, I could build a global ranking using single transferable vote, Borda count, or Condorcet count. Or I could use it to match people who are fans of similar art styles. But then that'd need some way to submit rankings electronically. I think I could have it show a 2D barcode at the end, which the player could photograph or screenshot to submit rankings. But then I'd need to figure out how to encode Reed-Solomon forward error correction on a 6502. --Tepples 11:47, 24 November 2011 (MST)

I think you mentioned the possibility of replacing some of the characters who are included in the test; we should probably finalize that first. Eighty5cacao 12:07, 24 November 2011 (MST)
I'd probably adapt the QR code generator by translating ZXing to 6502 asm if possible.
As for finalizing the roster, technically I could add more characters. At my current bitrate I could have 56 peoples in a 128 KiB cart. But practically, they'd take a bit over twice as long for the user to sort through, and 32 characters are already pushing the fatigue limit. This leaves me with either of two ways to proceed: keep all and add the Family BASIC backup circuit (for which a flag exists in iNES), or cut some. But whom would I cut?
I'm almost starting to think the NES is the wrong platform for this, that something web-based like the old whatsbetter.com would be a better platform for research. --Tepples 21:17, 26 November 2011 (MST)
Let's just take some time to think about it. The current roster is more or less fine (though the term "research" is a bit vague). At least, the size of the roster can remain the same. Eighty5cacao 22:34, 26 November 2011 (MST) (last edit 12:39, 27 November 2011 (MST))


I've thought of a way to make the sorting faster: ternary comparison. If I present two pictures to the user, there are two possibilities for their order. When the user chooses one of them, he eliminates half of these orders (log(1/2) / log(1/2) = 1 bit). But if I present three pictures, there are six orders. When the user chooses one, he eliminates two-thirds of these orders (log(1/3) / log(1/2) = 1.58 bits). In theory, there is enough VRAM to show three pictures much of the time, with the larger one on top. But I'm not entirely sure how many comparisons this would save.

There's another way to take advantage of nearly sorted incoming data, using much the same principle as timsort. First make one pass of bubble sort to find sub-runs that are already sorted, then merge those runs. That would help if I went back to starting from a semi-sorted state with my own preferences in it. But as you said earlier, this might bias the test a bit. --Tepples 12:28, 19 December 2011 (MST)

Can you explain a bit more how such an user interface would be controlled via the NES controller? That is, which buttons do what? Eighty5cacao 14:06, 19 December 2011 (MST)
Top: choose pic at top center. Left: choose pic at bottom left. Right: choose pic at bottom right. Use of timsort wouldn't need any UI change, just as the change from shell to merge didn't. --Tepples 14:32, 19 December 2011 (MST)
I first read your top-level post the right way, then the wrong way. I ended up misunderstanding that the user was supposed to rank all three pictures of each displayed set. I would have made some comparison to the A, B, and C buttons of the Genesis controller, but I wasn't sure how not to make it sound whiny. Eighty5cacao 18:57, 19 December 2011 (MST)

You said "larger one on top"; does that imply a need to store two versions of each picture, with a larger size for use in the top position and a smaller size for not-top? Or am I misunderstanding yet again? Eighty5cacao 14:20, 21 December 2011 (MST)

Either a picture is small or it isn't. Any picture that's no wider than 112 pixels and with no more than 96 distinct tiles is small. This includes roughly half the pictures: Al Gore, Big Bird, Bomberman, Bugs Bunny, Cacodemon, Davros, Jar Jar Binks, Jeanie Tomaini, Lara Croft, Lego, Marilyn Manson, Natalie Portman, Parappa, Pinocchio, Toad, Winnie the Pooh, and Yoshi. The idea is that I could somehow rearrange the early rounds to have two small and one big where possible; it'd end up a radix sort instead of a merge sort. --Tepples 19:45, 21 December 2011 (MST)
I guess I didn't think of that because 1) it might also bias the test a little bit, and 2) the above "56 peoples" comment about storage space. Eighty5cacao 21:11, 21 December 2011 (MST)


Is this a genuine proposal for a new revision of Who's Cuter? --Eighty5cacao (talk) 19:47, 19 February 2015 (UTC)

It was as of March 30, 2012, but not enough #nesdev members were willing to provide self-portraits. --Tepples (talk) 03:38, 22 February 2015 (UTC)