Open ashes999 opened 11 years ago
About 1) that is intentional, since loading times on phones is significantly higher than on PCs I think that it is better not to wait for the song to be loaded and start the game as soon as possible. Does it makes sense to you?
About 2), that happens because I did not fully implemented all possible song combinations ( start, stop, start again, ..) taking into account android media player different states. But simply that you could at least load one song and start/stop it. I know it is not best coding practice sorry for that. I'll definitely fix that soon enough.
@neochuky it would be really useful to be able to tell when a sound sample ends. That would enable a lot of other behaviours (like not starting when it's playing) from a wrapper class. Would that be easier than what you have?
Don't worry about coding practices. Following the 80/20 rule, you did 20% of the work and got 80% of what people need. I'm just looking at what I, specifically, need, which may be different from what other people need.
Is this possible to do on the original Gosu gem? If so how? By the way, why is the issue closed?
I'm not sure. I thought I was using the original Gosu for audio, but I remembered that Gosu uses OpenAL, which doesn't work on Windows XP. I was actually testing it against a different library (probably fmod), which is why the whole issue is invalid and unimportant.
So I closed it. Please feel free to disregard :)
I still thing the second point might be a bug, or something to improve in future releases, but it's not a problem for me right now, anyway.
So I finally got OpenAL (and by extension, Gosu) audio to work, after months of trying this and that. Now I've verified that the second issue (audio plays repeatedly) is an issue, so I'm reopening this.
I'm not in a hurry to get this closed, and I am pushing my own architectural direction (keep gosu_android
as similar to gosu
as possible so people can easily use both), but I would like some help fixing this. I looked through the code (Ruby side) and didn't find a solution.
I tried to solved this today, but I am having problems with android listeners that are never called.
For future reference commits are f382adf8507753a8a843a8ba57c63179494ffb61 and 5161ce4de7b3d430717463f1ceff0dd379cff8f8.
I'll keep thinking about this, maybe I'll figure something out.
Ping :)
I am so sorry, but I have got engaged in other projects so I am not going to develop gosu-android in the foreseeable future. If you feel up to it I'd gladly accept pull requests, the solution to this could be to set up a listener to OnCompletion and have a pool of songs to be played next. Then whenever a song finishes, start playing the next one in the pool. In any case I think this will be easier to do in Java, so a first step would be to rewrite the audio file to Java.
Hi,
I noticed two distinct differences between Gosu and android-gosu.
1) If I load a huge sound (5MB+) in
MainWindow.initialize
, gosu freezes with the game not loaded or displaying anything, while gosu-android starts the game and the sound loads later. 2) If indraw
orupdate
I callsound.play
(I know, I know, it's crazy), gosu waits until the sound finishes before restarting it (normal looping). gosu-android stops and restarts, so it sounds like the first fractional second of the sound is stuck.The first issue is not really a problem (where's my Ruboto loading screen?!), but I would like to resolve the second issue. I'll take a look at the code tonight if I can, and see if it's easy to do so. Please confirm if that change is okay with you :)
@neochuky