fretsonfire-devel Mailing List for Frets on Fire

Dear Frets on Fire people,

In this project I try to make a connection between a Brain-Computer Interface and Frets on Fire (project called Brains on Fire).
This will enable people to play Frets on Fire only using their brain waves, helping disabled people to play this great game!
Now I am no python expert, and I have some (simple) problems that I have to solve before I can make this work:

- Disable the Rhythm Button, is there an easy way to do this? I thought about making all the notes "hammer ons", could that be an option?
- Disable the length of the note, just hitting should be enough in the beginning. 
- Timing should be less important, like it doesn't matter if you hit it 0.4 seconds later.
- Change the keys into BCI input (already found the key assignment class, so wouldn't be a big problem)

If I could get the game working with these simple things I can continue and improve it. Unfortunately I am currently working on a Windows computer and I can't edit those *.pyd files, I can change those *.py files of the Linux distribution.. how can I change the source of the Windows game in the same way?
At the moment I am just looking through the source code from the Linux version, but I am not able to test that on my Windows computer..

I hope someone can help me out here with one or more problems! Should be great!!

For some more information about this project you can read some here: http://reynouts.wordpress.com

Thanks in advance,

Reinout Versteeg
 		 	   		  
_________________________________________________________________
Alles over Windows
http://www.windows.nl/About.aspx

Hi Gavin,

On Mon, Feb 8, 2010 at 12:36 AM, Gavin <gav...@gm...> wrote:
> I'm interested in getting a program that can take a song (e.g. .wav file)
> and create a track I can use to drive a light show.
> I'm building my own hardware for LED lighting and basically want something
> like the old color organ. But I want to be able to edit the output.
> It occurred to me that Fret on Fire must have such a software engine in it.
> Is it accessible? Or does anyone know of an app. like what I'm looking for
> freely available? I'll make my driver circuits available if anyone is
> interested.

That sounds like an interesting project. Unfortunately Frets on Fire
relies upon good ol' manual automation for the conversion from music
to note files. That is, the game ships with a song editor that can be
used to place notes in a way that corresponds to the playing music.

The note files themselves are just plain old midi files (search for
files named 'notes.mid'), so you could write software to read those
directly. You can also use a standard MIDI editor to edit the notes.
There are quite a few FoF note files for different songs out there, so
changes are the notes for the song you're interested in are already
available. Check the forums for more information.

> Thanks in Advance,
>
> Gavin
>
> Gavin Perry
> web: http://www.gptsllc.com
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> fretsonfire-devel mailing list
> fre...@li...
> https://lists.sourceforge.net/lists/listinfo/fretsonfire-devel
>
>

- Sami

I'm interested in getting a program that can take a song (e.g. .wav file)
and create a track I can use to drive a light show.
I'm building my own hardware for LED lighting and basically want something
like the old color organ. But I want to be able to edit the output.
It occurred to me that Fret on Fire must have such a software engine in it.
Is it accessible? Or does anyone know of an app. like what I'm looking for
freely available? I'll make my driver circuits available if anyone is
interested.

Thanks in Advance,

Gavin

Gavin Perry
web: http://www.gptsllc.com

Hi Olivier,

>> Do you have some ideas on how you would like to refresh the graphics
>> style of the game? It would be great to see some mockups. Would you
>> prefer to keep the current 2D style or move toward a more 3D look?
>
> I've many, many ideas !
> With my skill, i prefer work on 2D style, cause i don't know enough the 3D
> modeling but if you have a modeler available we can cobine our talents !!
> but it's possible to have a animated 2D style which using 3D effects like
> "mario paper"  or "parapa the rappers" (for the effect not the graphic style
> ;-)  )

Keeping the graphics style 2D or 2.5D is of course simpler from the
code point of view as well, and I think it can look very stylish and
polished if done right. Joonas Kerttula from the dev team is very
experienced with 3D modeling, but unfortunately the amount of time he
can spare for making models is a bit limited. Adding proper 3D would
also in practice mean integration with a proper 3D engine such as
Ogre. Therefore, a mostly 2D approach with a limited number of 3D
elements sounds good to me.

> -1/ the in-game design (when we play guitar !) is quite disappointing and wa
> can work about a more real live style.
> -2/ if the team (or you) is interested we can add a real "rock'n roll"
> graphic touch to all the interface, but it's just a bonus cause the actuall
> design is correct. So we should talk about.
> -3/ i can propose a graphic content for a campaign mode with free songs
> (with creative commons license) but it's a longer work. i have many ideas
> about this.
> So tell me what is your priority about this 3 thematics ?
> For me it's in the order i present to you (1,2,3).

That sounds about right to me too -- I think improving the in-game
view has the biggest effect on how good the game looks for players and
it can be done with moderate effort.

> After we can speak about the graphic style and propositions because i can
> work with differents styles. Some are quick to create other are long, So we
> speak about style, duration, flexibility, integration and lightness (for
> display performance) etc...

Agreed. If you have some mockups to share I think we all would be very
interested to have a look.

> Another question :
> I don't know how evolutions are decided in the project ? Are you alone to
> choose, have you a maker team ? a mailing-list debate ?
> Meanwhile i'm working on my graphical proposals

Let's keep this discussion going on this the fretsonfire-devel mailing list.

As Alex mentioned, the in-game graphics are mostly based on SVG files.
That's somewhat of a historical remnant, since originally the SVG
files were drawn on the fly in the game. Nowadays the SVG files are
converted into PNG files offline to improve in-game performance and
graphics quality. Therefore you can use any program that produces PNG
files -- using SVG is not a hard requirement.

- Sami

Great.

The two major graphics things are obviously SVG with inkscape (as you've
discussed) also COLLADA with blender or some such (for the 3d models).  If
you could do both that would be great.

Some of the default graphics and new themes definitely need some work.  Also
some new items (icons and some other stuff) are going to be required as
well.  General UI changes might be cool too.


-Alex


On Thu, Aug 13, 2009 at 12:03 PM, olivier boyer <zi...@gm...> wrote:

> Hi,
> I'm french graphist webdesigner (and i'm a dummy in english, so excuse me
> for my syntax) and i'm very interested to work on the graphical interface of
> Fret's on Fire.
> I know very well Inkscape (i say that cause you'r using SVG) and i'm very
> flexible in graphic style.
>
> If you are interessed too :
> - we can talk about that
> - or I can send several different models (if i have litlle time to finalize
> them) to initiate debate or if you want to evaluate my graphics skills
>
> I can work on the interface, optimize the ingame interface or for a solo
> campaign, or the three, If any developper is interested...
>
> I've done contribution on 2 other games :
> - maps for Wormux
> - all the interface for monkey bubble
>
> Thanx
>
> --
> Zi olive
> -------------------------------------
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> fretsonfire-devel mailing list
> fre...@li...
> https://lists.sourceforge.net/lists/listinfo/fretsonfire-devel
>
>

Hi,
I'm french graphist webdesigner (and i'm a dummy in english, so excuse me
for my syntax) and i'm very interested to work on the graphical interface of
Fret's on Fire.
I know very well Inkscape (i say that cause you'r using SVG) and i'm very
flexible in graphic style.

If you are interessed too :
- we can talk about that
- or I can send several different models (if i have litlle time to finalize
them) to initiate debate or if you want to evaluate my graphics skills

I can work on the interface, optimize the ingame interface or for a solo
campaign, or the three, If any developper is interested...

I've done contribution on 2 other games :
- maps for Wormux
- all the interface for monkey bubble

Thanx

-- 
Zi olive
-------------------------------------

Open source allows forks.

MFH had been doing a mod like I had for a while.  He's forked it which is
fine.

The main issue with the MFH stuff is it is directly ripping off both GH and
RB stuff (graphically) and trying to be a more or less clone.   The original
FoF is trying to stay farther away from those issues.

-Alex


On Sun, Nov 9, 2008 at 3:55 PM, Cristian Morales Vega <cmo...@ya...>wrote:

> Looking in the community forums seems the main development effort is
> now in a fork: http://code.google.com/p/fofix/
> I'm not a Guitar Hero freak, I just know notes arrive and I pulse
> buttons getting points and starts "somehow". So I didn't know about
> half the features added to the fork. They made some strange changes
> (hardcode "python2.4" when python2.5 works ok and the original just
> uses "python"; search only .png *or* .svg instead of trying first .png
> and fallback to .svg; etc.) but looks like they have added a lot of
> features (again, I don't understand half of them).
> Since with the 1.3.110 release FoF now seems live again... the
> question is obvious: which is the position of the original project
> about the fork? They just forked without even asking for svn write
> access here? They have subtle different objectives than you?...
>
>
> 2008/11/9 Alex Samonte <asa...@us...>:
> > I have not been reading the bug reports on the source forge page.  I've
> been
> > getting them mostly from the community forum.  The SVN version has
> various
> > issues.  the 1.2.451 build was much more stable then 1.2.512
> >
> > I'll look at disabling the bug report zone and try to point people to the
> > community forums.  I'm looking to update the version in the near future
> with
> > the devel code i'm working on.  I haven't been using the SVN repository
> like
> > i should, but once I merge them it should be easy.
> >
> > Thanks for the email.
> >
> > -Alex
> >
> >
> > On Sat, Nov 8, 2008 at 12:35 PM, Cristian Morales Vega <
> cmo...@ya...>
> > wrote:
> >>
> >> On Linux the game right now is on a very very very very bad state,
> >> it's just unplayable.
> >>
> >> Since a year ago (SVN revision 55) the menus texts aren't shown, it
> >> was reported six months ago but nobody answered... but the thing is
> >> nobody answers to a single bug report. Well, ok... answer to bug
> >> reports is boring, but ten months Michael Brunton-Spall submitted a
> >> patch for another problem (#1848584, I can verify the problem exists
> >> and the patch fixes it)... and hasn't still been applied.
> >> So... are the devs aware that there exists a bug report zone??
> >> (seriously!! no offense intended...). From other projects hosted at
> >> sourceforge looks like you can disable these bug report/patch submit
> >> zones. So, if bugs are supposed to be reported on the mailing list or
> >> somewhere else, disable the sourceforge zones could be a good idea.
> >>
> >> The Linux version has a lot more problems (at least on x86-64), but
> >> the thing is... where should I report them?
> >>
> >>
> -------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great
> >> prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the
> >> world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> fretsonfire-devel mailing list
> >> fre...@li...
> >> https://lists.sourceforge.net/lists/listinfo/fretsonfire-devel
> >
> >
>

Looking in the community forums seems the main development effort is
now in a fork: http://code.google.com/p/fofix/
I'm not a Guitar Hero freak, I just know notes arrive and I pulse
buttons getting points and starts "somehow". So I didn't know about
half the features added to the fork. They made some strange changes
(hardcode "python2.4" when python2.5 works ok and the original just
uses "python"; search only .png *or* .svg instead of trying first .png
and fallback to .svg; etc.) but looks like they have added a lot of
features (again, I don't understand half of them).
Since with the 1.3.110 release FoF now seems live again... the
question is obvious: which is the position of the original project
about the fork? They just forked without even asking for svn write
access here? They have subtle different objectives than you?...


2008/11/9 Alex Samonte <asa...@us...>:
> I have not been reading the bug reports on the source forge page.  I've been
> getting them mostly from the community forum.  The SVN version has various
> issues.  the 1.2.451 build was much more stable then 1.2.512
>
> I'll look at disabling the bug report zone and try to point people to the
> community forums.  I'm looking to update the version in the near future with
> the devel code i'm working on.  I haven't been using the SVN repository like
> i should, but once I merge them it should be easy.
>
> Thanks for the email.
>
> -Alex
>
>
> On Sat, Nov 8, 2008 at 12:35 PM, Cristian Morales Vega <cmo...@ya...>
> wrote:
>>
>> On Linux the game right now is on a very very very very bad state,
>> it's just unplayable.
>>
>> Since a year ago (SVN revision 55) the menus texts aren't shown, it
>> was reported six months ago but nobody answered... but the thing is
>> nobody answers to a single bug report. Well, ok... answer to bug
>> reports is boring, but ten months Michael Brunton-Spall submitted a
>> patch for another problem (#1848584, I can verify the problem exists
>> and the patch fixes it)... and hasn't still been applied.
>> So... are the devs aware that there exists a bug report zone??
>> (seriously!! no offense intended...). From other projects hosted at
>> sourceforge looks like you can disable these bug report/patch submit
>> zones. So, if bugs are supposed to be reported on the mailing list or
>> somewhere else, disable the sourceforge zones could be a good idea.
>>
>> The Linux version has a lot more problems (at least on x86-64), but
>> the thing is... where should I report them?
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> fretsonfire-devel mailing list
>> fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/fretsonfire-devel
>
>

I have not been reading the bug reports on the source forge page.  I've been
getting them mostly from the community forum.  The SVN version has various
issues.  the 1.2.451 build was much more stable then 1.2.512

I'll look at disabling the bug report zone and try to point people to the
community forums.  I'm looking to update the version in the near future with
the devel code i'm working on.  I haven't been using the SVN repository like
i should, but once I merge them it should be easy.

Thanks for the email.

-Alex


On Sat, Nov 8, 2008 at 12:35 PM, Cristian Morales Vega <cmo...@ya...>wrote:

> On Linux the game right now is on a very very very very bad state,
> it's just unplayable.
>
> Since a year ago (SVN revision 55) the menus texts aren't shown, it
> was reported six months ago but nobody answered... but the thing is
> nobody answers to a single bug report. Well, ok... answer to bug
> reports is boring, but ten months Michael Brunton-Spall submitted a
> patch for another problem (#1848584, I can verify the problem exists
> and the patch fixes it)... and hasn't still been applied.
> So... are the devs aware that there exists a bug report zone??
> (seriously!! no offense intended...). From other projects hosted at
> sourceforge looks like you can disable these bug report/patch submit
> zones. So, if bugs are supposed to be reported on the mailing list or
> somewhere else, disable the sourceforge zones could be a good idea.
>
> The Linux version has a lot more problems (at least on x86-64), but
> the thing is... where should I report them?
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> fretsonfire-devel mailing list
> fre...@li...
> https://lists.sourceforge.net/lists/listinfo/fretsonfire-devel
>

On Linux the game right now is on a very very very very bad state,
it's just unplayable.

Since a year ago (SVN revision 55) the menus texts aren't shown, it
was reported six months ago but nobody answered... but the thing is
nobody answers to a single bug report. Well, ok... answer to bug
reports is boring, but ten months Michael Brunton-Spall submitted a
patch for another problem (#1848584, I can verify the problem exists
and the patch fixes it)... and hasn't still been applied.
So... are the devs aware that there exists a bug report zone??
(seriously!! no offense intended...). From other projects hosted at
sourceforge looks like you can disable these bug report/patch submit
zones. So, if bugs are supposed to be reported on the mailing list or
somewhere else, disable the sourceforge zones could be a good idea.

The Linux version has a lot more problems (at least on x86-64), but
the thing is... where should I report them?

Hi

I'm trying to get the latest FOF working from Subversion source.

I'm having quite a few problems getting it running.
I have a few questions.
1) Is the latest subversion source ( in a working condition, or is it in 
a broken state?
2) Is it possible to run FOF without making a build? (with make -f 
Makefile.unix)

The first error I get trying to run FOF from source is:
Traceback (most recent call last):
  File "./FretsOnFire.py", line 74, in <module>
    engine = GameEngine(config)
  File "/home/pico/games/fretsonfire_source/trunk/src/GameEngine.py", 
line 180, in __init__
    Mod.init(self)
  File "/home/pico/games/fretsonfire_source/trunk/src/Mod.py", line 32, 
in init
    for m in getAvailableMods(engine):
  File "/home/pico/games/fretsonfire_source/trunk/src/Mod.py", line 41, 
in getAvailableMods
    return [m for m in os.listdir(modPath) if 
os.path.isdir(os.path.join(modPath, m)) and not m.startswith(".")]
OSError: [Errno 2] No such file or directory: '../data/mods'

Obviously this can be solved by creating a mods directory under data, 
but I think FOF should not fail when it's missing. I've added a patch 
that I used to fix this.

The next problem that I run into is:
Traceback (most recent call last):
  File "./FretsOnFire.py", line 74, in <module>
    engine = GameEngine(config)
  File "/home/pico/games/fretsonfire_source/trunk/src/GameEngine.py", 
line 192, in __init__
    self.data = Data(self.resource, self.svg)
  File "/home/pico/games/fretsonfire_source/trunk/src/Data.py", line 48, 
in __init__
    self.loadSvgDrawing(self, "star1",   "star1.svg", textureSize = 
(128, 128))
  File "/home/pico/games/fretsonfire_source/trunk/src/Data.py", line 
108, in loadSvgDrawing
    drawing.convertToTexture(textureSize[0], textureSize[1])
  File "/home/pico/games/fretsonfire_source/trunk/src/Svg.py", line 577, 
in convertToTexture
    quality = self.context.getRenderingQuality()
  File "/home/pico/games/fretsonfire_source/trunk/src/Svg.py", line 118, 
in getRenderingQuality
    q = self.drawBoard.RenderingQuality()
AttributeError: GOpenGLBoard instance has no attribute 'RenderingQuality'

What has to be done to fix this?
I guess DummyAmanith.py needs more methods added to it so that it looks 
like the real Amanith library?

Thanks
Pico

Hi all,

Just wanted to give you all a little status update on what kind of
changes have been incorporated into SVN recently. Besides the usual
bugfixes (which we really should get out the door soon...), we've
removed the dependency on the Amanith vector graphics library. This
means that it is now much easier to get the game up and running on
different platforms, since Amanith and especially its python wrappers
are kind of a chore to compile. Furthermore the library is kind of
buggy and nowadays totally unmaintained.

Due to this change, we don't support loading SVG files at runtime
anymore, so images have to be rasterized to PNGs offline. This has the
added benefit of giving a nice performance boost and it even improves
image quality in most cases.

Another welcome change is the reworking of the build system. Now we
can build the distributed installation package with just one 'make'
command for Linux, Windows and Mac OS X. With a little more effort
this could also be turned into automated nightly builds.

Ultimately we would like to incorporate nice new features from some of
the popular mods to the trunk version, or at least make it easier for
modders to package and distribute their mods (i.e. allow code-altering
mods). This is of course difficult due to everyone's general lack of
time, but one step at a time it should be doable.

- Sami

Hi,

I suggest you try using the native win32 Python instead of the one
shipped with Cygwin. It looks like the errors you're experiencing
might be due to Cygwin's Python being unable to use the native win32
python modules. The following change to your Makefile should
accomplish this:

  PYTHON=/cygdrive/c/python25/python

- Sami

On Sun, Apr 20, 2008 at 11:17 PM, Tom Chen <to...@gm...> wrote:
> Hi,
>
>  I'm trying to build the frets source code on windows using cygwin. I
>  modified the Makefile constants to point to the dependencies on my
>  Windows machine. It initially had a missing opengl.gl error, so I got
>  PyOpenGL. I also obtained cx_freeze. When I modify the Makefile to
>  point to the correct PythonFreeze, Win32GUI.exe, and python library I
>  am getting an "IOError: [Errno 2] No such file or directory:
>  'c:\\python25\\cx_Freeze-3.0.3\\bases\\Win32GUI.exe". I think there
>  may be some cygwin/windows pathing problem -- I am not sure.
>
>  The top of my Makefile looks something like this (and indeed that is
>  where they are located):
>
>  CXFREEZE=/cygdrive/c/python25/cx_Freeze-3.0.3/FreezePython
>  CXFREEZE_BASE=`cygpath -w
>  \`/cygdrive/c/python25/cx_Freeze-3.0.3/bases/win32gui\``
>  PYTHON=python
>  PYTHON_LIBS=/cygdrive/c/python25/lib
>  MAKENSIS=/cygdrive/c/Program\ Files/NSIS/makeNSIS.exe
>
>  Alternatively I also tried using the Makefile.unix to build (using
>  cygwin's python 2.4 instead of windows' python 2.5 that I installed):
>
>  CXFREEZE=src/cx_Freeze-3.0.3/FreezePython
>  PYTHON=python
>  PYTHON_LIBS=/usr/lib/python2.4
>  VERSION=test
>  USE_AMANITH=1
>
>  and it gives me the error: "ImportError: No Module named
>  xml.sax.drivers2" even though I got the PyXML package.
>
>  Does anyone have any suggestions/experience on building in
>  windows/cygwin? I am using Windows with cygwin. On windows, I
>  installed python 2.5 via the win32 binary and I have python 2.4
>  installed from the cygwin installer.
>
>  Thanks,
>  --Thomas
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  fretsonfire-devel mailing list
>  fre...@li...
>  https://lists.sourceforge.net/lists/listinfo/fretsonfire-devel
>

Hi,

I'm trying to build the frets source code on windows using cygwin. I
modified the Makefile constants to point to the dependencies on my
Windows machine. It initially had a missing opengl.gl error, so I got
PyOpenGL. I also obtained cx_freeze. When I modify the Makefile to
point to the correct PythonFreeze, Win32GUI.exe, and python library I
am getting an "IOError: [Errno 2] No such file or directory:
'c:\\python25\\cx_Freeze-3.0.3\\bases\\Win32GUI.exe". I think there
may be some cygwin/windows pathing problem -- I am not sure.

The top of my Makefile looks something like this (and indeed that is
where they are located):

CXFREEZE=/cygdrive/c/python25/cx_Freeze-3.0.3/FreezePython
CXFREEZE_BASE=`cygpath -w
\`/cygdrive/c/python25/cx_Freeze-3.0.3/bases/win32gui\``
PYTHON=python
PYTHON_LIBS=/cygdrive/c/python25/lib
MAKENSIS=/cygdrive/c/Program\ Files/NSIS/makeNSIS.exe

Alternatively I also tried using the Makefile.unix to build (using
cygwin's python 2.4 instead of windows' python 2.5 that I installed):

CXFREEZE=src/cx_Freeze-3.0.3/FreezePython
PYTHON=python
PYTHON_LIBS=/usr/lib/python2.4
VERSION=test
USE_AMANITH=1

and it gives me the error: "ImportError: No Module named
xml.sax.drivers2" even though I got the PyXML package.

Does anyone have any suggestions/experience on building in
windows/cygwin? I am using Windows with cygwin. On windows, I
installed python 2.5 via the win32 binary and I have python 2.4
installed from the cygwin installer.

Thanks,
--Thomas

On 1/16/08, Alex Samonte <asa...@us...> wrote:
>
>
> The second thing I have been working on is getting a working mac version
> going.  I have a mac mini I borrowed and have been compiling all the
> required libraries.  The biggest snag so far....I'm using OSX 10.5.  A LOT
> of programatical API stuff changed in 10.5.  Several big ones, python2.5is included (instead of
> 2.4) pyobjc-2.0 is included (2.0 is for OSX 10.5 ONLY), also several
> programming APIs have been depreciated or removed.



So now I have a OSX 10.4 install and all the dependencies compiled.  I have
a nearly working mac version from source.   Right now there's some problems
in actually running things where I end up with an illegal instruction
error.   I don't think this is a FoF issue, but more something with the
underlying libraries.   I'm trying to track down what's triggering it.  I
believe it's an opengl call.   Since the OSX version uses an even older
opengl (2.0.1 instead of 2.0.2) I may try updating that library to see if it
solves the problem.

What I actually get on the screen right now is it starts up, reads the
fof.ini, i get a main screen, I get the menu.ogg playing, but as the main
menu items are showing up on the screen it crashes with the illegal
instruction.   So the good part is we're pretty close

-Alex

On 1/21/08, Sami Ky=F6stil=E4 <sam...@gm...> wrote:
>
> Hi Alex,
>
> > So I released a 4.15 quickly on new years and addressed both of the
> issues.
> > All seems well.
>
> Great news, congratulations on getting RF-mod 4.15 released.
>
> >  I then stumbled across bb_freeze.  This has been recently updated (dec
> 6,
> > 2007) and looked like it had a lot of the things I wanted.  Cross
> platform
> > (at least for windows/linux...no mac).  I gave it a try tonight and it
> > worked almost right out of the box.  It doesn't seem to have some of th=
e
> > bells and whistles that cx_freeze and py2app had, but i may just see if
> I
> > can modify the source and make it do that.  Two changes I'd like to
> fix.  1)
> > adding of the *.ico icon to the binary, and 2) a separate library
> subdir.
>
> BBFreeze seems like a good fit for the job. It looks like they've
> fixed many of the common annoyances we ran into with cx_Freeze and
> py2exe, such as unicode handling and egg-based modules. If you find
> that bbfreeze works well, I'm all for switching to it.
>
> Regarding icon replacement, cx_freeze doesn't have direct support for
> it either. What I did was change the icon of the thunk exe and then
> configured cx_freeze to use that modified thunk for building the final
> executable. Something like this should probably work for bbfreeze too,
> unless we want to add icon support directly into it.



[Alex] I think I'm going to add icon support directly into it.  I originall=
y
thought this was going to be easy, but apparently with py2exe this is
implemented via C functions which are called to do it (I thought it was pur=
e
python).    Overall bbfreeze seemed to work very well out of the box with
very little mess.  I have not tried it under Linux yet, and I'm going to se=
e
how that goes.


I agree with you on the messiness of the top-level directory.
> Cx_freeze is the worst in this regard and py2exe only a little better.
> An easy solution would be to just have a simple launcher exe at the
> top level, which simply executes the main program from a subdirectory.
> I'm not entirely sure you can put all the libraries into a
> subdirectory, since at least a rudimentary C runtime DLL will probably
> be needed at the top level for the launcher.



[Alex] I thought about doing it that way, but I think it limits us to using
some weird relative paths in game then (../data, etc)  From looking at what
bbfreeze does is it changes sys.path in python to the directory the program
is in.  It should not be hard to change, or add directory the program is
in+/libs.  Then depending on the OS it will either add that to the PATH or
LD_LIBRARY_PATH.  Again, I think easy to add /lib to that and unclutter.
But like the icon code, this is accomplished with some C bindings to
python.  So not as straight forward.  It does look promising though.

> The second thing I have been working on is getting a working mac version
> > going.  I have a mac mini I borrowed and have been compiling all the
> > required libraries.  The biggest snag so far....I'm using OSX 10.5.  A
> LOT
> > of programatical API stuff changed in 10.5.  Several big ones, python2.=
5is
> > included (instead of 2.4) pyobjc-2.0 is included (2.0 is for OSX 10.5ON=
LY),
> > also several programming APIs have been depreciated or removed.
> >
> > This makes compiling all the dependencies hard on OSX 10.5.
> pygame-1.7.1
> > requires pyobjc-1.4 and wont work with 2.0.  So right now I'm having a
> > difficult time getting stuff to compile just for the dependencies.  I
> feel
> > i'm going to have to install OSX 10.4 to get things working.  It should
> run
> > on a 10.5 box...I hope.
>
> This is great to hear. The mac build has been in a sorry state for
> quite some time now and people have been wondering whether it has been
> dropped for good. I guess the most problematic dependency is the
> Amanith library? I'm under the impression that most of the other
> libraries are pretty well maintained on the mac. If this is the case,



[Alex] Actually it's pygame which is the most problematic for 10.5.  pygame
requires pyobj-c.  pyobj-c was at version 1.4 for 10.4 and was kind of
sketchy for OSX.  They fixed a lot of things, and came out with
pyobj-c-2.0which supports OSX
10.5...but does not support pygame.  At this point I have a 10.4 install dv=
d
which I will install on another drive and build the dependencies.  the
macports project (similar to freebsd ports) seems to build most of the
dependencies fine so far (except for the 10.5 limitations of pygame so
far).  I'm not sure if amanith is a problem in 10.5 yet...haven't gotten to
that dependency.


I think we should work toward dropping the Amanith dependency for
> good. As the game already supports this for the Debian version, this
> should be pretty trivial thing to do. What do you think?




[Alex] For the amanith lib is that just being used for the .svg support?  I=
s
there an alternative (aside from not using svgs).  pygame i know is being
used for a number of things (which may also be possible to replace).  Those
types of changes I'll look into a little later.  As I mentioned in a
previous email I'm interested in what python-ogre has to offer as far as
some of the graphics and sound possibilities.

> If I can get that working then we will have 3 working platforms for FoF.
> > windows, linux, osx.  If I am feeling especially cocky, I might get a
> > freebsd one going too.
>
> Good. I think we should also start shipping a ready-to-run source
> package for Linux, since that's how most software is distributed in
> Linux anyway. Binary packages with a large set of dependencies have a
> bad habit of not running on a wide variety of distros. The same
> package might work for freebsd as well, if the dependencies are there.



[Alex] I'm not sure we can do that easily with linux.  The different
distributions have different libraries there by default as far as some of
the base dependencies go.  Also they may have different versions.   So
assuming we have a dependency list, the question will be does the
distribution have prebuilt binaries (rpm, deb, etc) for those dependencies.
If not, then you need to build them from source.   Since each distribution
is different I don't think we can come up with a single package or method
which will work for all of them.  The binary distribution with cx_freeze
works well because it packages up all the stuff it needs so it doesn't
matter what libraries you have.  In order to do something like that we woul=
d
need to build an entire dependency tree from sources for all distributions.
I'm actually more confident I can get a working one for mac easier than
linux because there's not a lot of variety in the different mac installs.
And the way macports works is by building the entire dependency tree from
sources (even if you already have some of them)

> In my work on OSX I noticed there is a new pyopengl-3.0 build...no longer
> > alpha, but beta...perhaps it will work better for FOF in the
> future...I'm
> > going to keep my eye on that.
>
> Yes, that's something we might want to keep an eye on. The performance
> of the alpha builds has been a little disappointing so far.



[Alex] I'm not really sure if we're missing anything from 2.0->3.0 as far a=
s
features we need.  sticking with 2.0 isn't necessarily bad, just not
supported.

-Alex


- Sami
>

Hi Alex,

> So I released a 4.15 quickly on new years and addressed both of the issues.
> All seems well.

Great news, congratulations on getting RF-mod 4.15 released.

>  I then stumbled across bb_freeze.  This has been recently updated (dec 6,
> 2007) and looked like it had a lot of the things I wanted.  Cross platform
> (at least for windows/linux...no mac).  I gave it a try tonight and it
> worked almost right out of the box.  It doesn't seem to have some of the
> bells and whistles that cx_freeze and py2app had, but i may just see if I
> can modify the source and make it do that.  Two changes I'd like to fix.  1)
> adding of the *.ico icon to the binary, and 2) a separate library subdir.

BBFreeze seems like a good fit for the job. It looks like they've
fixed many of the common annoyances we ran into with cx_Freeze and
py2exe, such as unicode handling and egg-based modules. If you find
that bbfreeze works well, I'm all for switching to it.

Regarding icon replacement, cx_freeze doesn't have direct support for
it either. What I did was change the icon of the thunk exe and then
configured cx_freeze to use that modified thunk for building the final
executable. Something like this should probably work for bbfreeze too,
unless we want to add icon support directly into it.

I agree with you on the messiness of the top-level directory.
Cx_freeze is the worst in this regard and py2exe only a little better.
An easy solution would be to just have a simple launcher exe at the
top level, which simply executes the main program from a subdirectory.
I'm not entirely sure you can put all the libraries into a
subdirectory, since at least a rudimentary C runtime DLL will probably
be needed at the top level for the launcher.

> The second thing I have been working on is getting a working mac version
> going.  I have a mac mini I borrowed and have been compiling all the
> required libraries.  The biggest snag so far....I'm using OSX 10.5.  A LOT
> of programatical API stuff changed in 10.5.  Several big ones, python2.5 is
> included (instead of 2.4) pyobjc-2.0 is included (2.0 is for OSX 10.5 ONLY),
> also several programming APIs have been depreciated or removed.
>
> This makes compiling all the dependencies hard on OSX 10.5.  pygame-1.7.1
> requires pyobjc-1.4 and wont work with 2.0.  So right now I'm having a
> difficult time getting stuff to compile just for the dependencies.  I feel
> i'm going to have to install OSX 10.4 to get things working.  It should run
> on a 10.5 box...I hope.

This is great to hear. The mac build has been in a sorry state for
quite some time now and people have been wondering whether it has been
dropped for good. I guess the most problematic dependency is the
Amanith library? I'm under the impression that most of the other
libraries are pretty well maintained on the mac. If this is the case,
I think we should work toward dropping the Amanith dependency for
good. As the game already supports this for the Debian version, this
should be pretty trivial thing to do. What do you think?

> If I can get that working then we will have 3 working platforms for FoF.
> windows, linux, osx.  If I am feeling especially cocky, I might get a
> freebsd one going too.

Good. I think we should also start shipping a ready-to-run source
package for Linux, since that's how most software is distributed in
Linux anyway. Binary packages with a large set of dependencies have a
bad habit of not running on a wide variety of distros. The same
package might work for freebsd as well, if the dependencies are there.

> In my work on OSX I noticed there is a new pyopengl-3.0 build...no longer
> alpha, but beta...perhaps it will work better for FOF in the future...I'm
> going to keep my eye on that.

Yes, that's something we might want to keep an eye on. The performance
of the alpha builds has been a little disappointing so far.

- Sami

Just wanted to drop everyone a quick note on what was going on.

I did the release of 4.14 for RF-mod on xmas.

I was told for the windows version I accidentally packaged the 4.12 version
again, oops.  For the linux version it worked for some, but not all.  There
were a few libraries that didn't quite make it.

So I released a 4.15 quickly on new years and addressed both of the issues.
All seems well.

It was my first time really using cx_freeze to get a linux standalone
binary.  Took a while to figure out, but it seemed to work.  Unfortunately
it seemed the cx_freeze 3.03 takes all the object files and stuff and
compiles them into the actual binary.  This makes it much more difficult for
people to do code mods like they can with py2exe with the library.zip file.

I know you had released 1.2.512 windows version using cx_freeze as well.
The same behavior happens with cx_freeze for windows (no library.zip).  I
investigated this a bit more, a while back the author of cx_freeze released
a 4.0b (beta?)  version that has support for that.  I tried it with linux
and it was a no go.  It did not handle importing of some of the existing
libraries correctly (specifically the xml/xmlplus stuff, and sax).  This
version while newer than 3.03 has not been updated in a long time.  I
screwed around with that for several days with little progress.  I was going
to look at modifying the source to fix some of the things broken in 4.0 that
worked in 3.03.

I then stumbled across bb_freeze.  This has been recently updated (dec 6,
2007) and looked like it had a lot of the things I wanted.  Cross platform
(at least for windows/linux...no mac).  I gave it a try tonight and it
worked almost right out of the box.  It doesn't seem to have some of the
bells and whistles that cx_freeze and py2app had, but i may just see if I
can modify the source and make it do that.  Two changes I'd like to fix.  1)
adding of the *.ico icon to the binary, and 2) a separate library subdir.

2) is actually an issue for all versions of cx_freeze, py2exe and py2app.  I
feel the main directory of FoF is cluttered (especially with CX freeze).
The directory structure currently looks like

FOF-|
       |----data

With py2exe FOF contains some extra libraries (a small managable set), and
then data contains FOF required data files (dae, svg, etc), plus
library.zipand various DLL's and stuff that make things run
standalone.

With cx_freeze, data is just the FOF data (good), and mods and songs, and
translations but all the rest of the garbage is in the top level directory.

I'd like to have a layout like this:

FOF--|
        |----data (just data files)
        |----mods
        |----songs
        |----translations
        |----libraries

That looks so much cleaner and sexier!   I believe that I can modify
bb_freeze to put all the required libaries in a specified directory (I need
to add that code).  The rest I can modify the normal FOF code to get a
working layout like that.

That's a lot of typing for a simple cleanup.

The second thing I have been working on is getting a working mac version
going.  I have a mac mini I borrowed and have been compiling all the
required libraries.  The biggest snag so far....I'm using OSX 10.5.  A LOT
of programatical API stuff changed in 10.5.  Several big ones, python2.5 is
included (instead of 2.4) pyobjc-2.0 is included (2.0 is for OSX 10.5 ONLY),
also several programming APIs have been depreciated or removed.

This makes compiling all the dependencies hard on OSX 10.5.
pygame-1.7.1requires
pyobjc-1.4 and wont work with 2.0.  So right now I'm having a difficult time
getting stuff to compile just for the dependencies.  I feel i'm going to
have to install OSX 10.4 to get things working.  It should run on a
10.5box...I hope.

If I can get that working then we will have 3 working platforms for FoF.
windows, linux, osx.  If I am feeling especially cocky, I might get a
freebsd one going too.

In my work on OSX I noticed there is a new pyopengl-3.0 build...no longer
alpha, but beta...perhaps it will work better for FOF in the future...I'm
going to keep my eye on that.

So once I get bb_freeze finalized, I'm going to start the work on FoF-1.3.X.
Should be pretty exciting.

-Alex

On 12/19/07, Sami Ky=F6stil=E4 <sam...@gm...> wrote:
>
> Hi Alex,
>
> Just a quick comment on the features listed below. It looks like there
> is quite a few things to tweak here, which raises the question of
> whether this degree of customization is really needed? The number of
> options here is quite overwhelming and I'm pretty sure most people
> won't even understand most of these settings. This is, of course, my
> personal opinion and you might have a different idea. I would still
> propose that we go through these options and choose the ones that
> really make a difference and drop the rest. For instance, I find it
> hard to see why we would need many different HOPO key detection
> schemes, and choosing a single working HOPO scheme might also be
> possible. Also, the POV options are unlikely to affect scoring, so it
> might not need to be reflected in the charts. It might also make sense
> to change the built-in defaults of the game for some settings instead
> of introducing a configuration option.


[Alex] Well the main reasons for the options is because they differed from
the FoF defaults.  It originally started out as improvements to make HOPOs
better.  In RF-mod-3.5 I made my keystyle the ONLY option.  There were
improvements in  the HOPO fudge detection (ability to strum HOPO sections)
which made strumming HOPO sections doable there were also improvements in
picking up a HOPO streak.

[Alex] In converting from 1.1.324 to 1.2.451, the base type of key detectio=
n
seemed to change, and I came up with a much better way to do the key
detection.  It required lots of rewriting of stuff.   This keystyle i think
VASTLY improved gameplay and made being able to pick up a HOPO streak
possible.  I think it was ready for normal use in my upcoming version as I
worked out all the obvious bugs.  I was going to replace RFmod keystyle wit=
h
RFmod2 keystyle.

[Alex] One thing I learned in making modifications is lots of people hate
change.  This can be seen in the 1.1.324 to 1.2.451 resistance, to even
RF-mod-3.5 to RF-mod-4.   One thing that helped was options.  There are lot=
s
of options which people play with from the various mods.

[Alex] 2 note chords, variable BPM disabled, HOPO disabled, capo hit
margins, 8th note hopos, board speed are definitely all options people use.
All of them affect score and probably should be represented.

[Alex] the POV one, i am not convinced people use, but it was there for
completeness.   the easy/medium/hard margin options are not implemented yet=
,
but i imagine those will be HIGHLY used (makes the game easier or harder)

[Alex] The HOPO markings, and HOPO styles are really there because many
people liked, or got used to the FoF Defaults.  Now i have no problem makin=
g
those the new defaults with new versions of FoF, but i'm not sure people
will like that.  Also people still use old version with the old behavior.  =
I
wanted to be able to represent the differences.  RFmod-4.12 and before use
RF-mod keystyle and markings by default.  4.14 and beyond use RFmod2
keystyle.   They operate differently enough I would really like to represen=
t
the difference.

[Alex] Right now my personal opinon is that I don't think reducing the
options will help because they already exist out in the wild.  I just want
some icons to represent them.  They are easily saved and represented in the
scores.  If it turns out that everyone is using the same options it may be
easy to say 'oh well we will just get rid of the RFmod keystyle because
everyone is using RFmod2 keystyle, I have no problem with that.  But until
we're keeping track of it we're just going by gut instinct.  It's not reall=
y
anything the players themselves need to keep track of

-Alex



>
> Also, let's finally move this discussion to the mailing list :)



[Alex] Am I on the mailing list by default?  or do I need to sign up for it=
?

Hi Alex,

Just a quick comment on the features listed below. It looks like there
is quite a few things to tweak here, which raises the question of
whether this degree of customization is really needed? The number of
options here is quite overwhelming and I'm pretty sure most people
won't even understand most of these settings. This is, of course, my
personal opinion and you might have a different idea. I would still
propose that we go through these options and choose the ones that
really make a difference and drop the rest. For instance, I find it
hard to see why we would need many different HOPO key detection
schemes, and choosing a single working HOPO scheme might also be
possible. Also, the POV options are unlikely to affect scoring, so it
might not need to be reflected in the charts. It might also make sense
to change the built-in defaults of the game for some settings instead
of introducing a configuration option.

Also, let's finally move this discussion to the mailing list :)

- Sami

On Dec 19, 2007 5:33 PM, Alex Samonte <asa...@pr...> wrote:
> On 12/18/07, Joonas Kerttula <joo...@gm...> wrote:
> > Are those icons coming to the game or to the charts?
>
> [Alex] Actually both.  The charts need png icons, the game needs them in svg
> format (similar in size to the multiplier balls or the stars)
>
> To look at my first stab at icons for the web check out:
> http://www.prison.net/FoF-Chart/chart.php
>
> Here's something i wrote up to kind of describe what each was for and some
> possible ideas for each.
>
> 2 note chords
>   Description
>   When playing chords, many keyboards cannot hold down more than 3 keys at a
> time.  so if you chords consisting of two notes, you can usually hold those
> and press the pick button.  For chords with 3 or more notes, usually some
> button does not register.  With two note chords you can play these 3+ note
> chords by just pressing the two outer notes of the chord and picking. Ex:  A
> chord of GRYB can be played by picking GB
>
>   Icon ideas
>   A simple 2
>   a hand with index and pinky held down (won't translate into 16x16 well)
>   3 or 4 color bars with the outer ones glowing
>
> VBPM off
>   Description
>   Within some songs are tempo markers.  These speed up or slow down the
> beats per minute of the song.  In game this causes the notes to come at you
> faster or slower. This does not change the speed at which you play the
> notes, it just either shows more or less notes on the screen and they have a
> lower or higher velocity.  Turning this off keeps the BPM constant and the
> velocity constant.
>
>
>   Icon ideas
>   A watch/clock with a stop/disabled sign.
>   A speedometer pegged at 55 (might be hard to get numbers on a 16x16 icon)
>
>
> HOPO off
>   Description
>   Notes that are a certain closeness together can be HOPOed (Hammer on, pull
> off).  This means that you can play the next note by just pressing that key,
> rather than pressing that key and picking.   With HOPOs off this is disabled
>
>   Icon ideas
>   Hammer with an anti symbol though it.
>   Hammer with a stop/disabled sign
>
> HOPO Marks RFmod
>   Description
>   The original algorithm for which notes can be HOPO notes was not very
> accurate.  An improved one (which makes it more like GH) was implemented.
>
>   Icon ideas
>   notes or dots of 3 or 4 colors
>
> HOPO Marks Explicit
>   Description
>   Similar to the previous except instead of being calculated, the HOPO
> sections are explicitly defined in the song
>
>   Icon ideas
>   notes or dots of 3 or 4 colors with a different color scheme than the last
> or maybe a different note/dot style
>
> HOPO Style RFmod
>   Description
>   In game I call this a 'key style' because it's a modification on how key
> presses are detected
>
>   Icon ideas
>   3 keyboard keys in a row perhaps with a small letter or icon in the lower
> corner
>   Some style of guitar (or perhaps just the neck)
>
> HOPO Style RFmod2
>   Description
>   Similar to the last it's just another key detection method
>
>   Icon ideas
>   3 keyboard keys in a row, perhaps with a different small letter, or icon
> in the lower corner.  Perhaps a different color scheme
>   some different style of guitar (or perhaps just neck)
>
> POV GH
>   Description
>   The angle of the fretboard when playing is set to a more GH angle
>
>   Icon ideas
>   A fretboard (or just a plane) perspective with a small letter or icon in
> the lower corner.
>
> POV Custom
>   Description
>   The angle of the fretboard whe playing is set to some custom angle
>
>   Icon ideas
>   A fretboard (or just a plane) perspective with a small letter or icon in
> the lower corner.
>
> Margin Easy
>   Description
>   The allowable time before and after when a note crosses the hit mark that
> a note can still be hit.  This is the largest value
>
>   Icon ideas
>
>   A single line in the middle with a different colored bar extending up and
> down above the line as tall as the icon is.
>
> Margin Hard
>   Description
>   The allowable time before and after when a note crosses the hit mark that
> a note can still be hit.  This is the smallest value
>
>   Icon ideas
>
>   A single line in the middle with a different colored bar extending up and
> down above the line just a little bit
>
> Margin Medium
>   Description
>   The allowable time before and after when a note crosses the hit mark that
> a note can still be hit.  This is the middle value
>
>   Icon ideas
>
>   A single line in the middle with a different colored bar extending up and
> down above the line less than the easy one, but more than the hard.
>
> Margin Capo
>   Description
>   The allowable time before and after when a note crosses the hit mark that
> a note can still be hit.  In this variation there's a maximum cap on the
> value (regardless of other factors)
>
>   Icon ideas
>
>   A single line in the middle with a different colored bar extending up and
> down above the line similar in size to medium, but on the top of the bar put
> a baseball cap
>
> A single line in the middle with a different colored bar extending up and
> down above the line similar in size to medium, but on the top of the bar
> have a dotted line that crosses
>
> 8th note HOPOs
>   Description
>   Normally the HOPOs are computed by any notes that are closer than an 8th
> note together (16th notes) are counted as  HOPO notes.  Some songs have
> anything closer than a quater note (8th note) as HOPO notes.
>
>
>   Icon ideas
>
>   two 8th notes
>
> Board Speed
>   Description
>   Normally the board speed is dependant on the tempo and BPM.  With this
> option the board speed is linked to the difficulty played.  Similar to the
> VBPM option, but can be used with and without it
>
>   Icon ideas
>   A watch/clock with a link icon.
>   A speedometer with a link icon (might be hard to differentiate between
> this and watch/clock on a 16x16 icon)
>
> -Alex
>
>
>