Planet maemo: category "feed:0d3ed10193588edfe41285c9c902da78"
I don't know. But if you want to find out, then I have something for you.
I don't know. But if you want to find out, then I have something for you.
Back in March, when Fremantle SDK was released, I had ported Frets on Fire to it. Subsequent discussion made it clear that modifications were required to actually make it run on the device. I created a stripped down version which could run without the OpenGL code. This made it suitable for n900 (and even n810). But due to lack of actual device, I couldn't test it.
Fast forward 7 months. Now I have access to actual n900, so recently I went back to the FoF code. After couple weeks of getting re-acquainted with the code, I have it satisfactorily running on the n900.
Frets-On-Fire code primarily has three parts -
I have created a project on googlecode to host the code - maemofof. It shows all the changes I had to make, starting from the base Frets-on-Fire code from v1.3.110.
The next step is to package it nicely and push to extras-devel. There are few problems with packaging though.
I couldn't get ogg files to play through pygame. I installed the ogg-support package, but for pygame/sdl to work with it, something more is required - which wouldn't install due to broken dependencies (libsdl-mixeroggwav1.2-dev). So for now I converted all ogg files to wav. But the wav files are huge (~80MB if a single song is included as sample). That makes them inconvenient to package and they also take a long time to load (~90 seconds).
But good news is, the ball got rolling again. I hope to make some progress in coming days. If you have any suggestions, feel free to chime in comments.
Fast forward 7 months. Now I have access to actual n900, so recently I went back to the FoF code. After couple weeks of getting re-acquainted with the code, I have it satisfactorily running on the n900.
Frets-On-Fire code primarily has three parts -
- playing the song (loading song, computing notes, etc. uses pygame for audio),
- showing the visuals (PyOpenGL+pygame code) and
- handling input.
I have created a project on googlecode to host the code - maemofof. It shows all the changes I had to make, starting from the base Frets-on-Fire code from v1.3.110.
The next step is to package it nicely and push to extras-devel. There are few problems with packaging though.
I couldn't get ogg files to play through pygame. I installed the ogg-support package, but for pygame/sdl to work with it, something more is required - which wouldn't install due to broken dependencies (libsdl-mixeroggwav1.2-dev). So for now I converted all ogg files to wav. But the wav files are huge (~80MB if a single song is included as sample). That makes them inconvenient to package and they also take a long time to load (~90 seconds).
But good news is, the ball got rolling again. I hope to make some progress in coming days. If you have any suggestions, feel free to chime in comments.
Back in March, when Fremantle SDK was released, I had ported Frets on Fire to it. Subsequent discussion made it clear that modifications were required to actually make it run on the device. I created a stripped down version which could run without the OpenGL code. This made it suitable for n900 (and even n810). But due to lack of actual device, I couldn't test it.
Fast forward 7 months. Now I have access to actual n900, so recently I went back to the FoF code. After couple weeks of getting re-acquainted with the code, I have it satisfactorily running on the n900.
Frets-On-Fire code primarily has three parts -
I have created a project on googlecode to host the code - maemofof. It shows all the changes I had to make, starting from the base Frets-on-Fire code from v1.3.110.
The next step is to package it nicely and push to extras-devel. There are few problems with packaging though.
I couldn't get ogg files to play through pygame. I installed the ogg-support package, but for pygame/sdl to work with it, something more is required - which wouldn't install due to broken dependencies (libsdl-mixeroggwav1.2-dev). So for now I converted all ogg files to wav. But the wav files are huge (~80MB if a single song is included as sample). That makes them inconvenient to package and they also take a long time to load (~90 seconds).
But good news is, the ball got rolling again. I hope to make some progress in coming days. If you have any suggestions, feel free to chime in comments.
Fast forward 7 months. Now I have access to actual n900, so recently I went back to the FoF code. After couple weeks of getting re-acquainted with the code, I have it satisfactorily running on the n900.
Frets-On-Fire code primarily has three parts -
- playing the song (loading song, computing notes, etc. uses pygame for audio),
- showing the visuals (PyOpenGL+pygame code) and
- handling input.
I have created a project on googlecode to host the code - maemofof. It shows all the changes I had to make, starting from the base Frets-on-Fire code from v1.3.110.
The next step is to package it nicely and push to extras-devel. There are few problems with packaging though.
I couldn't get ogg files to play through pygame. I installed the ogg-support package, but for pygame/sdl to work with it, something more is required - which wouldn't install due to broken dependencies (libsdl-mixeroggwav1.2-dev). So for now I converted all ogg files to wav. But the wav files are huge (~80MB if a single song is included as sample). That makes them inconvenient to package and they also take a long time to load (~90 seconds).
But good news is, the ball got rolling again. I hope to make some progress in coming days. If you have any suggestions, feel free to chime in comments.
After spending some time on the Frets-on-Fire code I have managed to liberate it from PyOpenGL dependency.
In first step, I bypassed all the GUI code, without making any changes to the audio and input processing components. So I ended up with a completely blank window with a default song playing and me pressing the keyboard frets blindly.
In second step, I wrote only few lines of code to draw the notes on the screen using basic pygame.draw functions.
Here is a screen shot of the minimal UI.
Then I realized that, in theory this minimal version can also run on n810. I tested it in Diablo SDK and it runs. I couldn't hear the sound, but that's an issue with my scratchbox settings. I am sure that this will run on n810, however I am not sure if it will have real time response times. Unfortunately, I don't have a n810 to try this on (mine must be changing hands in black market as I write this :( ). Nevertheless I made necessary changes so that someone can try it on real n810 if they wish to.
If you have played FoF on keyboard, you would know F1-F5 keys are used to control frets and RETURN key is used to pluck the string. One possible way to achieve this with n810 is to use the keys on the keypad.
Following mockup should give you an idea.
F1 = Quote, F2 = K, F3 = H, F4 = F, F5 = S
In place of RETURN we can use the square key as shown above, but I couldn't find what its keycode is. So for now I have assigned that functionality to Q. If someone can provide with that keycode in pygame, I will fix it.
The gameplay is for single song only. I have bypassed all the menus for now. As the song starts the goal is to hit the note when it reaches the white line. You can play different songs by specifying their name as --play command line option.
This is not (yet) a single click install app, however.
I have put together the steps that you will need to follow, to get it working on actual n810. Those should work to the best of my knowledge, but you may run into errors. If you do, please report them in comments and I can help with them.
If you are interested in the changes I had to make, then here is the list of changes starting from the baseline FoF code (r1165 - r1176)
Give it a try. If it runs slow, let me know how slow. There still must be bunch of code paths that we can eliminate to improve the response times.
In first step, I bypassed all the GUI code, without making any changes to the audio and input processing components. So I ended up with a completely blank window with a default song playing and me pressing the keyboard frets blindly.
In second step, I wrote only few lines of code to draw the notes on the screen using basic pygame.draw functions.
Here is a screen shot of the minimal UI.
Then I realized that, in theory this minimal version can also run on n810. I tested it in Diablo SDK and it runs. I couldn't hear the sound, but that's an issue with my scratchbox settings. I am sure that this will run on n810, however I am not sure if it will have real time response times. Unfortunately, I don't have a n810 to try this on (mine must be changing hands in black market as I write this :( ). Nevertheless I made necessary changes so that someone can try it on real n810 if they wish to.
If you have played FoF on keyboard, you would know F1-F5 keys are used to control frets and RETURN key is used to pluck the string. One possible way to achieve this with n810 is to use the keys on the keypad.
Following mockup should give you an idea.
F1 = Quote, F2 = K, F3 = H, F4 = F, F5 = S
In place of RETURN we can use the square key as shown above, but I couldn't find what its keycode is. So for now I have assigned that functionality to Q. If someone can provide with that keycode in pygame, I will fix it.
The gameplay is for single song only. I have bypassed all the menus for now. As the song starts the goal is to hit the note when it reaches the white line. You can play different songs by specifying their name as --play command line option.
This is not (yet) a single click install app, however.
I have put together the steps that you will need to follow, to get it working on actual n810. Those should work to the best of my knowledge, but you may run into errors. If you do, please report them in comments and I can help with them.
If you are interested in the changes I had to make, then here is the list of changes starting from the baseline FoF code (r1165 - r1176)
Give it a try. If it runs slow, let me know how slow. There still must be bunch of code paths that we can eliminate to improve the response times.
After spending some time on the Frets-on-Fire code I have managed to liberate it from PyOpenGL dependency.
In first step, I bypassed all the GUI code, without making any changes to the audio and input processing components. So I ended up with a completely blank window with a default song playing and me pressing the keyboard frets blindly.
In second step, I wrote only few lines of code to draw the notes on the screen using basic pygame.draw functions.
Here is a screen shot of the minimal UI.
Then I realized that, in theory this minimal version can also run on n810. I tested it in Diablo SDK and it runs. I couldn't hear the sound, but that's an issue with my scratchbox settings. I am sure that this will run on n810, however I am not sure if it will have real time response times. Unfortunately, I don't have a n810 to try this on (mine must be changing hands in black market as I write this :( ). Nevertheless I made necessary changes so that someone can try it on real n810 if they wish to.
If you have played FoF on keyboard, you would know F1-F5 keys are used to control frets and RETURN key is used to pluck the string. One possible way to achieve this with n810 is to use the keys on the keypad.
Following mockup should give you an idea.
F1 = Quote, F2 = K, F3 = H, F4 = F, F5 = S
In place of RETURN we can use the square key as shown above, but I couldn't find what its keycode is. So for now I have assigned that functionality to Q. If someone can provide with that keycode in pygame, I will fix it.
The gameplay is for single song only. I have bypassed all the menus for now. As the song starts the goal is to hit the note when it reaches the white line. You can play different songs by specifying their name as --play command line option.
This is not (yet) a single click install app, however.
I have put together the steps that you will need to follow, to get it working on actual n810. Those should work to the best of my knowledge, but you may run into errors. If you do, please report them in comments and I can help with them.
If you are interested in the changes I had to make, then here is the list of changes starting from the baseline FoF code (r1165 - r1176)
Give it a try. If it runs slow, let me know how slow. There still must be bunch of code paths that we can eliminate to improve the response times.
In first step, I bypassed all the GUI code, without making any changes to the audio and input processing components. So I ended up with a completely blank window with a default song playing and me pressing the keyboard frets blindly.
In second step, I wrote only few lines of code to draw the notes on the screen using basic pygame.draw functions.
Here is a screen shot of the minimal UI.
Then I realized that, in theory this minimal version can also run on n810. I tested it in Diablo SDK and it runs. I couldn't hear the sound, but that's an issue with my scratchbox settings. I am sure that this will run on n810, however I am not sure if it will have real time response times. Unfortunately, I don't have a n810 to try this on (mine must be changing hands in black market as I write this :( ). Nevertheless I made necessary changes so that someone can try it on real n810 if they wish to.
If you have played FoF on keyboard, you would know F1-F5 keys are used to control frets and RETURN key is used to pluck the string. One possible way to achieve this with n810 is to use the keys on the keypad.
Following mockup should give you an idea.
F1 = Quote, F2 = K, F3 = H, F4 = F, F5 = S
In place of RETURN we can use the square key as shown above, but I couldn't find what its keycode is. So for now I have assigned that functionality to Q. If someone can provide with that keycode in pygame, I will fix it.
The gameplay is for single song only. I have bypassed all the menus for now. As the song starts the goal is to hit the note when it reaches the white line. You can play different songs by specifying their name as --play command line option.
This is not (yet) a single click install app, however.
I have put together the steps that you will need to follow, to get it working on actual n810. Those should work to the best of my knowledge, but you may run into errors. If you do, please report them in comments and I can help with them.
If you are interested in the changes I had to make, then here is the list of changes starting from the baseline FoF code (r1165 - r1176)
Give it a try. If it runs slow, let me know how slow. There still must be bunch of code paths that we can eliminate to improve the response times.
After the Frets-on-Fire-on-Fremantle post, the feasibility of it on real actual hardware was discussed on maemo mailing list and in comments. It became clear that it's not sufficient to get FoF running in SDK to prove that it will also run on final hardware. We will have to work on the OpenGL GUI to make it happen.
So I dived into the internals of FoF. And this is what I've come up with so far. (Click on image for detailed view)
It is far from a formal UML diagram, but it tries to capture the elaborate architecture of FoF code.
I am experimenting with some parts of the above diagram. Let's see how it goes.
That's all for now... BTW, I posted inkface v0.2.3 yesterday (highlights - all tests running in Diablo SDK, basic Clutter support). Check the detailed changelog here.
So I dived into the internals of FoF. And this is what I've come up with so far. (Click on image for detailed view)
It is far from a formal UML diagram, but it tries to capture the elaborate architecture of FoF code.
I am experimenting with some parts of the above diagram. Let's see how it goes.
That's all for now... BTW, I posted inkface v0.2.3 yesterday (highlights - all tests running in Diablo SDK, basic Clutter support). Check the detailed changelog here.
After the Frets-on-Fire-on-Fremantle post, the feasibility of it on real actual hardware was discussed on maemo mailing list and in comments. It became clear that it's not sufficient to get FoF running in SDK to prove that it will also run on final hardware. We will have to work on the OpenGL GUI to make it happen.
So I dived into the internals of FoF. And this is what I've come up with so far. (Click on image for detailed view)
It is far from a formal UML diagram, but it tries to capture the elaborate architecture of FoF code.
I am experimenting with some parts of the above diagram. Let's see how it goes.
That's all for now... BTW, I posted inkface v0.2.3 yesterday (highlights - all tests running in Diablo SDK, basic Clutter support). Check the detailed changelog here.
So I dived into the internals of FoF. And this is what I've come up with so far. (Click on image for detailed view)
It is far from a formal UML diagram, but it tries to capture the elaborate architecture of FoF code.
I am experimenting with some parts of the above diagram. Let's see how it goes.
That's all for now... BTW, I posted inkface v0.2.3 yesterday (highlights - all tests running in Diablo SDK, basic Clutter support). Check the detailed changelog here.
Here is an update on the Inkface library. But before that let me give a background of the project for the benefit of new readers that will be reading this post via Planet Maemo.
Inkface is an SVG based GUI framework. Unlike the desktops - where GUI components need to be keyboard/mouse friendly; the handheld GUIs need to be finger friendly. Therefore the handheld GUI components should be naturally manipulatable - like parts of an image. Therefore inkface provides a framework in which, GUI is composed in an image editor like Inkscape, instead of rigidly coded in the program. The various elements of SVG image are presented as python objects to the programmer who can then write his program logic using these elements as widgets.
The current version of inkface uses pycairo for vector graphics rendering and uses pygame as backend surface to draw on. A clutter backend is in the plans.
With that background, let me show a demo of an app that I designed (in Inkscape) and coded (in python) using inkface-pygame library v0.2.2. It's a twitter client. The demo shows how the GUI can be changed vastly by merely changing the SVG files and doing no change in the code at all. (the --theme option tells the app to just use a different set of SVG files) The first one is the default theme and the later has a vintage look.
The whole GUI consists of only 2 SVG images (corresponding to 2 screens - login and main twits page). So to create a new theme one only needs to create/change these two SVG files in Inkscape. Compare this to the traditional approach where a theme consists of tens of PNG images of specific sizes.
I was aiming to release it as an app for diablo, but I had to postpone the plan. For improving the performance during animation, I used pygame's features that are only available in v1.8.x and I later found that Diablo ships with pygame v1.7.x. So I need to work around this incompatibility before I release it for n8x0 devices.
For more information on the project check out the wiki. You can download v0.2.2 tarball from here. It is pure python code and can be tried on desktop. For details on the changelog of v0.2.2 check my post on the mailing list here.
Inkface is an SVG based GUI framework. Unlike the desktops - where GUI components need to be keyboard/mouse friendly; the handheld GUIs need to be finger friendly. Therefore the handheld GUI components should be naturally manipulatable - like parts of an image. Therefore inkface provides a framework in which, GUI is composed in an image editor like Inkscape, instead of rigidly coded in the program. The various elements of SVG image are presented as python objects to the programmer who can then write his program logic using these elements as widgets.
The current version of inkface uses pycairo for vector graphics rendering and uses pygame as backend surface to draw on. A clutter backend is in the plans.
With that background, let me show a demo of an app that I designed (in Inkscape) and coded (in python) using inkface-pygame library v0.2.2. It's a twitter client. The demo shows how the GUI can be changed vastly by merely changing the SVG files and doing no change in the code at all. (the --theme option tells the app to just use a different set of SVG files) The first one is the default theme and the later has a vintage look.
The whole GUI consists of only 2 SVG images (corresponding to 2 screens - login and main twits page). So to create a new theme one only needs to create/change these two SVG files in Inkscape. Compare this to the traditional approach where a theme consists of tens of PNG images of specific sizes.
I was aiming to release it as an app for diablo, but I had to postpone the plan. For improving the performance during animation, I used pygame's features that are only available in v1.8.x and I later found that Diablo ships with pygame v1.7.x. So I need to work around this incompatibility before I release it for n8x0 devices.
For more information on the project check out the wiki. You can download v0.2.2 tarball from here. It is pure python code and can be tried on desktop. For details on the changelog of v0.2.2 check my post on the mailing list here.
Here is an update on the Inkface library. But before that let me give a background of the project for the benefit of new readers that will be reading this post via Planet Maemo.
Inkface is an SVG based GUI framework. Unlike the desktops - where GUI components need to be keyboard/mouse friendly; the handheld GUIs need to be finger friendly. Therefore the handheld GUI components should be naturally manipulatable - like parts of an image. Therefore inkface provides a framework in which, GUI is composed in an image editor like Inkscape, instead of rigidly coded in the program. The various elements of SVG image are presented as python objects to the programmer who can then write his program logic using these elements as widgets.
The current version of inkface uses pycairo for vector graphics rendering and uses pygame as backend surface to draw on. A clutter backend is in the plans.
With that background, let me show a demo of an app that I designed (in Inkscape) and coded (in python) using inkface-pygame library v0.2.2. It's a twitter client. The demo shows how the GUI can be changed vastly by merely changing the SVG files and doing no change in the code at all. (the --theme option tells the app to just use a different set of SVG files) The first one is the default theme and the later has a vintage look.
The whole GUI consists of only 2 SVG images (corresponding to 2 screens - login and main twits page). So to create a new theme one only needs to create/change these two SVG files in Inkscape. Compare this to the traditional approach where a theme consists of tens of PNG images of specific sizes.
I was aiming to release it as an app for diablo, but I had to postpone the plan. For improving the performance during animation, I used pygame's features that are only available in v1.8.x and I later found that Diablo ships with pygame v1.7.x. So I need to work around this incompatibility before I release it for n8x0 devices.
For more information on the project check out the wiki. You can download v0.2.2 tarball from here. It is pure python code and can be tried on desktop. For details on the changelog of v0.2.2 check my post on the mailing list here.
Inkface is an SVG based GUI framework. Unlike the desktops - where GUI components need to be keyboard/mouse friendly; the handheld GUIs need to be finger friendly. Therefore the handheld GUI components should be naturally manipulatable - like parts of an image. Therefore inkface provides a framework in which, GUI is composed in an image editor like Inkscape, instead of rigidly coded in the program. The various elements of SVG image are presented as python objects to the programmer who can then write his program logic using these elements as widgets.
The current version of inkface uses pycairo for vector graphics rendering and uses pygame as backend surface to draw on. A clutter backend is in the plans.
With that background, let me show a demo of an app that I designed (in Inkscape) and coded (in python) using inkface-pygame library v0.2.2. It's a twitter client. The demo shows how the GUI can be changed vastly by merely changing the SVG files and doing no change in the code at all. (the --theme option tells the app to just use a different set of SVG files) The first one is the default theme and the later has a vintage look.
The whole GUI consists of only 2 SVG images (corresponding to 2 screens - login and main twits page). So to create a new theme one only needs to create/change these two SVG files in Inkscape. Compare this to the traditional approach where a theme consists of tens of PNG images of specific sizes.
I was aiming to release it as an app for diablo, but I had to postpone the plan. For improving the performance during animation, I used pygame's features that are only available in v1.8.x and I later found that Diablo ships with pygame v1.7.x. So I need to work around this incompatibility before I release it for n8x0 devices.
For more information on the project check out the wiki. You can download v0.2.2 tarball from here. It is pure python code and can be tried on desktop. For details on the changelog of v0.2.2 check my post on the mailing list here.
Couple days ago I played Frets on Fire (FoF) for the first time. I was totally hooked on to it. After going through its hilarious tutorial and starting with a pathetic performance, I managed to score 37K points with 87% accuracy on the "Defy the Machine" song a few moments ago.
Couple days ago I played Frets on Fire (FoF) for the first time. I was totally hooked on to it. After going through its hilarious tutorial and starting with a pathetic performance, I managed to score 37K points with 87% accuracy on the "Defy the Machine" song a few moments ago.