Most recent activity
-
- 4 comments
- 74 views
-
This looks great! It'd be good to see this in the app loader!
Yes that's my aim, but i'm still working on it, i need to still add some options to make the input rects visible and make theming optional.
Do you think you could come up with a small self-contained example bit of code that you could post up here that runs really slow like you mentioned? It might be we can find a way to make it faster.
I'll have to check but it may not be easy to do this as i used classes and such that are intertwined with the checks
What do you mean by "Moves Left" - does it actually try and run through each move each time to see how many would be needed to finish?
Yes, after each "move" you have done, the game loops through all still available pegs using a double for loop (i have a two dimensional array to represent the playfield). And i have a Peg class which contains a canMoveToPostion function that will check if a certain Peg can move to a postion and return true or false. For each peg it then calls this functions with all possible move location per peg, these are 4 or 8 calls (moves) to that function depending on the difficulty (if diagonals are allowed). It has todo this for each peg on the board and then it will display value, but it also uses that value to determine if the game is over (moves left = 0, like no peg can move anywhere anymore)
this is the current code:
function movesLeft() { "compiled"; let result = 0; pegsLeft = 0; let BoardPart; let Y, X; for (Y = 0; Y < NROFROWS; Y++) { for (X = 0; X < NROFCOLS; X++) { BoardPart = BoardParts.Items[Y][X]; //print (BoardParts.Items[Y][X]); // if there is a boardpart on that X,Y Coordinate // check all direction if we can move to that if so increases the movesleft if (BoardParts.Items[Y][X]) { if (BoardParts.Items[Y][X].AnimPhase < 2) { pegsLeft++; result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X + 2, Y, false); result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X - 2, Y, false); result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X, Y - 2, false); result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X, Y + 2, false); result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X + 2, Y - 2, false); result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X + 2, Y + 2, false); result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X - 2, Y + 2, false); result += CPeg_CanMoveTo(BoardParts.Items[Y][X], X - 2, Y - 2, false); } } } } return result; }Just a thought but even without using compiled code, if you could split the code up such that it could run as a function that gets called multiple times, you could update the screen immediately, and then run the calculation in the background. If the user interacted with the Bangle to make another move you could just cancel, redraw with the new state and start again.
thats not a bad idea, but i'm not sure how easily i can adapt to this, you see i do a single frame game loop and everything gets done during that single frame as soon as thats over the game is idling, i don't have a loop that keeps getting called. If nothing needs drawing it doesn't do anything at all but i could give it a try by recalling the game loop if the calculation had not finished but i'll need to check how i can actually do this. When you say run the calculation in the background do you refer to something like threads or so ? Is that some special functionality in javascript / bangle ?
-
I'm working on version 0.02. It will have bigger playfield tiles and repositioned screen layout so that things are more viewable on the watch itself. The menu's (atm) will remain the same as well as the little ingame help but during gameplay the playfield will actually be a lot bigger, i went from 10x10 tiles to 16x16 tiles and it makes viewing it on the watch a lot better.
If you can't wait for the release there is a dev version available on my github pagesand here is a small gif to show what i mean
-
- 7 comments
- 150 views
-
if you like to try the new changes you can grab the new (dev) version from here https://joyrider3774.github.io/BangleApps/
-
btw @HughB i started working on my idea of using different size of tiles for the playfield and it's much more visible now on the watch. It seems it will work, but the downside is it will use some more ram. The menu's and help screen and text will remain same size though (otherwise i could not fit everything in the screen), but the playfield / puzzles will actually be bigger in size and easily viewable on the watch (i tried it already)
-
I had a look at the code. Is that C code really running ?
Not sure i understand the question but in the emulator the C code is not running, but if it's not javascript code is used. The C code only compiles when uploading to the watch but not in the emulator. I only made specific parts in C all the rest is basically javascript code running. (see line 1023 for example) USECCODE is set to false when it could not compile the C Code (inside the emulator for example) and based on that boolean flag i either run the C Code or the Javascript version of the function
I think there is maybe a problem with the logic for the state machine for the movement / centre button. In the simulator I can go up, up. left, left. Then Right or bottom wil rotate the tile. So it gets a bit confusing.
I can not reproduce this not on my watch nor in the simulator, so when you play the game and you press the upper parts twice (so the selector moves 2 times up) and then you press the left part of the screen twice (so selector moves 2 times left) and then you press the bottom or Right direction it rotates the tile ? Are you certain you pressed the complete bottom or right parts ? Enabling the inputrect in the options will make sure you press in the correct parts as it shows where you are supposed to touche / click. On the bangle itself you need to touch the screen on the sides. Can you be more specific about what you did exactly so i can reproduce it
Edit: not sure if it matters but i run the emulator in chrome on windows
-
I look forward to your next games. Is this your Rubido game ?
Yes thats the rubido game i'm porting. I made that game about 14-15 years ago, for the gp2x and dingoo handhelds, at the time there did not exist iphones or androids and so or at least i did not have one. The gp2x and dingoo were opensource handhelds and most were running linux and people could develop their own games for the machines. There was an active community around these handhelds with people developing games and emulators and users playing them . if you want something similar today the only thing that comes to mind is the playdate which i also own and made a few games for. I took the source code my old game and again ported it to javascript. It's not that hard to convert SDL c/cpp code to espruino but they do require a lot of changing as you can't constantly refresh the screen on the bangle. So i was checking my old games for games that basically only "acted" when input was done and rubido was another such game so i started porting that game also. I've created another thread in the projects page about it and there is a little gif showing the progress so far
-
I just created a little help video, explaining the game mode and usage of the game on the watch. I recorded it using OBS Studio and the emulator as doing it with the watch was probably not going to work already. The video is available on youtube
Hey gordon,
I managed to implement the background counting of movesleft. I've used the setinterval function todo this. And now we can keep on playing immediatly after a move was done and it will update the movesleft value once it has done calculating them. I just call the GameLoop one more time to verify if it is a winning game and draw the results basically my code looks like this now :
and that seems to work fine