crash OpenAL

[71104]

il crash che avviene ogni tanto nel gioco è dovuto a OpenAL (più raramente a un problema di gestione delle stones), e la causa sembra essere il modo errato in cui utilizzo la classe DroppableFactory in StoneFallState; in attesa che io scopra come va utilizzata quella classe (mi serve per inizializzare correttamente le animazioni delle stones) vi evidenzio nel codice qui riportato (che si trova in DroppableFactory.java) le righe che dovete commentare per poter giocare senza crash:

package it.diamonds.gems;


import it.diamonds.engine.Config;
import it.diamonds.engine.audio.Sound;


public class DroppableFactory
{
private Sound sound;

private int gemAnimationUpdateRate;

private int gemAnimationDelay;



public DroppableFactory(Config config)
{
sound = new Sound("diamond");
gemAnimationUpdateRate = config.getInteger("GemAnimationUpdateRate");
gemAnimationDelay = config.getInteger("GemAnimationDelay");
}


public static DroppableFactory createForTesting()
{
return new DroppableFactory(Config.createForTesting());
}


private Droppable setupGemAnimationAndSound(Droppable newGem)
{
newGem.setCollisionSound(sound);
newGem.createAnimationSequence(gemAnimationUpdateRate);

return newGem;
}


public Droppable create(DroppableType type, DroppableColor color)
{
Droppable newDroppable = null;

if (type.isChest())
{
newDroppable = Chest.create(color, gemAnimationDelay);
}
else
if (type.isFlashingGem())
{
newDroppable = FlashingGem.create();
}
else
if (type.isGem())
{
newDroppable = Gem.create(color, gemAnimationDelay);
}
else
if (type.isStone())
{
newDroppable = Stone.create(color);
}

return setupGemAnimationAndSound(newDroppable);
}


public Droppable createFlashingGem()
{
return create(DroppableType.FLASHING_GEM, null);
}


public Droppable createStone(DroppableColor color)
{
return create(DroppableType.STONE, color);
}
}

qualcuno che se ne intende di questa classe potrebbe per cortesia guardare come l'ho utilizzata in StoneFallState e dirmi cosa c'è di sbagliato?? :cry: :cry: :cry:

[BlueDragon]

Ciao 71104,
il problema è che OpenAL gestisce un limitato numero di fonti (il numero esatto credo dipenda dalla scheda audio del pc).
Ad ogni Sound noi associamo una nuova fonte.
Ogni DroppableFactory ha 1 solo Sound che usa per tutte le gemme che crea.
Purtroppo StoneFallState crea una nuova factory per ogni sua istanza.
CrushState crea nel tempo vari StoneFallState, ed alla fine il numero delle fonti sonore generate supera il massimo gestibile...crash! :)

[thebol]

Ciao 71104,
il problema è che OpenAL gestisce un limitato numero di fonti (il numero esatto credo dipenda dalla scheda audio del pc).
Ad ogni Sound noi associamo una nuova fonte.
Ogni DroppableFactory ha 1 solo Sound che usa per tutte le gemme che crea.
Purtroppo StoneFallState crea una nuova factory per ogni sua istanza.
CrushState crea nel tempo vari StoneFallState, ed alla fine il numero delle fonti sonore generate supera il massimo gestibile...crash! :)

\o/ singletone \o/ su dropfactory

o su una factory di oggetti sound, che va creata in gameLoop e comune a i 2 playField.

oppure lo si passa tramite parametro da gameLoop fino al gridController

[fek]

\o/ singletone \o/ su dropfactory

o su una factory di oggetti sound, che va creata in gameLoop e comune a i 2 playField.

oppure lo si passa tramite parametro da gameLoop fino al gridController

Singleton? :)

Allora, abbiamo bisogno urgentissimo del seguente refactoring: il costruttore di Sound diventa privato e i suoni si creano dalla classe Audio che deve essere propagata fino a DroppableFactory (quindi niente Singleton ;)). Audio fa pooling di Sound e quando viene fatta richiesta di creazione di un Sound, controlla che sia gia' stato creato e ritorna una copia o ne crea uno nuovo se necesario.

Questo dovrebbe risolvere il problema che abbiamo adesso. Quando poi ci serviranno piu' di N suoni diversi contemporaneamente risolveremo anche quel problema (bello OpenAL, lo potessino).

Me ne posso occupare io stasera se volete o uno di voi oggi. E' urgentissimo perche' e' un crash che impedisce di giocare (classe A).

[Ufo13]

\o/ singletone \o/ su dropfactory

o su una factory di oggetti sound, che va creata in gameLoop e comune a i 2 playField.

oppure lo si passa tramite parametro da gameLoop fino al gridController

Hmmmmm sarà mica giunto il momento di implementare il SoundBank? :)

[cdimauro]

Singleton? :)

Allora, abbiamo bisogno urgentissimo del seguente refactoring: il costruttore di Sound diventa privato e i suoni si creano dalla classe Audio che deve essere propagata fino a DroppableFactory (quindi niente Singleton ;)). Audio fa pooling di Sound e quando viene fatta richiesta di creazione di un Sound, controlla che sia gia' stato creato e ritorna una copia o ne crea uno nuovo se necesario.

Questo dovrebbe risolvere il problema che abbiamo adesso. Quando poi ci serviranno piu' di N suoni diversi contemporaneamente risolveremo anche quel problema (bello OpenAL, lo potessino).

Me ne posso occupare io stasera se volete o uno di voi oggi. E' urgentissimo perche' e' un crash che impedisce di giocare (classe A).
Era più o meno quello che prevedevo di fare dopo aver fatto la stessa cosa con Engine / Texture. :p

Così mi risparmi un bel po' di lavoro. Thanx! :D :D :D

[fek]

Ho fissato il bug di OpenAL facendo pooling di Sound e creando Sound a partire da un oggetto Audio.

Questo pero' vuol dire dover propagare Audio giu' per tutta la gerarchia e non e' banale da risolvere con la struttura corrente. Servirebbe un buon refactoring per capire quali classi sono necessarie globalmente, metterle in un oggetto tipo Environment e propagare lui.

Ma non c'era tempo per questo refactoring, c'era da risolvere il bug per la First Playable, quindi ci voleva un orribile hack: Config e' propagato quasi ovunque, ho messo l'oggetto Audio li' dentro. Lo so, e' orribile, mi pento e mi ripento di questa scelta, ma il bug e fixato, ora c'e' solo da rifatorizzare il fix in una soluzione piu' mantenebile.

Ho aggiunto i test per il pooling di Sound, che implicitamente testano anche il bug.

Voi non siete autorizzati ad hackare brutalmente come ho fatto io, fate quello che vi dico non quello che faccio :D

[Jocchan]

Ho fissato il bug di OpenAL facendo pooling di Sound e creando Sound a partire da un oggetto Audio.

Questo pero' vuol dire dover propagare Audio giu' per tutta la gerarchia e non e' banale da risolvere con la struttura corrente. Servirebbe un buon refactoring per capire quali classi sono necessarie globalmente, metterle in un oggetto tipo Environment e propagare lui.

Ma non c'era tempo per questo refactoring, c'era da risolvere il bug per la First Playable, quindi ci voleva un orribile hack: Config e' propagato quasi ovunque, ho messo l'oggetto Audio li' dentro. Lo so, e' orribile, mi pento e mi ripento di questa scelta, ma il bug e fixato, ora c'e' solo da rifatorizzare il fix in una soluzione piu' mantenebile.

Ho aggiunto i test per il pooling di Sound, che implicitamente testano anche il bug.

Voi non siete autorizzati ad hackare brutalmente come ho fatto io, fate quello che vi dico non quello che faccio :D

Ottimo!
Voglio dire deprecabile... ma, in queste circostanze, davvero ottimo ;)
Posso segnalare il bug come FIXED?

[fek]

Ottimo!
Voglio dire deprecabile... ma, in queste circostanze, davvero ottimo ;)
Posso segnalare il bug come FIXED?

Prima testalo per assicurarti che sia fissato.

[cdimauro]

Ottima soluzione. Avrei voluto infilare anch'io Engine, Audio, Keyboard, ecc. dentro Config, perché propagare tutti questi oggetti era ed è un grosso problema per procedere con alcuni refactoring, ma mi sono astenuto perché tenevo alle mie dita. :D

Proporrei di creare adesso una classe Environment e "sostituirla" a Config nelle varie API: penso che ne gioverebbe tutto il codice, e lavorare dovrebbe risultare più semplice (ho già un "repository" dove andare a pescare i singleton che mi servono, all'occorrenza).

[fek]

Ottima soluzione. Avrei voluto infilare anch'io Engine, Audio, Keyboard, ecc. dentro Config, perché propagare tutti questi oggetti era ed è un grosso problema per procedere con alcuni refactoring, ma mi sono astenuto perché tenevo alle mie dita. :D

Proporrei di creare adesso una classe Environment e "sostituirla" a Config nelle varie API: penso che ne gioverebbe tutto il codice, e lavorare dovrebbe risultare più semplice (ho già un "repository" dove andare a pescare i singleton che mi servono, all'occorrenza).

L'idea e' proprio questa classe Environment o qualcosa di analogo. I singleton pero' sono contro la mia religione :D

Mi confermate che il bug e' fissato?

[Jocchan]

Ho testato a fondo, e il bug non mi si presenta più.