View Full Version : NormalGravity in GameConfig
Per sistemare il problema delle gemme che cadono troppo velocemente (nato dall'eliminazione di qualche costante qui e là nel codice) bisogna dividere per due il valore di normalGravity.
Peccato che il suo valore sia 1, e che GameConfig utilizzi valori interi.
Che si fa? Lo si converte in float? Se sì, rischiamo qualche imprecisione per l'approssimazione dei valori decimali (in passato ho avuto brutte sorprese al riguardo :grrr:)?
La cosa va sistemata, e la gravità è un punto piuttosto delicato (è stata fonte di un sacco di bug).
GravityMultiplier = 8
StrongestGravityMultiplier = 20
NormalGravity = 1
prova a giocare con il GravityMultiplier
Possiamo rinominarli in maniera piu` sensata? Direi che i nomi potrebbe deciderli Joc dopo che qualcuno gli ha spiegato che fanno :D
Più che altro, quando viene usato GravityMultiplier? StrongestGravity è abbastanza autoesplicativo invece :)
Cambiando GravityMultiplier non cambia niente.
In compenso, provate a raddoppiare (ovviamente senza commit) la gravità ed a farvi una partitella... lo spettacolo è assicurato :)
A dire il vero qui c'e' un mistero.
Il GravityMultiplier funziona cosi':
StrongerGravity= normalGravity * gravityMultiplier;
e il StrongestGravityMultiplier cosi'
StrongestGravity= normalGravity * strongestGravityMultiplier;
quindi attenzione, non si mappano uno a uno. Ora e' cosi' perche' la NormalGravity e' 1.
Aggiunto come bug, va risolto assolutamente.
Qualcuno mi aggiorna sull'esatto significato di questi valori di GameConfig?
NormalRepeatDelay = 200
FastRepeatDelay = 100
FrameRate = 20
UpdateRate = 10
Soprattutto UpdateRate mi interessa: cosa succede esattamente quando lo si cambia? Ci sono dei vincoli particolari per cambiarlo? Una sua modifica (ad es. da 10 a 15) impatterebbe solo sulla logica di Grid o su tutto quanto? Qual è la sua unità di misura?
Aggiunto come bug, va risolto assolutamente.
Qualcuno mi aggiorna sull'esatto significato di questi valori di GameConfig?
NormalRepeatDelay = 200
FastRepeatDelay = 100
FrameRate = 20
UpdateRate = 10
Soprattutto UpdateRate mi interessa: cosa succede esattamente quando lo si cambia? Ci sono dei vincoli particolari per cambiarlo? Una sua modifica (ad es. da 10 a 15) impatterebbe solo sulla logica di Grid o su tutto quanto? Qual è la sua unità di misura?
updateRate è ogni quanti ms viene eseguito questo ciclo dentro PlayField
updatePlayField(timestamp);
lastUpdateTimeStamp += updateRate;
score.setValue(getGridController().getGrid().getScoreCalculator().getScore());
updateWarningBox();
updateCrushBox();
updateCounterBox();
frameRate è ogni quanti ms viene eseguito questo loop nel loop che contiene i 2 playField. E ogni quanto viene aggiornato lo schermo.
if (timeStamp - lastRender >= environment.getConfig().getInteger("FrameRate"))
{
lastRender = timeStamp;
environment.getEngine().clearDisplay();
layerManager.drawLayers(environment.getEngine());
environment.getEngine().updateDisplay();
}
gli altri ci devo guardare meglio, sembra che gestiscano il delay necessario fra 1 tasto pigiato 2 volte e 1 tasto tenuto pigiato, ma nn capisco la differenza fra i 2
^TiGeRShArK^
14-03-2008, 15:57
e forse può essere pericoloso cambiarlo perchè molti test settavano dei valori fissati per quei valori anzichè prenderli dal config.. :muro:
Io quelli che ho visto li ho fixati, ma non ho idea se ancora se ne trovano altri a spasso per il codice con i valori scolpiti.. :boh:
e forse può essere pericoloso cambiarlo perchè molti test settavano dei valori fissati per quei valori anzichè prenderli dal config.. :muro:
Io quelli che ho visto li ho fixati, ma non ho idea se ancora se ne trovano altri a spasso per il codice con i valori scolpiti.. :boh:
ne ho tolti molti anche io, facendo dei getter in environmentTest
cmq se vanno cambiati joc, dillo a noi che vediamo se alcuni test vengono rotti, e vediamo di sistermarli(renderli indipendenti dal config)
Aggiunto come bug, va risolto assolutamente.
ehm...quello del calcolo della gravita' era un requisito del costumer :D :D
Come rischi più che ai test rotti (se ci sono valori hardcoded non ci vuole niente a cambiarli una volta individuati i test che falliscono :p ) mi riferivo a eventuali conseguenze più insidiose e meno visibili: perdita di sincronia con il resto del codice dopo qualche loop o persino la possibilità che qualche evento/pressione venga ignorato (ho dato una spulciata e mi sembra di no, ma preferirei esserne certo).
Mi riferivo più a questioni di logica del programma, insomma ;)
ehm...quello del calcolo della gravita' era un requisito del costumer :D :D
Che intendi?
E' segnato come bug perchè non si può settare la gravità ai valori desiderati, mentre prima era possibile ;)
Al momento il valore è troppo elevato come gravità "di base", quindi va sistemato per forza in qualche modo.
I refactoring che hanno portato a questo problema erano molto massicci?
Se c'erano delle costanti sparse qui e là per il codice (come mi è sembrato di capire), cosa cambierebbe se le rimettessimo e magari le rendessimo settabili in GameConfig? Chi se n'era occupato in origine?
Come rischi più che ai test rotti (se ci sono valori hardcoded non ci vuole niente a cambiarli una volta individuati i test che falliscono :p ) mi riferivo a eventuali conseguenze più insidiose e meno visibili: perdita di sincronia con il resto del codice dopo qualche loop o persino la possibilità che qualche evento/pressione venga ignorato (ho dato una spulciata e mi sembra di no, ma preferirei esserne certo).
Mi riferivo più a questioni di logica del programma, insomma ;)
Che intendi?
E' segnato come bug perchè non si può settare la gravità ai valori desiderati, mentre prima era possibile ;)
Al momento il valore è troppo elevato come gravità "di base", quindi va sistemato per forza in qualche modo.
I refactoring che hanno portato a questo problema erano molto massicci?
Se c'erano delle costanti sparse qui e là per il codice (come mi è sembrato di capire), cosa cambierebbe se le rimettessimo e magari le rendessimo settabili in GameConfig? Chi se n'era occupato in origine?
nn ho ben capito perchè servissero 3 valori per la gravità.
Ne possono bastare 2?
Se si, si elimina un valore e si tiene gravityNormal e gravityStrenght e basta, l'altro si toglie si vede dove ci sono dei problemi, si risolvono e poi siamo puliti.
public void setStrongestGravity()
{
actualGravity = normalGravity * strongestGravityMultiplier;
}
public void setStrongerGravity()
{
actualGravity = normalGravity * gravityMultiplier;
}
public void setNormalGravity()
{
actualGravity = normalGravity;
}
normaleGravity è la gravità normale per una gemsPair intera
strongerGravity e la gravità di una gemsPair quando si preme il tasto giu
strongestGravity e la gravita delle gemme che nn sono gemsPair che cadono verso il basso
il diviso 2 perso come costante si può recuperare mettendo l'updateRate a 20!!!!!!(aka raddoppiandolo). Il gioco nn dovrebbe risentirne per i test, faccio qualche prova
edit:
i test nn si lamentano. cio nn vuol dire che un test che prima aveva senso, ora nn ce l'abbia più...però per me si può rischiare
ho trovato un problema per questa soluzione.
Ho provato a mettere updateRate a 100, e viene coinvolto anche il pulsare della pivot, che accelera compulsivamente.
Stranamente non viene coinvolto il riflesso. Penso che il problema sia nella Grid.updateDroppableAnimations, che viene chiamata nel ciclo controllato dall'updateRate.
Eh da vedere come (e se) risolvere la cosa
edit: penso di essermi sbagliato, il problema sembra nn essersi(forse avevo smanettato qualcos'altro nella config)
^TiGeRShArK^
15-03-2008, 00:33
ho trovato un problema per questa soluzione.
Ho provato a mettere updateRate a 100, e viene coinvolto anche il pulsare della pivot, che accelera compulsivamente.
Stranamente non viene coinvolto il riflesso. Penso che il problema sia nella Grid.updateDroppableAnimations, che viene chiamata nel ciclo controllato dall'updateRate.
Eh da vedere come (e se) risolvere la cosa
edit: penso di essermi sbagliato, il problema sembra nn essersi(forse avevo smanettato qualcos'altro nella config)
:mbe:
l'importante è che non hai committato mentre commitavo io :O
..altrimenti sai dove andava a finire la torre degli asinelli...vero? !?!?!? :asd:
:mbe:
l'importante è che non hai committato mentre commitavo io :O
..altrimenti sai dove andava a finire la torre degli asinelli...vero? !?!?!? :asd:
nn ho ancora committato nulla
strongestGravity e la gravita delle gemme che nn sono gemsPair che cadono verso il basso
Sì, viene usata sia per le gemme "orfane" della pair che per le stone.
il diviso 2 perso come costante si può recuperare mettendo l'updateRate a 20!!!!!!(aka raddoppiandolo). Il gioco nn dovrebbe risentirne per i test, faccio qualche prova
edit:
i test nn si lamentano. cio nn vuol dire che un test che prima aveva senso, ora nn ce l'abbia più...però per me si può rischiare
Ieri qualche prova l'avevo fatta anche io... sembrava andare tutto bene, ma preferivo esserne sicuro. Ecco perchè ho chiesto :p
Anche perchè alla fine non avrei proprio messo 20, ma un 15 (ed ho chiesto quale unità di misura stessimo usando ed eventualmente quali sincronie perderemmo perchè non è un sottomultiplo di 100, quindi se tutto il resto funziona in centesimi di secondo forse qualche problema può sorgere dopo un pò).
:mbe:
l'importante è che non hai committato mentre commitavo io :O
..altrimenti sai dove andava a finire la torre degli asinelli...vero? !?!?!? :asd:
Lo sai che me l'ero scordato che pure Thebol sta qui a Bologna?
Qualche volta una birretta (http://xkcd.com/323/) mi sa che è obbligatoria (già ne avevo parlato con Bonfo) :)
Ieri qualche prova l'avevo fatta anche io... sembrava andare tutto bene, ma preferivo esserne sicuro. Ecco perchè ho chiesto :p
Anche perchè alla fine non avrei proprio messo 20, ma un 15 (ed ho chiesto quale unità di misura stessimo usando ed eventualmente quali sincronie perderemmo perchè non è un sottomultiplo di 100, quindi se tutto il resto funziona in centesimi di secondo forse qualche problema può sorgere dopo un pò).
fra frameRate e updateRate, a occhio penso di no. Per me si può provare.
Certo se metti l'updateRate ogni ms, e il frameRate ogni 100ms, il gioco scatterà, vistosamente, però è fisiologico. Sincronia di gioco nn si dovrebbe perdere, al max da vedere può fare schifo.
Cmq nn sono centesimi ma millesimi di secondo.
Lo sai che me l'ero scordato che pure Thebol sta qui a Bologna?
Qualche volta una birretta (http://xkcd.com/323/) mi sa che è obbligatoria (già ne avevo parlato con Bonfo) :)
:ubriachi:
ps.xkcd > all
fra frameRate e updateRate, a occhio penso di no. Per me si può provare.
Certo se metti l'updateRate ogni ms, e il frameRate ogni 100ms, il gioco scatterà, vistosamente, però è fisiologico. Sincronia di gioco nn si dovrebbe perdere, al max da vedere può fare schifo.
Bene, allora setto a 15 e committo.
Cmq nn sono centesimi ma millesimi di secondo.
Sì, errore mio. Ovviamente non andiamo a 5 fps :asd:
xkcd > all
Decisamente. (http://xkcd.com/386/)
Quando palavo della scelta del costumer intendevo il sistema di calcolo della gravità ;)
Per me non è furbissimo avere una moltiplicazione, ma 3 valori diversi e basta.
Io sono quello che ha rimosso il "/2", rimetterlo non è un problema, ma no è la cosa più intelligente da fare.
Ripeto la mia proposta: che ne dite di aggiungere il supporto ai float nel config? Così invece di 1 ci mettimao 0.5 e siamo tutti felici.
Per ciò che riguarda il config, se cambiano i valori non funziona più il gioco vuol dire che il codice del gioco è sbagliato. :D
P.S.: birra quando volete (appena torno ;) )
Quando palavo della scelta del costumer intendevo il sistema di calcolo della gravità ;)
Per me non è furbissimo avere una moltiplicazione, ma 3 valori diversi e basta.
Per me va più che bene.
Io sono quello che ha rimosso il "/2", rimetterlo non è un problema, ma no è la cosa più intelligente da fare.
Ripeto la mia proposta: che ne dite di aggiungere il supporto ai float nel config? Così invece di 1 ci mettimao 0.5 e siamo tutti felici.
I float li eviterei come la peste, in verità. Tutta la logica della gravità ragiona in int al momento, quindi a meno che non diventi obbligatorio lascerei le cose come stanno.
Per ciò che riguarda il config, se cambiano i valori non funziona più il gioco vuol dire che il codice del gioco è sbagliato. :D
Beh, non è sempre così. Se io domani impazzisco e setto il valore di FrameRate a 2000 (un frame ogni 2 secondi) sono io ad aver scelto un valore che non va bene. Allo stesso modo, se settare UpdateRate a un valore troppo alto significasse necessariamente perdere qualche evento troppo rapido (vedi la pressione dei tasti, la cui durata non dipende da noi), sarebbe sempre colpa di chi ha settato un valore errato.
P.S.: birra quando volete (appena torno ;) )
:cincin:
Allo stesso modo, se settare UpdateRate a un valore troppo alto significasse necessariamente perdere qualche evento troppo rapido (vedi la pressione dei tasti, la cui durata non dipende da noi), sarebbe sempre colpa di chi ha settato un valore errato.
Non si dovrebbe perdere l'input. L'inconveniente sarebbe che puoi spostare la droppable di più posizioni senza che questa scenda realmente(updateRate alto).
Oppure nn vederli immediatamente a video con un frameRate alto.
Non si dovrebbe perdere l'input. L'inconveniente sarebbe che puoi spostare la droppable di più posizioni senza che questa scenda realmente(updateRate alto).
Oppure nn vederli immediatamente a video con un frameRate alto.
Bene, ti ringrazio :)
I float li eviterei come la peste, in verità. Tutta la logica della gravità ragiona in int al momento, quindi a meno che non diventi obbligatorio lascerei le cose come stanno.
Non proprio, se vai a vedere nel codice sono tutti float ;)
(Anche perche' se no il normalgravity a 1/2 non avrebbe funzionato ;) )
Beh, non è sempre così. Se io domani impazzisco e setto il valore di FrameRate a 2000 (un frame ogni 2 secondi) sono io ad aver scelto un valore che non va bene. Allo stesso modo, se settare UpdateRate a un valore troppo alto significasse necessariamente perdere qualche evento troppo rapido (vedi la pressione dei tasti, la cui durata non dipende da noi), sarebbe sempre colpa di chi ha settato un valore errato.
Certo, ma no e' che il codice non fa piu' quello che deve fare o cambia il suo comportamento, continua a comportarsi come prima solo con valori diversi.
Il fattoche il gioco risulta ingiocabiule e' colpa del configuratore che ha scritto il config e non del codice del gioco ;)
Non proprio, se vai a vedere nel codice sono tutti float ;)
(Anche perche' se no il normalgravity a 1/2 non avrebbe funzionato ;) )
Avevo scritto quello dopo aver guardato nel codice in verità, e all'interno di Grid actualGravity, normalGravity, gravityMultiplier e strongestGravityMultiplier mi risultano tutti int :stordita:
Certo, ma no e' che il codice non fa piu' quello che deve fare o cambia il suo comportamento, continua a comportarsi come prima solo con valori diversi.
Il fattoche il gioco risulta ingiocabiule e' colpa del configuratore che ha scritto il config e non del codice del gioco ;)
Il che è esattamente quello che intendevo :D
Il comportamento in sè rimarrebbe teoricamente corretto, ma a causa di valori insensati il gioco sarebbe ingiocabile.
Avevo scritto quello dopo aver guardato nel codice in verità, e all'interno di Grid actualGravity, normalGravity, gravityMultiplier e strongestGravityMultiplier mi risultano tutti int :stordita:
Il che è esattamente quello che intendevo :D
Il comportamento in sè rimarrebbe teoricamente corretto, ma a causa di valori insensati il gioco sarebbe ingiocabile.
ok, allora ci siamo capiti ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.