Reenable sounds in Kolf
ClosedPublic

Authored by yurchor on Nov 18 2018, 2:41 PM.

Details

Summary

Once upon a time Phonon was unreliable, sounds were buggy and prevent you from playing Kolf as you like. It seems those days have been gone.

Test Plan

Start recompiled Kolf, choose the game, play. Sounds should be audible without problems.

Diff Detail

Repository
R407 Kolf
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
yurchor created this revision.Nov 18 2018, 2:41 PM
Restricted Application added a subscriber: kde-games-devel. · View Herald TranscriptNov 18 2018, 2:41 PM
yurchor requested review of this revision.Nov 18 2018, 2:41 PM
aacid accepted this revision.Nov 18 2018, 5:39 PM
aacid added a subscriber: aacid.

the wall sound is not played, any idea when that was lost form the code?

Also i thnk we should eventually move to kgsound, but that's for another time.

I guess you can commit, but if you could investigate why the wall sound was removed it'd be nice, since it feels weird not to have it playing (the wall.wav is there)

This revision is now accepted and ready to land.Nov 18 2018, 5:39 PM

the wall sound is not played, any idea when that was lost form the code?

Also i thnk we should eventually move to kgsound, but that's for another time.

I guess you can commit, but if you could investigate why the wall sound was removed it'd be nice, since it feels weird not to have it playing (the wall.wav is there)

It seems that it was removed in 5fb04e3feca8c15b4deb6d86ce37fd4e5e898e99 and never have been restored. On the overloaded machine (e.g. when Baloo has decided to take the rule) even now sounds can lead to the tearing in the ball movement. Anyway, it is better explicitly switch off the sound than trying to decide why it is not working (and even not compiled), imho.

yurchor updated this revision to Diff 45741.EditedNov 18 2018, 6:50 PM

Enable sound for wall and putter collisions. Additional testing needed.

the wall sound is not played, any idea when that was lost form the code?

Also i thnk we should eventually move to kgsound, but that's for another time.

I guess you can commit, but if you could investigate why the wall sound was removed it'd be nice, since it feels weird not to have it playing (the wall.wav is there)

It seems that it was removed in 5fb04e3feca8c15b4deb6d86ce37fd4e5e898e99 and never have been restored. On the overloaded machine (e.g. when Baloo has decided to take the rule) even now sounds can lead to the tearing in the ball movement. Anyway, it is better explicitly switch off the sound than trying to decide why it is not working (and even not compiled), imho.

Do you think you can give it a try porting to kgsound? technically it's supposed to be much less resource intensive and shouldn't be "too hard" (TM)

the wall sound is not played, any idea when that was lost form the code?

Also i thnk we should eventually move to kgsound, but that's for another time.

I guess you can commit, but if you could investigate why the wall sound was removed it'd be nice, since it feels weird not to have it playing (the wall.wav is there)

It seems that it was removed in 5fb04e3feca8c15b4deb6d86ce37fd4e5e898e99 and never have been restored. On the overloaded machine (e.g. when Baloo has decided to take the rule) even now sounds can lead to the tearing in the ball movement. Anyway, it is better explicitly switch off the sound than trying to decide why it is not working (and even not compiled), imho.

Do you think you can give it a try porting to kgsound? technically it's supposed to be much less resource intensive and shouldn't be "too hard" (TM)

I do not know (it might need a very heavy fuel as we see on the KolourPaint example). No hard promises in our business. ;)

First things first. Kolf should be ported away from kdelibs4support to make it safe for the next several years and Kolf should keep its full set of features. Optimizations can wait, imho

aacid added a comment.Nov 19 2018, 6:32 PM

the wall sound is not played, any idea when that was lost form the code?

Also i thnk we should eventually move to kgsound, but that's for another time.

I guess you can commit, but if you could investigate why the wall sound was removed it'd be nice, since it feels weird not to have it playing (the wall.wav is there)

It seems that it was removed in 5fb04e3feca8c15b4deb6d86ce37fd4e5e898e99 and never have been restored. On the overloaded machine (e.g. when Baloo has decided to take the rule) even now sounds can lead to the tearing in the ball movement. Anyway, it is better explicitly switch off the sound than trying to decide why it is not working (and even not compiled), imho.

Do you think you can give it a try porting to kgsound? technically it's supposed to be much less resource intensive and shouldn't be "too hard" (TM)

I do not know (it might need a very heavy fuel as we see on the KolourPaint example). No hard promises in our business. ;)

First things first. Kolf should be ported away from kdelibs4support to make it safe for the next several years and Kolf should keep its full set of features. Optimizations can wait, imho

kdelibs4support is as sake as KF5, they will both disappear at the same time, so porting away from kdelibs4support doesn't really give you a "lot" of future proofing.

But up to you :)

the wall sound is not played, any idea when that was lost form the code?

Also i thnk we should eventually move to kgsound, but that's for another time.

I guess you can commit, but if you could investigate why the wall sound was removed it'd be nice, since it feels weird not to have it playing (the wall.wav is there)

It seems that it was removed in 5fb04e3feca8c15b4deb6d86ce37fd4e5e898e99 and never have been restored. On the overloaded machine (e.g. when Baloo has decided to take the rule) even now sounds can lead to the tearing in the ball movement. Anyway, it is better explicitly switch off the sound than trying to decide why it is not working (and even not compiled), imho.

Do you think you can give it a try porting to kgsound? technically it's supposed to be much less resource intensive and shouldn't be "too hard" (TM)

I do not know (it might need a very heavy fuel as we see on the KolourPaint example). No hard promises in our business. ;)

First things first. Kolf should be ported away from kdelibs4support to make it safe for the next several years and Kolf should keep its full set of features. Optimizations can wait, imho

kdelibs4support is as sake as KF5, they will both disappear at the same time, so porting away from kdelibs4support doesn't really give you a "lot" of future proofing.

But up to you :)

I would agree, but the community has already abandoned some of my favorite applications (KFileReplace, KRecipes). I have to work on porting because I think that the constant changing of basic Qt API, poor decisions on fracturing KDE and wasting time on the dead-born parts like Baloo and Activities will leave me without some dozens of useful tools during the next iteration. Just because "there is too much to port".

It was too safe to be just a translator for years. But there is no choice anymore. The team is so underpowered and full of "designers" that now our "bus factor" for most of the projects is 1. Just look at the poor Konqueror. Once it was our symbol and now it is almost dead, definitely the first candidate for the grave in Applications.

What if tomorrow kgSound will be "optimized"? Phonon will survive because it's more widely used.

Anyway, if noone objects I will try to commit this for a week.

I would agree, but the community has already abandoned some of my favorite applications (KFileReplace, KRecipes). I have to work on porting because I think that the constant changing of basic Qt API, poor decisions on fracturing KDE and wasting time on the dead-born parts like Baloo and Activities will leave me without some dozens of useful tools during the next iteration. Just because "there is too much to port".

I'd really like if you stopped bad mouthing other people efforts. You don't like Baloo, fine, don't use it, but don't shit on the work done by other community members. Also cut the bullshit with "fracturing KDE", what is that even supposed to mean?

It was too safe to be just a translator for years. But there is no choice anymore. The team is so underpowered and full of "designers" that now our "bus factor" for most of the projects is 1. Just look at the poor Konqueror. Once it was our symbol and now it is almost dead, definitely the first candidate for the grave in Applications.

You speak as if having designers is bad.

What if tomorrow kgSound will be "optimized"? Phonon will survive because it's more widely used.

You strongly misinterpret how much phonon is maintained/used.

I would agree, but the community has already abandoned some of my favorite applications (KFileReplace, KRecipes). I have to work on porting because I think that the constant changing of basic Qt API, poor decisions on fracturing KDE and wasting time on the dead-born parts like Baloo and Activities will leave me without some dozens of useful tools during the next iteration. Just because "there is too much to port".

I'd really like if you stopped bad mouthing other people efforts. You don't like Baloo, fine, don't use it, but don't shit on the work done by other community members. Also cut the bullshit with "fracturing KDE", what is that even supposed to mean?

I cannot. I try to be a part of the team. My distribution (Mageia) cares of its users and switches it off by default, but I switch it on again everytime to test. I leave my machine running for several hours just for indexing, have ~3GB index file and still cannot find files that I'm looking for. Ok. Is it harmless? No. It still hangs my system on ~30 secs from time to time to update its index. Other cool success stories can be read by "KDE Baloo success" in Google.

Kudos to the Dolphin team for allowing other search methods (KFind) at last.

That is my personal opinion after using Nepomuk/Baloo for 10 years: we should not mark KNumInput deprecated, it would be better to mark Baloo deprecated. Its commercial implementation (Refinder) is dead for 5 years already.

On fracturing: GTK+ and Qt have just several parts and mostly monolithic. We had monolithic kdelibs for some time. It was decided to fracture kdelibs into ~100 frameworks to engage Qt developers and be successful in the Qt world. Now we search documenters to explain what was done and have the Release notes in the style "Revert "Revert the commit"", "Allow it work". It's like to go to the library and receive 300 separate pages instead of the one book. That's what I call "fracturing".

It was too safe to be just a translator for years. But there is no choice anymore. The team is so underpowered and full of "designers" that now our "bus factor" for most of the projects is 1. Just look at the poor Konqueror. Once it was our symbol and now it is almost dead, definitely the first candidate for the grave in Applications.

You speak as if having designers is bad.

They are good when they do not conflict with the most valuable part of the community - developers.

What if tomorrow kgSound will be "optimized"? Phonon will survive because it's more widely used.

You strongly misinterpret how much phonon is maintained/used.

Or I realistically see the current power of libkdegames support.

yurchor updated this revision to Diff 46216.Nov 25 2018, 5:39 PM

Port to KgSound. Add missing sound (remastered Audacity effect).

The game became much more responsive. Many thanks for the suggestion to port it.

aacid added inline comments.Nov 26 2018, 10:40 PM
game.cpp
48

this should go now?

yurchor updated this revision to Diff 46299.Nov 27 2018, 5:26 AM

All the leftovers of phonon dependency were removed. Thanks.

sitter added a subscriber: sitter.Nov 27 2018, 12:46 PM

I haven't read all the comments but I want to make a thing clear because I just stumbled over the diff and saw some argument over Phonon or not. So, let me put on my Phonon dev hat and say: Phonon is not and never was a suitable framework for these types of use cases. It entirely lacks relevant API and the API it has is designed around different requirements altogether. What you want for short samples that need playback with low-latency is libcanberra or OpenAL.

I haven't read all the comments but I want to make a thing clear because I just stumbled over the diff and saw some argument over Phonon or not. So, let me put on my Phonon dev hat and say: Phonon is not and never was a suitable framework for these types of use cases. It entirely lacks relevant API and the API it has is designed around different requirements altogether. What you want for short samples that need playback with low-latency is libcanberra or OpenAL.

@sitter We're using OpenAL now

aacid added inline comments.Nov 27 2018, 11:17 PM
game.cpp
450

Please fix the reordering warning this creates.

game.h
267

Having member variables public is "bad programming".

They should be in private, hidden behind a playSound(EnumValue ev) or similar.

yurchor marked 2 inline comments as done.Nov 28 2018, 6:34 AM

Thanks. Both suggestion are implemented (I hope).

yurchor updated this revision to Diff 46370.Nov 28 2018, 6:35 AM

Make m_sound and sounds private, reorder initialization sequence to avoid warnings.

aacid accepted this revision.Nov 28 2018, 10:39 PM
This revision was automatically updated to reflect the committed changes.