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.


Messages - CoolieCoolster

Pages: 1 2
1
Thumby / Re: Pico Pac - Tiny Pac Man - Finished!
« on: November 19, 2021, 08:44:27 AM »
Still need to finish with the graphic set, but I was thinking that creating a function for Pico Pac to save its high score to a text file on the Thumby would not only be helpful for the game itself, but also could serve as a base for other developers to implement such functionality? My first game for instance, NanoMem, is ready other than that functionality, which I haven't been able to figure out thus far...

2
Thumby / Re: Pico Pac - Tiny Pac Man - Finished!
« on: November 17, 2021, 05:55:37 AM »
Your version sort of reminds me of Blinky for the CHIP-8, though perhaps with somewhat more capable ghosts? And yeah; the reason I designed the mockup sprites as they are was to avoid them merging with the walls, but I guess I can try to modify them and see how they'll look in the maze mockup.

3
Thumby / Re: Pico Pac - Tiny Pac Man - Finished!
« on: November 12, 2021, 12:33:32 PM »
I'll have to send it as the bottom half and the top half at the very least as the import utility doesn't accept anything beyond the resolution of the Thumby itself (hopefully a limit that will be increased at some point), but I guess if the values are being blitted 40 lines at a time depending on the vertical coordinate of Pac-Man, the bitmaps could just be combined following the import and then just used as the general background dataset. I'll add the graphic data to the PY file I send, as well as separate image files of the various bitmaps for reference, and then you can subsequently adjust it and let me know if anything else is needed.

4
Thumby / Re: Pico Pac - Tiny Pac Man - Finished!
« on: November 11, 2021, 06:19:43 PM »
No worries regarding function implementation; I much prefer to collaborate with others to implement more complex ideas rather than trying to do so by myself without much success, in addition to the benefit that the game concept itself gains with more people working on it. I'll try setting up a basic title screen that takes inputs for a high score screen, settings screen, and "start game". There would also be the potential to implement a multiplayer mode at a later point, but as it isn't yet documented in the API, such an implementation and the associated title screen selection option for it can be saved for a potential later revision. Will probably not be as efficient as can be, but I'll subsequently upload a ZIP file with the PY file and importable gameplay graphic bitmaps that can then have the gameplay functions added to it.

To display the background maze walls, as they could be mirrored across the y-axis, would it be better to implement it as two bitmaps each blitted regularly and mirrored, or divided further into drawing the edges of the maze as lines and blitting the rectangles within the maze individually?

5
Thumby / Re: Pico Pac - Tiny Pac Man - Finished!
« on: November 11, 2021, 01:26:45 PM »
I'm not sure how much it would help as it seems that taking accurate photos of the Thumby's screen is difficult due to its size, but here's one of my nearly complete "NanoMem" game that someone with a pre-release Thumby took for me. As I personally find the default font to take up too much space, I've been using bitmaps as a means of using custom fonts, with the "TINYMEM" text on the title screen using the smallest legible font of three pixels tall. As the game's score is displayed via five pixel tall bitmap numbers separated by one pixel wide gaps, I'll ask the person who sent me the picture how legible the score for reference. Also, as the screen only seems to be roughly half the width of the device itself, while I'd have to do a calculation first, perhaps larger screens might not have a sufficient pixel density to be an accurate reference for the Thumby?

Edit: While the pixel density of a smartphone would have to be a multiple of that of the Thumby to be able to accurately represent how a game would look at the scale of the Thumby, as most smartphones should at least have a higher resolution than that of the Thumby, at least an estimate can be determined by seeing how legible the nearest multiples of 40x72 are. Not an exact method, but it should still be informative.


6
Thumby / Re: Pico Pac - Tiny Pac Man - Finished!
« on: November 11, 2021, 02:23:58 AM »
Impressive! I like the full-size Pac-Man on the initial screen. While I also have Pac-Man on my list of games that I think would work well as demakes, its need for several functions I'm not yet sure how to implement convinced me to focus on my simpler ideas first: tracking which pellets to disable (my guess would be a dictionary of all pellet locations, though I wouldn't know how to set that up), ghost AI (having each ghost to go to their designated corners and which pixel each should use as a means of tracking Pac-Man), and how to scroll between bitmaps, among other factors.

As pictured below, I came up with a "NanoMaze" mockup a few weeks ago where the regular Pac-Man maze is scaled down as accurately as possible to a point where only vertical scrolling between two bitmaps would be required. A bit more difficult to give the ghosts "character" with such a low resolution, though as indicated by the "sprite list" at the bottom right, movement direction could be indicated at the very least, with the power pellets differentiated by having them flicker, and swapping the pallet when a power pellet is in effect.

While I plan on implementing my various game mockups in an order of increasing complexity (NanoMaze probably being near the top of the list), if you'd be interested in trying to adapt the logic you came up with for Pico Pac to such a design, or perhaps implementing it as an alternate mode, I'd be glad to divide the graphics into importable sprites and create additional ones as needed. While my attempts at creating functions often take a while just for them to break, once I figure out how to implement saving an array of highscore values to a text file for my current projects, I imagine such a function could be easily repurposed for most games where all that needs to be saved from one session to the next are highscore values.


7
Thumby / Re: Sprite not being completely mirrored?
« on: November 09, 2021, 07:40:31 PM »
While it only works with flipping across the x-axis due to how the bitmap data values are ordered, until mirroring is fixed
Code: [Select]
thumby.display.blit(list(reversed(bitmapname)) appears to be a functional alternative that works with the default Python functions.

8
Thumby / Accurate usage of the Thumby.Audio.Play function
« on: November 08, 2021, 06:15:12 PM »
As I wanted my game, NanoMem, to make use of the Thumby's audio capabilities, when finalizing the function that illuminates the pattern outputs I assigned each output a frequency value that matched forth-octave notes. Unsure what the optimal volume would be, I had left the third field of the function blank so that it would default to the preset of 50%. After asking someone who had received a pre-release unit to test NanoMem for functionality, as they said the audio was very quiet I modified the audio output functions with the values of the third field set to the maximum value defined in the API. When they tried the modified version, however, there was no audio at all; is there another factor I may have missed?

9
Thumby / Re: IDE on Raspberry Pi in Chrome
« on: November 03, 2021, 01:42:20 PM »
Perhaps not the best practice for syncing the emulator on whichever page users will be using (as in the webpage using fixed-pixel settings versus adjusting on the basis of screen width), but perhaps for the IDE the emulator could be set to be at a fixed-pixel multiplier, depending on the developer's preference in regards to their own screen resolution? So, for instance, there could be options for 5x for 200x360, 10x for 400x720, etc. That way the pixel height and widths would maintain their same ratios to each other across the entire screen, and then if one needs to see how the graphics look at scale, they can either test it on their own device after they are shipped, or, assuming that hopefully the communities grows to the point of having volunteer testers, have others give them feedback on how it functions on an actual device.

10
Thumby / Re: Launch Multiplayer Games?
« on: November 02, 2021, 03:40:22 PM »
Personally, I think I'll try to come up with multiplayer mode ideas for as many of my mockups as possible as potential "Version 2" updates for when I know more Python functions; and I imagine as the devices would be sending data to each other, one of the serialization functions would need to be used to serialize the data? If so, I guess I should get to work trying to figure out the Pickle function...

11
Thumby / Re: Launch Multiplayer Games?
« on: November 02, 2021, 10:41:07 AM »
In response to a question of mine on Kickstarter regarding a game to demonstrate the multiplayer functionality, they did say they were working on something, though I guess we'll just have to wait to see what it is. Otherwise, it would also be helpful for such functionality to be documented in the API so that third-party developers can attempt their own Link Cable multiplayer implementations. I probably wouldn't try to implement something so complex myself for my projects until I better know how to make games at all, but I have a few ideas for which the Link Cable might prove helpful.

12
Thumby / Re: Addition of third-party games to the pre-loaded set?
« on: November 01, 2021, 08:02:09 PM »
Thanks for the reply! The unfortunate thing is that not many people seem to be developing games yet, despite the fact that it seems that many of us working on MicroPython projects are learning while doing, so hopefully others in the community can find inspiration to make programs of their own. As I'm keen to finish up NanoMem and figure out the mystery that will be combining animation and velocity in my second project (I expect SaurRun has some functions that might be helpful to learn from in that regard), I'll see if I can finish my function rewrites and implementation of save data saving/loading in the next few days.

If anyone working on their own Thumby projects might be able to help discern how to use the following functions from pickle to serialize and deserialize variables and lists to a defined txt file, I'll post what I've gathered so far on the subject:

The following is the pickle function, edited to allow for its use without a seperate pickle module:
Code: [Select]
# Save data serialization
HIGHEST_PROTOCOL=0

def dump(obj,f,proto=0):
    f.write(repr(obj))

def dumps(obj,proto=0):
    return repr(obj).encode()

def load(f):
    s=f.read()
    return loads(s)

def loads(s):
    d={}
    s=s.decode()
    if "(" in s:
        qualname=s.split("(",1)[0]
        if "." in qualname:
            pkg=qualname.rsplit(".",1)[0]
            mod=__import__(pkg)
            d[pkg]=mod
    return eval(s,d)

If it helps, the following description was also listed in the documentation describing the function, though it wasn't too helpful for me:
Code: [Select]
import pickle
data = {'1':b'test\nmore', '2':1.414, '3': [11, 12, 13]}
s = pickle.dumps(data)
print('Human readable data:', s)
v = pickle.loads(s)
print('Decoded data (partial):', v['1'])

Human readable data: {"2": 1.414, "3": [11, 12, 13], "1": "test\nmore"}
Decoded data (partial): test
more

s = ujson.dumps(data)
# pickle produces a bytes object whereas ujson produces a string
u.write(s.encode())
# Pickle:
# u.write(s)
u.write(b'\n')

# receiver
s = u.readline()
v = ujson.loads(s)  # ujson can cope with bytes object
# ujson and pickle can cope with trailing newline.

The following was my initial attempt at adding theoretical variable saving functionality to NanoMem, and while it includes what I think is the intended method of opening, reading, and writing to files, I have yet to figure out how to combine it with the pickle functionality to save and load the variable that determines whether or not the user has unlocked hard mode and the index of six high score values that are currently saved if the current score following a "desync" is greater than one of the three saved high scores for the current gamemode:

Code: [Select]
thumby.files.openFile(/Games/NanoMem/data.txt)
    thumby.files.readFile(1)
    if(thumby.files.readFile()=='h'):
        h=1
        thumby.files.closeFile()
        bl(s1e2,33,29,6,7)
    elif(thumby.files.readFile()=='r'):
        thumby.files.closeFile()
    else:
        thumby.files.openFile(/Games/NanoMem/data.txt,w)
        thumby.files.writeFile(r000000000000000000000000)
        thumby.files.closeFile()

Should it be of any use, the following is the aforementioned function that saves high scores in NanoMem, with an i value of range three for the three high score values saved, which itself is defined by the hard_mode variable that places it in the corresponding sub-index of the highScores index:

Code: [Select]
for i in range(3):
            if s>highScores[hard_mode][i]:
                highScores[hard_mode].insert(i,s)
                del highScores[hard_mode][3]
                break

Assuming an efficient function for saving and loading variable data is standardized, perhaps it will prove helpful to future users in saving time in developing their own games.

13
Thumby / Addition of third-party games to the pre-loaded set?
« on: October 31, 2021, 02:10:51 AM »
As there's still at least two weeks until any production begins, and I would imagine still some time after that until devices are assembled and flashed with firmware, perhaps the addition of completed third-party Thumby games to the default set of five could be something to consider as a means of giving the device additional functionality out of the box? While users can always add and remove games based on their preferences, I thought that perhaps the inclusion of third-party games completed prior to whenever firmware flashing will begin could serve as both a means of encouraging additional third-party development and adding to the first impressions that the user would have in regards to the capabilities of the Thumby.

In regards to my own projects, if NanoMem's implemented button-select sound effects work on actual hardware, and if I can figure out how to use the functions transposed from "Pickle" to save the "hard mode unlock" and six high score values to a text file, I would be glad to contribute it, should the creator of TinyMem not have any objections.

14
Thumby / Re: NanoMem v1.4 and Question Regarding NanoBird Animation
« on: October 29, 2021, 02:08:30 PM »
Thanks for the feedback! In terms of the menu icons, I did the three-stage podium to sort of mimic the icon from Flappy Bird, and while I initially thought of making a gear icon for settings, I couldn't come up with one that looked recognizable and still fit in the space needed for it to not blend with the button outline. In regards to which icon is selected, I'll see if I can make it clearer. Took me some time to initially implement it as there wasn't another Thumby program to base menu navigation via buttons off of at the time, plus the fact that I wanted to take advantage that two sets of icons are stored to not have to have additional graphic space taken up by dedicated button selection graphics.

15
Thumby / NanoMem v1.5 and Question Regarding NanoBird Animation
« on: October 29, 2021, 12:51:31 AM »
After analyzing other Thumby programs, I improved NanoMem for a v1.4 release that reduces the space used by functions and bitmap data, offsetting my addition of the "pickle" function that I intend to use for serializing save data, once I figure out how it works. As implementing such functionality will take up more storage space, hopefully I can offset it with additional function and bitmap usage efficiency improvements, considering how simple the game is.

Secondly, I've also included a non-gameplay version of my current project, NanoBird, intended to be a Flappy Bird demake. While I'm still working on actually making it functional, nearly all graphics intended for the final release are included (in two palettes for the day/night modes of Flappy Bird, but after everything is implemented I'll test a palette swap function to see whether or not it impacts performance). The question I have regarding it is how Flappy Bird should be animated both before and after gameplay begins (with the former being on the title screen and before the player presses a button on the gameplay screen). On the title screen I intend to have an animated version of the original Flappy Bird sprite, too large for gameplay purposes, moving from the left side of the screen to the right side, followed by the smaller "gameplay" Flappy Bird. I currently have this animation partially implemented, albeit in a manner that is probably inefficient. What I'm having trouble with is synchronizing the animation of Flappy Bird's wing with that of Flappy Bird itself, as it switches between its three frames 25% faster (0.5 vs 0.67 seconds), something I want to try to implement. If anyone who looks at the code might know how to make it work, it would be much appreciated!

Edit: For NanoMem v1.5, I fixed a regression in regards to the detection of button inputs for exiting the high score screen and implemented the saving of high scores to variables once a match ends. The last step will be to have the variables saved to a text file whenever they are modified, and load them from the text file whenever the main menu loop starts.

Edit 2: As requested in the comments, for v0.02 I updated NanoBird to animate the currently-selected button on the menu. I also tried making the wing animation slightly less broken, but the entire function probably just needs to be cleaned up and simplified... To keep the two sets of NanoMem/NanoBird versions available for reference, future updated versions will either be posted in the comments or as a new thread.

Pages: 1 2
SMF spam blocked by CleanTalk