Rockbox

Seems nice... it's good to know people are still developing for Rockbox in Lua.

I say it "seems" and not that it "is", because it seems there's no keymap for iPods! I can't move the color selector up and down :(

Oh, and some warnings (like the invalid move one seem too last for too long... I ended up rebooting the device.

Cheers, and keep up the good work!

Gabriel

Hey Gabriel, thanks for trying it out.

First, what iPod are you using? It seems to work on all the emulators I mentioned using the same scrolling movement you'd use for navigating menus. The menu button opens the game menu on all the emulators. You can also skip left to quit exit the game (which saves it as well).

The invalid move popup doesn't block. As soon as you change colour or make a selection it will disappear. Perhaps I should revise how it's displayed as I guess people mightn't realise this.

*quick exit the game.

Yes, it seems that on the simulator of iPod Nano 1G it works... on my real iPod Nano 2G, it doesn't change the selected color, and it's very hard to access the menu (I got there by randomly pressing keys).
Can someone with an iPod confirm this is my device's Rockbox fault, so we make sure it works or doesn't work on real iPods?

Weird. I assume you're running the latest version of RB? You can check in System->Rockbox Info->Version (should be 3.7.1).

I wrote a little script to test what 'keycodes' your player is sending, and what the lua plugin is mapping them to (attached). Please run it and press/scroll when it asks you to. It will dump the results to 'action-codes.txt', could you please upload that file here? Don't worry if you see some redundancy amongst the prompts (i.e. Up and Menu are the same thing).

Here it goes...

I'm using daily builds.

Thanks for that. It does produce different results for the scroll left/right actions than the simulator both with released and SVN code. Could you attach the result of this script as well (attached)? It prints out the whole action codes enumeration to 'action-enum.txt', and might help me work out what I should be using.

Also, if you have the time, could you try running the script with the released version of the code to see if it's a recent change which is causing the issue?

I can comfirm to you that your game works perfectly on the sansa v1 ! ( you did not seem to have v1 on your list of emulators )
Your game is very nice to play ^^
I will try player music and simutaneously play this game, see if anything happens. I will let you know.

Playing music casually works, ( no EQ, no pitch setting ) The only thing that happens if a 'slight' cut out in the music when 'calculating par'. The music then resumes after a couple seconds after it finishes calculating. ( so it is not a big deal. )
Now then, if I use your game in a more extreme condition ( EQ + pitch at limit ) so that I have 90% - 100% of the processor being used and start your game, your game works perfectly under this condition as well.
The only thing in that condition is that sometimes nearing the end of the game it randomly closes... ( or maybe I accidently touch the scroll wheel...)
If you could consider changing the button of what closes your program for the sansa e200's? Maybe the record key or menu ( down ) button would be more practical...
Also, for non color targets, you could use symbols instead of color.
Thankyou For This Awsome Game You Have ^^

By Sansa v1 do you mean a Fuze v1, or the e200 you reference later (or do you have both)?

Thanks for your report about the (temporary) music cutoff, I'll try making the garbage collection a bit more aggressive/smarter and we'll see if that fixes it. Before then, could you try editing the program and replacing the first few lines of the get_colours_count function with this and see if it fixes the music skip:

function get_colours_count(board, x, y, original_colour)
rb.yield()
local board_dimension = table.getn(board)
local count_table = {0, 0, 0, 0, 0, 0}

Regarding the random closing, are you sure you're not pressing the 'safe exit' button (which is 'up' for the e200)? You can check by opening the game again, and it should resume from where you left off. If it does, it was the safe exit button. I take it from your comment that you've already worked this out? There should also be a menu button (hold down home on Fuze) which lets you change the difficulty, start a new game etc. I don't have the e200 emulator at the moment, so I can't check what the menu button is on that.

I thought of the symbols thing, and even drew some. The main trouble is they're difficult to scale for different screen resolutions.

Sorry about that, I have a sansa e280 v1
I used to have a fuze, but I brought it back to the store later ( back in 2008/09? ) because rockbox did not support it =P

I could try your new code see how it goes. ( Ahha, I am hopefully doing it right, and not crash it due to my own errors...) It isn't really much of an inconvenience, your game only does it once ( when it starts ) while it can happen on boomshine ( already on rockbox ) many times throughout the game.

Up? I did not press that key. I could have accidently hit the scroll wheel ( which also closes your game. ) I think it might have resumed again...I can check again... It does not happen often ( and yes, most likely my error, and not yours . ) So I could of hit the safe button. If the scroll wheel is the up key, then I probably hit that.

I see... Hm. I guess you would have to scale different drawings / draw different sized ones for other targets / simulate them? Other thing to do would be much harder ( let your game scale them for the target it is on . )
I am unsure how to help with the screen resolution problem...

I added rb.yield() to where you said it should go.
"calculating par" seems to take a bit longer now, but does not interrupt music playback anymore.
My music playback is still stopping nearing the end of the game. Also, after a couple seconds that the music stopped , I got a '" Data abort at 01F979D8 (0) '"
Above is normal playback conditions ( No EQ, or pitch setting at limit )
Now then, with EQ & Pitch at its limit ( in the debug screen my processor is 100% 80MHz )
Music playback not stopping when "calculating par"
Seems playable still
Music still sometimes stopping nearing the end of the game...
I will test it out more later with EQ & Pitch at limit.

Thanks for your help jer. The rb.yield thing probably means the skipping at the start is due to the playback buffer running out while the CPU is being used by calculate_par. rb.yield gives control of the CPU back to the kernel so it can use it for other purposes, hence you'd expect the function to take a bit longer to run. How long does it take to run for a 'Hard' difficulty game?

Scrolling quits the game? How do you change the selected colour? Running the scripts I linked in my earlier comments and posting the results would help me to understand what's going on here :).

About the 'Data abort' crash, if you can reproduce it, could you write the entire message to this thread? I can make it happen if I run a lua script to use up all the player's memory, but I'm not sure why this would happen after calculate_par has executed. When you ran into the error did you continue playing after the music stopped? If so -and you can make the data abort thing happen consistently-, could you just leave the player and see if it 'data aborts' without you having to do anything. I suspect there may be a memory leak somewhere in the lua plugin/rockbox port. Could you also run the third 'test script' i've got in my opening comment in this thread: http://forums.rockbox.org/index.php/topic,27120.msg177434.html . Finally, what version of rockbox are you running?

Thanks again, you're very helpful :).

Oh, and post the two numbers the test script pops up.

And make sure you have music playing prior to the test script running or it will crash your player :P.

I will check into that, I have only been doing the default 'medium' setting for all the times that I tryed. I will also post time differences between 'easy, medium, & hard' in calculating par. Maybe even without rb.yield in place.

Yes, scrolling exits the game on a sansa e200, I think it is the ' safe exit ' button you talked about. It does load the game back up after I scroll. I accidently keep hitting it when pressing the select ( middle ) button.
The button is the middle for for changing colors. It isn't anything that you have done =) I just keep hitting the safe exit button by accident. ^^

It happened randomly...I am not sure if I could reproduce it... But I do know what I did to get there , yes.
No, I do not think I could resume that game.
I shall try leaving it to see if there is a memory leakage.
I am running the latest, 3.7.1 rockbox

I will see what numbers pop up? =)
Music , gotcha ^^

Also, How do I get the 'entire message' if I do get the data abort error? Is there a way to put my sansa into debug mode on the computer to see the whole message? The only message that I got on my sansa was what I posted...Ahha, rockboxes 'white screen of death...' ^^

Attached goes the result of output-codes.lua you told me to run some comments ago.

@jer When I cause a memory overflow crash on my player I get a bit more text than that, but if that's all there is that's OK. Don't worry too much about testing it right now, I've had a look into the realms of computer science and had decided to replace an oft used part of my algorithm with a much more efficient version. Hopefully this will fix the music stoppage and crashing issues. This may take a few days as I'm a working man :*(.

@Gabriel Thanks for that. The enumeration is quite different to mine, i'll see if I can work out why that is, and if it suggests anything.

Oh? A new efficient script? I was in the middle of testing every possibility for you.
With RB.yield easy , medium & hard mode , normal playback & EQ , pitch at limit ( cpu 90% to 100% )
without RB.Yield ( same tests )
With new script you told me to include...( same tests )
I can post what tests I did...
with RB.yield ( summary )
Easy Mode: Takes 6 - 9 seconds to calculate par , No problems...music does not stop.
Medium: Takes 28 to 39 sec to calculate par... Music playback stops frequently nearing end of game ( 1 to 6 more moves to make to end game )
Hard : About a minute to calculate par...

@jer When I cause a memory overflow crash on my player I get a bit more text than that, but if that's all there is that's OK. Don't worry too much about testing it right now, I've had a look into the realms of computer science and had decided to replace an oft used part of my algorithm with a much more efficient version. Hopefully this will fix the music stoppage and crashing issues. This may take a few days as I'm a working man :*(.

@Gabriel Thanks for that. The enumeration is quite different to mine, i'll see if I can work out why that is, and if it suggests anything.

I'm having a lot of trouble fixing the late-game music stoppage problem :(.

@all: I put some work into optimizing the memory usage, give it another try and see if you get any stoppages when playing a 'hard' difficulty game. I also changed the keymaps so that all targets should get the same stuff.

@Gabriel: Are you using a customized version of RB? I searched the entire source tree and can't find any mention of the 'ACTION_KBD_SCROLL_BACK' action, which is what your build seems to be expecting when you scroll the wheel.

D'oh, please use this version instead, I forgot to un-comment the collectgarbage command on line 95.

Hmm... in fact, when I tried this plugin for the first time, I used the official build (and it didn't work), but now I remember that I've been running the debug scripts you posted here with a custom build which indeed has a ACTION_KBD_SCROLL_BACK, because I have a patch related to the keyboard applied. It's strange anyways, as all the other plugins (including menu-based UI LUA scripts) that use the scroll, and the main interface, run without problems, and note that the patch did not modify them, so their code is still the original one and they are still receiving the normal scrollwheel events.

It's still strange as the patch only interferes with this specific script... are you using rb.actions namespace to get the wheel events, or using integers directly (like I did on the return values for do_menu on my contacts script - still waiting for feedback!).

I'll try with the official build in the next days (currently I can't connect my iPod to my computer) and post the results, as well as the outputs for output-codes and dump-action-codes scripts.

Sorry for making you spend time fixing non-existing bugs... although I'm yet to know if the problem also occurs on the official build. I'd be nice to have another nano2g user leaving his/her feedback.

I'm using the named constants in the actions namespace, it seems to be the best way of doing it. In your script you don't have to deal with actions at all, just the returned index (or -1) from do_menu.

I could make scrolling work better probably by using a different action context (other than keyboard), unfortunately this means I can't use the menu button.

Looking forward to your results :).

Sorry, I almost forgot about this - it's been more than a month! I took the time to install an official build on my iPod and the game works perfectly, again, I'm very sorry for wasting your time looking for bugs that didn't exist.
I like the game a lot, it's a good time waster (in the good sense). I'm now going to modify it in order to work with my custom build...

No problem. Did you see any playback problems on your iPod when playing through a (hard difficulty) game?

Sorry, I forgot to test playback while I was using the plugin.
I'll reply here when I test it.

I just tried this game, and I really like it. I didn't found any bug.
Will it be included by default?

Thanks for trying it out Lovasoa, I certainly want to get it included by default! Which music player did you try it on, and did you see any music stoppage when playing games?

I tried it on the iPod video, and music playback (vorbis files) han't been stopped by your game.
But if you really want to improve it, you could:
- optimize the part calculation algorithm: it's currently slow and I often beat it. I'm sure that basing it on perimeter rather than area (at least at the beginning of the game), would make it much smarter.
- include a «music playback» item in the game menu. A lot of other games have this option, and I find it very practice.

Thanks for this game with helps me when I'm bored in the subway

The same in C. Much more efficient. Better algorithm. Ability to cancel last move.
Much less features. Maybe some bugs. Please test and report bugs...

I just added the ability to configure board size.

I've pretty much reached the limit of what Lua can handle on my player for the par calculation, both in terms of speed and memory usage. Using a more complicated algorithm to generate a better result is a bit beyond the interpreter, I spent a fair bit of time optimizing the algorithm already. The 'choose the move which exposes the most surface area' which you've used in your version is something I rejected as it would have added too much overhead.

The playback menu thing isn't exposed to the Lua plugin at present, I'd need to add it.

I tried out your version, it's obviously a lot faster, and the par algorithm gives better results. A couple of issues:
1. The par and moves run off my screen even when I make the font very small. The way I did it in mine was by truncating the Moves/Par text until all of the number shows (see the draw_status function).
2. You have a rounding error when drawing the board due to CELL_SIZE being a double I think. This means on my screen (Fuze v2) you see lots of black lines through the board at random intervals.

Are you interested in refining your version to the extent to which I've brought mine, or were you just looking to have a better algorithm for your opponent? I'd be happy to help a bit if you're interested in extending your code. If not, I'll continue getting my Lua version tested and merged.

I've pretty much reached the limit of what Lua can handle on my player for the par calculation, both in terms of speed and memory usage. Using a more complicated algorithm to generate a better result is a bit beyond the interpreter, I spent a fair bit of time optimizing the algorithm already. The 'choose the move which exposes the most surface area' which you've used in your version is something I rejected as it would have added too much overhead.

The playback menu thing isn't exposed to the Lua plugin at present, I'd need to add it.

I tried out your version, it's obviously a lot faster, and the par algorithm gives better results. A couple of issues:
1. The par and moves run off my screen even when I make the font very small. The way I did it in mine was by truncating the Moves/Par text until all of the number shows (see the draw_status function).
2. You have a rounding error when drawing the board due to CELL_SIZE being a double I think. This means on my screen (Fuze v2) you see lots of black lines through the board at random intervals.

Are you interested in refining your version to the extent to which I've brought mine, or were you just looking to have a better algorithm for your opponent? I'd be happy to help a bit if you're interested in extending your code. If not, I'll continue getting my Lua version tested and merged.

I implemented splitting the informations strings.
If you want to “help a bit”, can you please help me implementing the "save game" feature ?

I implemented the "save game" feature.
No essential feature lacks now. But I still need to correct the bug that appears when LCD_HEIGHT is not a multiple of SIZE...

File handling was horribly buggy. Please don't even read the previous attachment : I'm ashame!