If you are thinking about running from svn, please do the entire community a favor and read this thread first. It contains some important information that anyone thinking about running from svn should be familiar with.
Please don't ask when this is going to be released. If you just read a page in this topic here and there you'll find out our response to said question that's even stated in the forum rules to not ask.
We currently only have 2 active developers working on FoFiX so it's going to take even longer now. One year is nothing for a game, most professional games take a few years to make and they have teams of sizes close to 100 people or more. A good chunk of the system is going under rewrite.
Once more I bring up the prime example of Stepmania, they've been in alpha for 4 years now and have a development team of around 10 people. At our current rate, things might end up like that if we don't get more people to help us out. You see all these other music game projects and how active they currently are, the ones with small teams that aren't paid are most likely going to die off in a year if not less time no matter how dedicated the developer looks now.
Python and FoF
Spoiler:
blazingamer wrote:I still don't like you people that say Python is the reason why the game goes slowly. It's not python that makes the game slow, the only thing that is slower in python than c is the compile time and the variable type signing (since it's dynamic) but if you keep variables the same type the whole time then it won't go slower than c. The only reason why these C versions that people keep making are faster is because the code is seriously bare bones. If you look at all the different passes and modules that FoF has to go through compared to one of those games, in addition to the way math is handled, you'll see why FoFiX lags so much. The code is written from an excessively modular base that is poorly written for what it needs to do, it could be simpler and as a result faster. Not only that, but most of these C games are written in directX and are windows only, most graphics cards are optimized for directX over openGL, so of course it's going to run faster if it's directX, the only reason why FoF is openGL is because the developers wanted it to be cross platform.
So, before you start blaming python for the reason why FoF is slow look at the code yourself and see why. If it was written in C except everything was kept in tact the same way it is written in python, it will go just about as slow, maybe a just maybe little faster just because C can do math faster.
Because it's one of those "when it's done" things. There's no set schedule.
Contact me:
Before you PM me, consider: Perhaps the question has already been answered? Use the search function. Perhaps other members of the community can help? Try posting a new topic. Perhaps you need to gain the attention of any or all moderators? Use the report feature.
Before you PM me, consider: Perhaps the question has already been answered? Use the search function. Perhaps other members of the community can help? Try posting a new topic. Perhaps you need to gain the attention of any or all moderators? Use the report feature.
I've testet the 4.0.0. dev.version of fofix and what I've seen was an amazing performance improvement. 4 players on FullHD with the RB2 theme and still 50 frames/sek. Perfect! In the old version 3 I'reached only 12-15 frames - not suitable for playing.
Now, I have one question.
Is it possible to include only the multicore-support / load balancing and maybe the new OpenGL optimization libraries into the 3.121 FoFix version? I think this would solve the biggest problem for a lot of the FoFiX players - the shrinking frame rate during the multiplayer mode. Maybe you only have to change some classes within the working 3.121 program core.
All further dev. steps to redesign the game can follow later.
Once we're ready to release 4.0 in any form, whether it be beta, release candidate, or final, I personally would love to backport some things into the 3.xxx maintenance branch. Things such as the somewhat rewritten image handling code, possibly video backgrounds, improved microphone support, improved midi/note handling, and more things that deal with engine compatibility and performance, not things that deal specifically with themes.
Python and FoF
Spoiler:
blazingamer wrote:I still don't like you people that say Python is the reason why the game goes slowly. It's not python that makes the game slow, the only thing that is slower in python than c is the compile time and the variable type signing (since it's dynamic) but if you keep variables the same type the whole time then it won't go slower than c. The only reason why these C versions that people keep making are faster is because the code is seriously bare bones. If you look at all the different passes and modules that FoF has to go through compared to one of those games, in addition to the way math is handled, you'll see why FoFiX lags so much. The code is written from an excessively modular base that is poorly written for what it needs to do, it could be simpler and as a result faster. Not only that, but most of these C games are written in directX and are windows only, most graphics cards are optimized for directX over openGL, so of course it's going to run faster if it's directX, the only reason why FoF is openGL is because the developers wanted it to be cross platform.
So, before you start blaming python for the reason why FoF is slow look at the code yourself and see why. If it was written in C except everything was kept in tact the same way it is written in python, it will go just about as slow, maybe a just maybe little faster just because C can do math faster.
Before you PM me, consider: Perhaps the question has already been answered? Use the search function. Perhaps other members of the community can help? Try posting a new topic. Perhaps you need to gain the attention of any or all moderators? Use the report feature.