Sorry for the confusion haha, I meant have you made a text renderer, using trails? The text renderer I showcased uses “trail art” letters. The blue backgrounds for the links are actually the only objects except for the buttons.
Here is a small game I made. I probably wont update it anymore because I don’t know what else to add. I did think of maybe a tournament mode where you try to win as much matches as you can before you lose. But If anyone has any suggestions for it, I’ll gladly add it because it’s honestly just fun to code this game.
#1 is a bit easier to follow, and #2 has detailed information that #1 had left out.
With some notes on changes I’ve made to make it work in Hopscotch, the general process of creating a QR code goes as follows:
Take the user input, and convert it all into binary. This needs to be in UTF-8, so that means emojis and other 2-byte characters actually take up 4 bytes. Converting to UTF-8 requires you to pair high and low surrogate bytes, then convert them to binary, whereas other 1-byte UTF-16 characters are easier to convert to UTF-8.
Choose a version number (uses the minimum version that can support the amount of bytes needed). You must do this after converting to binary because some characters that are 1 byte in UTF-16 may be several bytes in UTF-8 (lengths are variable).
Put the binary data into segments. I’ve opted to only use one segment to keep things simple, and this segment is in binary mode, so it does not have a limited character set. This allows me to put all user input into the QR code, though it has the drawback of not being perfectly optimized. (A fully optimized QR code generator would be able to store more information)
The single segment should take up all space in the given QR code version, so I add padding to the data.
Split the segment into blocks, whose size and count are predefined and associated with each QR code version.
Create error correction codewords (ECC) for each block separately (see notes below). Since this may affect multiple blocks, I use clones to run this operation in parallel.
Draw the fixed patterns (finder squares, timing patterns). Usually, you would also draw alignment and version information patterns here, but that would require a more complicated method for drawing the data and error correction bytes later.
Because I did not draw alignment or version information patterns with the fixed patterns, I instead hardcoded their positions in the binary data and inserted them using the clones I’ve already created. They are inserted back to front so that the next insertion index does not change. So, alignment and timing patterns are drawn with the data bytes and ECC.
I draw the data patterns with Mask #2 since it is based on columns only. Drawing occurs in a zigzag shape, so I needed to determine the start index of each column (i.e. 0, 1, 24, 25, etc.) and its size, then draw every other byte in that range (since going up or down requires two columns due to zigzag shape).
More info on generating Error Correction Codewords/bytes:
These typically require generating a polynomial to used to calculate the bits, depending on the number of ECC needed. The number of ECC needed per block depends on the QR code version, but since that is finite, I just ran the polynomial generation function outside of Hopscotch and pasted the results in this project. This allows me to get data from the polynomial without having to generate it.
After that, I recreated the simplified script in this project.
More info on drawing the patterns:
In columns with a finder pattern, data is drawn forwards going up and backwards coming down. Then, finder patterns are added at the beginning and end of the string.
In columns without a finder pattern, data is drawn forwards for all rows. Each row has a break due to the horizontal timing module; since this is 7 modules from the top, I either break the drawing after 6 or “size - 6” bytes to draw it. Then, I draw the rest of it and flip modules that have data flowing from top to bottom.
The vertical timing module is a constant checkered pattern and is thus constant for every version. This is the first column that appears when you tap on Generate.
Nope, changing actual resolution makes no difference, neither does emulating a different device.
edit: i’m assuming this isn’t intended
Uncaught ReferenceError: main is not defined
at HTMLAnchorElement.playHandler (application-a645945a26d70ea57fbb5caeee798582e0a9d60e378254c7ce7386e62c154e29.js:36105:31)
playHandler @ application-a645945a26d70ea57fbb5caeee798582e0a9d60e378254c7ce7386e62c154e29.js:36105```