16
Thumby / Re: Sudoku v1.0 by AirConsole
« on: October 28, 2021, 05:03:52 PM »
I think the QR code is even more out of place than the ad, but each to one's own.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: 1 2
17
Thumby / Re: Sudoku v1.0 by AirConsole
« on: October 27, 2021, 08:05:29 PM »
Really great content to file size ratio and very efficiently written, though I do think it's a bit much to have an "ad" pop up every time the user wins a game. In my opinion at least, a short message on the title screen or a credits menu would be more presentable.
18
Thumby / Template Function for Static Animations
« on: October 23, 2021, 02:11:17 AM »
As I was adjusting the function that animates the "Select Speed" text in NanoMem, I thought that creating a template for it might be helpful should others want to replicate the functionality. While I currently only use it for upwards, vertical animation, the template below has aspect ratio and directional input variables that can be set to choose which of the four animation types is being used. Perhaps at some point a page could be created to compile templates for various functions as to make the game creation process simpler for those doing so for the first time.
While I tried to name the input variables in a way that makes sense, I'll give a brief description of each below:
- line_count: The number of lines, vertical or horizontal, in the frame of animation.
- line_length: The number of pixels long that each line is.
- total_line_count: The total number of lines that the animation cycles through.
- x & y: Coordinate that the highest or leftmost line of the animation would be "blitted" at.
- aspect_ratio: If the animation is vertical, this should be set to 0, while if it's horizontal, this should be set to 1.
- direction: If the animation goes rightwards or downwards, this should be set to 0, while if it does leftwards or upwards, this should be set to 1.
- speed: The time in milliseconds between each frame of animation.
The main purpose for animating with lines rather than whole frames is not only because the lines can be reused each time the frame is redrawn, but also because the lines themselves are often the same, especially when the the line length is short. For instance, while my "Select Speed" animation in NanoMem cycles through 90 lines, as each line is only three pixels long, the data for the lines can be referenced from an array of only seven 1x3 pixel bitmaps, avoiding the excessive use of storage space. If anyone interested in using the template has any questions, I'll be glad to answer them below.
While I tried to name the input variables in a way that makes sense, I'll give a brief description of each below:
- line_count: The number of lines, vertical or horizontal, in the frame of animation.
- line_length: The number of pixels long that each line is.
- total_line_count: The total number of lines that the animation cycles through.
- x & y: Coordinate that the highest or leftmost line of the animation would be "blitted" at.
- aspect_ratio: If the animation is vertical, this should be set to 0, while if it's horizontal, this should be set to 1.
- direction: If the animation goes rightwards or downwards, this should be set to 0, while if it does leftwards or upwards, this should be set to 1.
- speed: The time in milliseconds between each frame of animation.
Code: [Select]
def animate(line_count,line_length,total_line_count,x,y,aspect_ratio,direction,speed):
current_line=0
line_limit=total_line_count-1
while aspect_ratio==0:
if direction==0:
frame_edge=y+line_count
line_switch=lambda a,b: a-b
elif direction==1:
frame_edge==y
line_switch=lambda a,b: a+b
while(1):
if current_line>line_limit:
current_line-=current_line
for i in range(line_count):
if current_line+i>line_limit:
prevent_overflow=line_limit
else:
prevent_overflow=0
thumby.display.blit(line_set[current_line+i-prevent_overflow],x,line_switch(frame_edge,i),line_length,1)
thumby.display.update()
wait(speed)
current_line+=1
while aspect_ratio==1:
if direction==0:
frame_edge=x+line_count
line_switch=lambda a,b: a-b
elif direction==1:
frame_edge==x
line_switch=lambda a,b: a+b
while(1):
if current_line>line_limit:
current_line-=current_line
for i in range(line_count):
if current_line+i>line_limit:
prevent_overflow=line_limit
else:
prevent_overflow=0
thumby.display.blit(line_set[current_line+i-prevent_overflow],line_switch(frame_edge,i),y,1,line_length)
thumby.display.update()
wait(speed)
current_line+=1The main purpose for animating with lines rather than whole frames is not only because the lines can be reused each time the frame is redrawn, but also because the lines themselves are often the same, especially when the the line length is short. For instance, while my "Select Speed" animation in NanoMem cycles through 90 lines, as each line is only three pixels long, the data for the lines can be referenced from an array of only seven 1x3 pixel bitmaps, avoiding the excessive use of storage space. If anyone interested in using the template has any questions, I'll be glad to answer them below.
19
Thumby / Option to Turn the Thumby Emulator Sideways
« on: October 22, 2021, 12:28:13 PM »
As I wrap up major updates to NanoMem, in considering which idea from my "High Likelihood of Adequate Functionality" list to work on next, I've decided to try to implement NanoBird, my mockup of a Flappy Bird demake. As my mockup assumes that the user has the Thumby held sideways for the purpose of having a tall aspect ratio (which is also the case for several of my other demake mockups), I was wondering if it would be possible to implement an option to emulate the Thumby tilted sideways, with the arrow keys remapped accordingly? All my mockups assume that the Thumby would be tilted with the D-Pad on the bottom, though in case anyone else has an idea that would have the device flipped the other way around, perhaps the option for Thumby emulation tilted in either direction would be helpful.
20
Thumby / Re: First Finished Build of NanoMem
« on: October 22, 2021, 06:00:48 AM »
Thanks! While having extra bitmap data comes at the cost of some storage space, I think that it's worth it to have a bit more polish in terms of a game's presentation. Might as well make the most of the resolution that there is!
21
Thumby / First Finished Build of NanoMem
« on: October 21, 2021, 11:29:23 PM »
To try to learn some of the basic functions of MicroPython in order to work on the more complex ideas I had, I adapted the font-based Thumby memory game TinyMem to use bitmap data instead. While I added sound functionality that I think should work and began working on high score saving by writing to a text file, since the emulator doesn't support those functionalities, I'll have to finish implementing them when my Thumby arrives. Otherwise, the game is pretty much finished, but let me know if there's anything that could be done to reduce the file size or otherwise improve the efficiency of the various functions. While the attached commented version of the program is 11KB, as it's only 9.5KB with the comments removed, hopefully with a bit more work it can go down to 7KB or so. Making additional use of the new sprite mirroring functionality would have helped in this regard, though as it seems that sprites are often corrupted via this method, for now I'll just have to make do with having extra bitmap data.
Should anyone want to collaborate with one of their ideas or one of my game mockups (such as potential Pac-Man, Calculator, Flappy Bird, and 2048 ports, among others), I'd be glad to do so! If so, perhaps a temporary Discord group or something could be setup until there's an official server. While I still much prefer the graphical, rather than technical, element of this game making process, hopefully that that will improve with a few more games.
Edit: Made a few modifications to improve performance.
Edit 2: Tried to divide the circle into eight sprites that could theoretically be reduced to one if sufficiently mirrored and rotated, but a function that does that automatically would be necessary to avoid the added Blit functions removing any benefit gained by the reduced bitmap data.
Edit 3: While I've primarily moved on to working on NanoBird, if there's anything else that needs improved with NanoMem feel free to let me know. Version 1.3 is slightly bigger than Version 1.2 as it updates the number display function to enable the centering of the "Round X" number.
Should anyone want to collaborate with one of their ideas or one of my game mockups (such as potential Pac-Man, Calculator, Flappy Bird, and 2048 ports, among others), I'd be glad to do so! If so, perhaps a temporary Discord group or something could be setup until there's an official server. While I still much prefer the graphical, rather than technical, element of this game making process, hopefully that that will improve with a few more games.
Edit: Made a few modifications to improve performance.
Edit 2: Tried to divide the circle into eight sprites that could theoretically be reduced to one if sufficiently mirrored and rotated, but a function that does that automatically would be necessary to avoid the added Blit functions removing any benefit gained by the reduced bitmap data.
Edit 3: While I've primarily moved on to working on NanoBird, if there's anything else that needs improved with NanoMem feel free to let me know. Version 1.3 is slightly bigger than Version 1.2 as it updates the number display function to enable the centering of the "Round X" number.
22
Thumby / Re: Font size
« on: October 21, 2021, 03:21:00 PM »
Not quite done with it yet, but here's NanoMem (adapted from TinyMem), which uses the functions I listed to keep track of the current score and how many inputs there are left to enter.
23
Thumby / Re: Font size
« on: October 21, 2021, 01:33:01 PM »
I'll have to see if I can adapt it for use with text rather than just numbers, but here's a set of functions someone wrote for me to let me use 3x5 number sprites rather than regular text for keeping score:
# Prints numbers to scoreboard
def PrintNumber(number,totalDigits,x,y):
scoreString=str(number)
digits=len(scoreString)
xPos=x
yPos=y
zerosToAdd=totalDigits-digits
for i in range(totalDigits):
if i < zerosToAdd:
PrintDigit(0,xPos,yPos)
else:
PrintDigit(int(scoreString[i-zerosToAdd]),xPos,yPos)
xPos += 4
# Locates sprite data for numbers
def PrintDigit(num,x,y):
thumby.display.blit(n[num],x,y,3,5)
Perhaps it wouldn't run as well if it had to sort through letters in addition to numbers, but it seems to work well for keeping score, at the very least.
# Prints numbers to scoreboard
def PrintNumber(number,totalDigits,x,y):
scoreString=str(number)
digits=len(scoreString)
xPos=x
yPos=y
zerosToAdd=totalDigits-digits
for i in range(totalDigits):
if i < zerosToAdd:
PrintDigit(0,xPos,yPos)
else:
PrintDigit(int(scoreString[i-zerosToAdd]),xPos,yPos)
xPos += 4
# Locates sprite data for numbers
def PrintDigit(num,x,y):
thumby.display.blit(n[num],x,y,3,5)
Perhaps it wouldn't run as well if it had to sort through letters in addition to numbers, but it seems to work well for keeping score, at the very least.
24
Thumby / Re: Thumby development Discord server or something similar?
« on: October 20, 2021, 03:27:59 PM »
While the many Discord servers out there have many different configurations, I'll give a few suggestions based on similar servers and my experience with Discord server moderation:
- In terms of how channels should be grouped, taking into consideration how this forum is currently structured, I would suggest having:
- Otherwise, it could be used in many ways like any other social media platform, such as having events to improve community engagement, with the difference being the greater opportunity for interaction and collaboration with and among members.
- In terms of how channels should be grouped, taking into consideration how this forum is currently structured, I would suggest having:
- A Server Information or Welcome section that would include server "infrastructure" channels, such as those for server rules and general announcements.
- A TinyCircuits section that would include discussion and support channels for TinyCircuits as a whole.
- Sections dedicated to each currently-supported product, such as Thumby and TinyTV, with each having a general discussion channel, and additional channels such as "support" or "development" for the sections that have sufficient levels of community participation to warrant channel "specialization".
- Language-specific and voice channels could also be channels to consider at some point after the initial creation of the Discord server should there be a purpose and sufficient moderation capabilities for them.
- Otherwise, it could be used in many ways like any other social media platform, such as having events to improve community engagement, with the difference being the greater opportunity for interaction and collaboration with and among members.
25
Thumby / Re: Flipping Bitmap Images in Thumby IDE
« on: October 19, 2021, 01:01:03 PM »
Other than having the ability to flip bitmaps, is the drawSprite function basically the same as blit then? And many thanks for the image button; I've been using a pixel art website to design my Thumby sprites, so I won't have to draw them a second time now.
26
Thumby / Thumby development Discord server or something similar?
« on: October 18, 2021, 05:21:37 PM »
While I've spent several hours over the past few days trying to figure out how the various functions of the various existing programs work, as I've made quite little progress in understanding why my implementations of the functions break so often, perhaps a Discord server (or some other real-time communication method) could be created to complement the forum? While I could ask each and every question here, not only would many of them be so insignificant as to be a waste of an entire thread, but the frequency at which I would have questions would lend itself more to a real-time form of communication, such as a Discord server. In addition to allowing developers to share projects and ideas with each other more easily, perhaps it could be expanded later on to include other Thumby-related channels?
27
Thumby / Extracting sprites from bitmap data?
« on: October 18, 2021, 01:38:20 AM »
As a means of learning one or two things about Python, I've begun to try implementing my calculator idea, hopefully one I can manage after a bit of trial and error despite my lacking Python abilities. As using the default font wouldn't allow me to fit nearly enough characters on screen at once, I added bitmaps for each of the 25 or so three pixel wide characters that could be used in an operation. While I considered just drawing all of these to the screen in addition to avoid having to take up extra space with a fullscreen bitmap, I realized that the text needed to add all the characters to the screen would eliminate any saved space. Therefore, I was wondering if there were a way to instead define sprites based on their coordinates in the 72x40 bitmap image, as it doesn't seem that coordinate data is directly included in the bitmap data, other than the fact that each column has its own entry for up to eight rows. If it's possible, I imagine not having the character set icons defined twice might save some space.
Attached is my latest "version" of NanoCalc, with nearly all graphics I intend to use included. Next I intend to try to figure out how to add in logic so that it knows which box is currently selected and flicker the white rectangle of that box, so if anyone has suggestions for that, that would also be appreciated!
Attached is my latest "version" of NanoCalc, with nearly all graphics I intend to use included. Next I intend to try to figure out how to add in logic so that it knows which box is currently selected and flicker the white rectangle of that box, so if anyone has suggestions for that, that would also be appreciated!
28
Thumby / Re: Magic 8-Ball App
« on: October 17, 2021, 09:36:18 AM »
Modified the 8 Ball sprite a bit:
29
Thumby / Re: My Game Mockups
« on: October 17, 2021, 08:59:45 AM »
Seems I mistook binary for hexadecimal, but the general idea for indicating card values for solitaire would be 0001 for Ace up to 1110 for King, with 0000 and 1111 reserved for where the cards are stacked and the face down card design. Not nearly as simple as I'd like it to be of course, but it's the only way to implement solitaire with the values of all cards visible simultaneously.
For the calculator, my thought was to just have it start with the top-left button highlighted and change which button is highlighted when the directional buttons are used. When a button is pressed, it would momentarily disable the highlighting. RN would be used to make the calculator output a random number (0.000 to 1.000 is how I believe most calculators would implement that?), while the | key wouldn't be for calculation, but rather to enable and disable the flickering of the "input next number" cursor, though it could alternatively be used to invert the colors of the screen I guess.
For the calculator, my thought was to just have it start with the top-left button highlighted and change which button is highlighted when the directional buttons are used. When a button is pressed, it would momentarily disable the highlighting. RN would be used to make the calculator output a random number (0.000 to 1.000 is how I believe most calculators would implement that?), while the | key wouldn't be for calculation, but rather to enable and disable the flickering of the "input next number" cursor, though it could alternatively be used to invert the colors of the screen I guess.
30
Thumby / My Game Mockups
« on: October 17, 2021, 02:12:09 AM »
While I lack any knowledge of Python, I still wanted to contribute in some way to bringing interesting games to the Thumby, so I made mockups of potential Calculator, Flappy Bird, Tetris, Pac-Man, and Solitaire implementations. Attached is a Thumby "program" I made after analyzing several existing programs that loads the title screen of NanoCalc, my calculator app mockup, with the A button set to load the calculator screen itself. While I intend to continue analyzing Thumby programs to try to better understand how they work, I thought that perhaps, if anyone who knows Python had a Thumby game idea similar to any of mine, it might be beneficial to work together. While I'll continue adding onto my existing mockups and seeing what other games might be feasible to demake to the Thumby, if anyone were willing to help with the technical aspect of implementing any of the ideas I listed above, I'd be glad to finish the creating graphics for the specific game. For the four non-calculator ideas, I've included bitmap data of the mockup images I made for them in the calculator program.
Pages: 1 2
SMF spam blocked by CleanTalk