Fire-Dragon-DoL

Il sort interno di ruby è stato ottimizzato, ma generalmente viene scelto il quicksort a questo fine (tra l'altro è un array di puntatori ad oggetti), per quello volevo mettere su l'insertion sort...a parere di wikipedia è quello che funziona meglio su array piccoli...il tempo non lo sto perdendo perchè mentre posto sul forum continuo il progetto (ho scritto altre 7 pagine di organizzazione...sto a quota 11, ora devo organizzare la grafica e poi il database, che sono ancora deciso come creare) Comunque ero interessato a ottimizzarlo al massimo perchè purtroppo verrà chiamato veramente spesso (si, anche ogni frame ci potrebbe essere il rischio...mi serve per aggiornare le barrette degli atb che possono variare mentre aumentano) quindi l'ottimizzazione massima è quasi indispensabile ^^ tra l'altro sempre da wikipedia "l'insertion sort è efficiente se l'input è già abbastanza ordinato."

Ho scaricato il megapack!allora quello del vx è un pò povero...ma quello dell'xp è veramente eccezionale, userò tutto per fare le basi del mio bs...poi ovviamente voglio sostituire con grafica mia, ma dovrei trovarmi un grafico prima :P

Salve scusate se scrivo qui...volevo solo fare una precisazione: quel che effettivamente secondo me è questo corso, è un corso di ruby (non di rgss).. mi spiego, l'rgss possiamo considerarla una branca del ruby applicata a rpg maker...ma qui attualmente vengono spiegate le basi, che sono propriamente del ruby...mentre l'rgss si dovrebbe apprendere solo una volta studiato il ruby (ovvero avere confidenza con il vero eproprio linguaggio) per poi passare all'rgss, che possiamo interpretare come l'insieme delle classi e librerie che compongono effettivamente rpg maker e i suoi script... quindi credo che un corso di rgss parta dal presupposto che la gente GIA sappia il ruby, non dover spiegare @questa e $questa cosa...ma bensì spiegare il funzionamento dei vari script di rpg maker, di come modificarli/sfruttarli e di come sfruttare le classi gia pronte dell'rpg maker (Sprite, RPG::Sprite, Bitmap...ecc) Non pensate che sia piu corretto?Io infatti ho studiato prima il ruby...ora sto "studiando" l'rgss (leggo la documentazione e analizzo gli script) ma a livello teorico se vengo a leggere questo tutorial di rgss non imparo niente (non perchè il corso sia fatto male, ma perchè il corso è di ruby che io ho gia studiato)...capite che intendo?

si solo che leggendo appare scritto "Il Quicksort, termine che tradotto letteralmente in italiano indica ordinamento rapido, è l'algoritmo di ordinamento che ha, in generale, prestazioni migliori tra quelli basati su confronto. È stato ideato da Charles Antony Richard Hoare nel 1961." quicksort: Struttura dati VariabileCaso pessimo temporalmente Θ(n^2)Caso ottimo temporalmente Θ(nlogn)Caso medio temporalmente Θ(nlogn) confrontiCaso pessimo spazialmente Dipende dalle implementazioniOttimale Spesso caso peggiore (array rivoltato al contrario, questo me lo ricordo io) è n^2 caso medio nlogn caso ottimale nlogn mergesort: Struttura dati ArrayCaso pessimo temporalmente Θ(nlogn)Caso ottimo temporalmente Θ(nlogn)Caso medio temporalmente Θ(nlogn)Caso pessimo spazialmente Θ(n)Ottimale In alcuni casi cambia il caso pessimo (l'array rivoltato al contrario) che è minore...ma è una cosa che non si verifica nella mia situazione suppongo si aun problema delle volte che si verifica il caso medio...comunque ho risolto leggendo questo: "Pur avendo complessità quadratica, per array piccoli è solitamente l'algoritmo di ordinamento più veloce. Un algoritmo simile all'Insertion Sort ma dalla complessità minore è lo Shell sort. Tuttavia, anche lo shell sort non è in grado di competere con la combinazione dell'insertion sort con un algoritmo di tipo divide et impera, quale il quick sort o il merge sort." insertion sort quindi, che è decisamente corto da creare :P

infatti...ma l'implementazione l'ho fatta (in C però) ed è piu lungo di 20 righe (il bubble saranno 15-16...non è sicuramente 20 righe l'implementazione del merge) la teoria grazie al cielo la so comunque guardati il quick sort... è il piu efficace in assoluto con una complessità media di logn (il merge non ha complessità media di logn, il quick è l'unico ad averla) Tra l'altro mi sorge il dubbio che tu abbia citato le capacità del quick sort e non del merge sort... è quello che ha complessità media di logn, è quello che se l'array è totalmente rigirato ha il suo caso peggiore (se è ordinato al contrario intendo)...sei sicuro di non esserti confuso? Li ho trovati su wikipedia, per questo te lo sto dicendo...il problema è che avevo letto da qualche parte che per array brevi i piu efficaci erano insertion/selection mi sa (o lo shell sort)

Vi spiego...avendo molti parametri personalizzati, non posso permettermi di usare il database di base di rpg maker...quindi devo per forza crearne uno mio. visto che sarà qualcosa di sola lettura (non scrivibile...tutte cose "costanti") e dovrà essere letto tante volte, la mia idea era di creare una classe "db" e riempirla per l'appunto di costanti... il problema è che mi farebbe molto comodo usare degli array (sempre in sola lettura) per tali valori tipo SPELL["id"]["name"] o cose cosi ci saranno...anche quindi a molteplici dimensioni (due o piu)...A questo punto mi è sorto il dubbio che non fosse l'approccio migliore. Avete altri suggerimenti?Un xml?Un db mysql vero e proprio?(sempre sola lettura ricordate)...lettura da file?Boh!

Ah era il merge...perfetto si è quello giusto... il migliore su tanti elementi è il quick, ma la mia lista è quasi sempre ordinata e di pochi elementi...ritengo che il merge (quello che odio di piu) sia la migliore opzione allora...aspe il merge di facile implementazione?mi sa che ti stai confondendo con gli altri... select, insert e bubble sono molto piu corti del merge eh xD Grazie a tutti dei suggerimenti sono apposto qui :P

EDIT: Mi rispondo da solo cosi che la gente possa imparare dai miei errori: si la GUI va separata dai calcoli interni... quello su cui sono perplesso (e comunque ritengo di no) è se i personaggi del bs sono parte della gui oppure distaccati da essa (e quindi il mio approccio di combattente->graphic era una buona idea)

Allora...mi è sorto un tremendo dubbio mentre organizzavo il lavoro (al solito su carta e penna): Sto costruendo vari pezzi del mio bs (battaglia->combattenti->buff,statistiche etc).. la grafica, per esempio della barretta degli hp, l'ho "appiccicata" alla statistica "hp", uguale per la limit e tutto il resto...(pure gli status alterati hanno un oggetto "graphic" che contiene informazioni e metodi riguardo l'icona) Purtroppo riflettendo su queste cose, mi è sorto il dubbio che non avrei dovuto far cosi ma bensi il contrario, la battaglia doveva contenere un oggetto chiamato GUI che avrebbe gestito tutto (quando vengono fatti danni, viene aggiornata la barretta degli hp del mostro e cosi via)... il vantaggio sta che l'organizzazione è migliore, lo svantaggio è per esempio che devo updatare tutta l'interfaccia ogni volta che viene effettuata un'azione (quindi non aggiorno la singola barra ma tutto quanto) Quale approccio dei due è quindi il migliore?

ma di algoritmi ne esistono tanti, ovviamente mi affido a quelli gia esistenti perchè sono quelli studiati maggiormente... inutile creare algoritmi propri ammenoche non siamo studiosi di algoritmi esperti (almeno per l'ordinamento di array) quello che dici te somiglia molto al selection sort...comunque ti ringrazio del suggerimento, anche se penso che userò il metodo "sort" visto che effettivamente il mio array è molto compresso (24 elementi...)

AH! Perfetto questo è interessante, perchè ero indeciso se sacrificare un pò di velocità in cambio di sicurezza (un sort a ogni fine turno) oppure fare come ha suggerito giver... ma in questa situazione preferisco un pò piu di sicurezza allora

Grazie mille del suggerimento, stavo pensando pure che una "coda" non sarebbe male (visto che il primo elemento va alla fine, sarebbe logica)...però l'accesso è lento e temo che a me serva accedervi spesso (per ilt argeting, questo array contiene la lista dei pg)

figo...di che tecnologie ti avvali?AJAX?i frame teoricamente non sono piu standard w3c... ti converrebbe usare qualcosa tipo un div con le proprietà css giuste (c'era qualcosa tipo "se superi i limiti fai comparire le scrollbar" ma nn ricordo la proprietà ora... il php mi è sempre piaciuto come linguagigo...peccato che fa i refresh di pagina, per quello chiedevo ajax...

Allora, essendo universitario ho imparato varie cose riguardo gli algoritmi di ordinamento... ora so benissimo che il quick sort teoricamente è il migliore, ma non è il caso in cui io debba usarlo... infatti avendo un array di soli 24 elementi, è logico che quel tipo di algoritmo sia troppo pesante per cosi pochi dati. Detto questo, vorrei quindi scegliere un algoritmo migliore per ordinare il tutto... Attualmente sono indeciso fra shell sort, insertion sort, merge sort (questo mi sta particolarmente antipatico)... anche il selection sort non dovrebbe andar male, comunque vi dico le prerogative per la scelta dell'algoritmo: -L'array è di soli 24 elementi, massimo (potrebbe essere di meno...mai minore di 2, per forza :P ) -L'array sarà quasi sempre ordinato, tranne la prima volta(e pazienza perchè è a inizio battaglia) il resto delle volte giusto l'ultimo elemento (il 24esimo) dovrebbe essere in disordine (probabilmente dovrà tornare alla posizione 1) Detto questo, ricordo che c'era un algoritmo che aveva il suo caso peggiore quando l'array era totalmente ordinato al contrario (questo potrebbe essere un buon algoritmo quindi?), poi invece ce ne era uno il cui caso peggiore era quando è già ordinato, considerato che io avrò una variazione di massimo 1 elemento nell'ordinamento (circa ovviamente), è probabile che questo non vada bene (l'array sarà sempre ordinato al 90%)... se avete suggerimenti quindi, sono ben accetti

We grazie della risposta...anche io sto andando di fretta purtroppo xD comunque si le globali sono esempi (è il modo piu veloce per fare un test senza fare qualcosa di complesso) Per la prima risposta si credo di aver capito (quindi supponendo frame_rate==40, 4 frame dovrebbe corrispondere a un decimo di secondo... ogni 4 frame posso far fare uno spostamento per dire, o ogni 40 se voglio che ci metta 640 secondi)... quello che mi lasciava perplesso in quella cosa che ho fatto io è: for i in 0..640 $sp.x+=1end Se faccio una cosa cosi, non viene effettuato nessun update...e soprattutto, io aumento una variabile numerica e stop (ammenoche in realtà quella nn è un metodo...ma questo non lo sapevo), di conseguenza, è come se aumentassi una variabile i di 1, e io dubito che venga effettuato un ciclo ogni frame (sarebbe assurdo no?cioè sarebbe lentissimo il linguaggio)...per questo ho fatto quella domanda: in quel thread a parte sei sicuro che avvenga una volta ogni update? io ho paura che si l'update avvenga, ma una volta ogni volta che il pc ci riesce (quindi basandosi sulla sua reale velocità di cpu... xD)...ovviamente molti update risulteranno impercettibili a occhio umano scappo che mia sorella mi corca!

Ok... noto che ultimamente i topic relativi al tempo sono molti, effettivamente il tempo è mal gestito in rgss (o meglio, è poco chiaro per chi programma)... quando avrò un pò piu di esperienza mi propongo di fare una libreria... comunque volevo chiedere...se io faccio una cosa di questo tipo: $sp=Sprite.new$sp.bitmap=RPG::Cache.battler("Ziegfred_btl",0)$sp.x=0$sp.y=0$thr=Thread.new { while ($sp<=640) $sp.x+=1 $sp.update end} Quanto ci impiega in secondi (e perchè) l'immagine ad attraversare lo schermo? Dipende dal nostro pc o sbaglio? Occorre mettere un wait (con la funzione che ho creato) per scandire il tempo sotto questo aspetto? Grazie dei suggerimenti... Ah una cosa, il fatto che gli FPS oscillino tra 38 e 40 (sul mio pc) non indica che i frame_rate siano meno di 40, cioè in realtà sempre 40 sono no?E' solo il pc che ne riproduce di meno a schermo... o sbaglio?Perchè in tal caso ho fatto una paperata con la funzione wait xD

Devi perdonarmi ma temo di non capire la tua domanda... la funzione .update aggiorna i frame... il thread lancia una parte di codice come "a se stante" e viene eseguita in parallelo ad un'altra (magari quella principale) se intendi mettere qualcosa dentro .update, allora non è lo stesso... se metti il "wait" dentro l'update logicamente "metti in pausa" l'intero processo principale... di conseguenza non vedrai (graficamente) muoversi qualcosa o roba del genere... ma i thread possono essere usati anche a altri scopi: immagina di avere tre thread... con uno aumenti ogni 10 secondi una variabile, con un altro sposti avanti un evento ogni 3 secondi, con un altro ancora carichi una barretta tipo quella dell'atb che però può riguardare qualcos'altro... (oppure puoi mettere tutto in un unico thread che si stacchi dal principale...queste son scelte) è molto ampia l'utilità dei thread...devo dire che è anche difficile spiegarla, fondamentalmente gia due thread (ribadisco il processo principale è gia considerato un thread) e uno secondario dovrebbero bastare (effettivamente esegui il programma su due piani paralleli...dovresti riuscire a fare gia tutto) ovviamente come ho detto i thread sono molto piu veloci dei processi paralleli e pesano molto meno all'rpg maker

Threading basilare, o anche Processi Paralleli in RGSS (applicati a rpgmaker) 1.0 1. Introduzione Per: RPG Maker XP/VX Autore: Fire-Dragon-DoL Descrizione: Questo tutorial tratta della progettazione di "processi paralleli" (pezzi di programma eseguiti in "contemporanea" ad altri) che consentono ad esempio aggiornamento di barre degli hp e atb in tempo reale, mentre potete continuare a muovere il vostro personaggio ed eseguire altre azioni (come gli eventi settati come "processi paralleli"). Ultima modifica: 10/04/2009 21:38. 2. Tutorial Avete presente quando mettete un processo parallelo per far ripetere un'azione all'infinito (per esempio l'aggiornamento della grafica di una barretta degli hp su mappa)? Vi è mai passato per la testa di voler fare la stessa cosa ma con l'RGSS? (in realtà i thread sono incorporati nel ruby...per comodità nel tutorial dirò RGSS) Questo è possibile... e offre tantissime possibilità, poichè differentemente dai processi paralleli sono molto leggeri (fin quando non li riempite voi di cose pesantissime) e soprattutto vi offrono la possibilità di non mettere quel maledetto eventino su ogni mappa per far comparire quella maledetta barra degli hp in alto a sinistra... Insomma hanno molteplici utilità...i thread servono quindi a far si che possiate fare delle azioni in parallelo. Come ho già detto, i thread sono una specifica del ruby e non dell'RGSS, quindi li trovate documentati qui: http://www.ruby-doc.org/core/classes/Thread.html In questo link troverete anche cose che esulano da questo tutorial (almeno per il momento) poichè non ritenute necessarie (le ritengo basilari) Oltre a ciò, vi servirà una funzione (metodo) che ho creato io (ieri notte) per creare dei tempi di attesa all'interno dei thread (vi torneranno comodi per scriptare un ATB...) senza che il vostro gioco si "fermi tutto" (se usate sleep, non potrete muovere il personaggio...ma allora è come se non poteste creare operazioni parallele "temporizzate"). In aggiunta a questo il vantaggio della mia funzione è che è in decimi di secondo (lo sleep è in secondi), quindi potete far aspettare un decimo di secondo (decisamente più utile che tempi di attesa in secondi!). Materiale: 1) Funzione "wait" module Utils #potete metterla dove volete...io la preferisco qui, in questo modulo personalizzato module_function def wait(decseconds) #I tempi di attesa sono in decimi di secondo, quindi 10=1 secondo #Ottengo il numero di frame correnti trascorsi dall'avvio del gioco #questo valore lo calcolo qui per essere piu preciso possibile nell'attesa framescurrent=Graphics.frame_count #Ottengo i frame al secondo (FPS) e li gestisco come float per maggior precisione framepersec=Graphics.frame_rate.to_f #Calcolo quanti frame devo aspettare per arrivare a un tempo di attesa pari a decseconds #Come potete notare, framepersec/10.0 corrisponde ai Frame Per Decimi di secondo (FPDS? xD) framestowait=decseconds.to_f*(framepersec/10.0) #A questo punto, parto dal frame a cui siamo e cerco di ottenere quanti frame vanno aspettati #Faccio arrotondare i float a interi (perchè non esistono "mezzi frame" in rpg maker... #in altri giochi come WoW li ho visti ma non vorrei dir cavolate frametoreach=framescurrent+framestowait.round #Dopodichè aspetto fino a che il frame_count non equivale il frametoreach (visto che il frame_count) si autoincrementa con l'attesa #Ovviamente l'unico modo è creare un mini ciclo infinito all'interno della funzione while (Graphics.frame_count<frametoreach) #Aspetta e spera... xD end #Ricordo a tutti che un codice "attende" la fine di una chiamata di funzione per continuare... è su questo che si basa #questa funzione endend (per utilizzarla è sufficiente scrivere Utils::wait(numero_intero)) Note: 1) Piccola legenda sui livelli per i tutorial Parto dal presupposto che l'utente sappia programmare in qualche linguaggio (anche per gli eventi perchè è meglio per tutti)* = Conoscenza basilare degli eventi** = Conoscenza avanzata degli eventi*** = Conoscenza del Ruby**** = Conoscenza basilare dell'RGSS (fondamentalmente della documentazione)***** = Conoscenza avanzata dell'RGSS (praticamente conoscere perfettamente gli script di RPGMaker e come smucinarci al meglio) Livello tutorial: **** Partiamo dalla base...come ho detto il Thread è un vero e proprio processo, un pò come far partire un altro programma a fianco del vostro (a livello pratico non è così, ma rende l'idea) che possa usare tutte le variabili/funzioni/classi/etc del vostro programma principale, modificandole a suo piacimento. Dunque, la sintassi per creare un Thread è veramente semplice, la cosa fondamentale però è memorizzare un riferimento a tale Thread in una variabile (in questo script useremo le globali) perchè se create un Thread infinito (per esempio per caricare l'ATB) vorrete poterlo mettere in pausa e soprattutto spegnerlo (eliminarlo) del tutto quando finisce (altrimenti il vostro ATB continuerà anche dopo la battaglia... portando a non voglio sapere quali errori). Sintassi variabile=Thread.new { } Tra le parentesi graffe metteteci il codice che volete... per creare un ciclo infinito (quindi un thread che viene eseguito all'infinito, ricordo che tutti i programmi sono cicli "infiniti" o quasi infinit (terminano quando li chiudete) variabile=Thread.new { while (true) end} Tutto quello che sta nel while viene ripetuto in eterno, ammenochè non "killate" (spegnete definitivamente) il thread (o processo), come riuscirci verrà spiegato a breve Se vi sta scomodo spegnere il thread esternamente, potete sempre mettere uno switch e usare quello nella condizione del while... quando il thread arriva alla fine, si spegne da solo (e forse questo è un approccio molto piu corretto di "killare" il vostro processo...anche più pulito, anche perchè sto leggendo in giro che Thread.kill potrebbe essere buggata...ma le voci sono di un anno fa...non so come si è evoluta la cosa nel frattempo). Un'alternativa per creare un Thread è la seguente: variabile=Thread.new([args]*) { |args|....} In questa situazione tutto ciò che è passato attraverso new (un array) sarà accessibile nel blocco del Thread come (in questo caso) args (la variabile tra | e |)... può farvi comodo per "parametrizzare" i thread (come sfruttare ciò è a vostra discrezione) A questo punto, come vi ho detto vogliamo poter "uccidere" (spegnere definitivamente e farlo crepare!) il nostro thread...la cosa è molto semplice ed eseguibile in due modi differenti: 1)Thread.kill(variabile) 2)variabile.kill Semplice, sensato, immediato, logico! (mi sento sadico quando uso questo metodo...) Può essere comodo comunque per spegnere il vostro ATB all'istante, se la battaglia finisce... ovviamente se state facendo scritture di file e roba simile in un thread e lo spegnete, non voglio sapere quello che succede...quindi assicuratevi di spegnere thread "sicuri", oppure usate uno switch per uscire dal while...che era un metodo più certo e tranquillo Esistono altre piccole cose interessanti riguardo i thread... ad esempio, supponendo che variabile=Thread.new.... potete settare dei valori che potrete usare all'esterno nel seguente modo variabile["nome"]=qualcosa Se volete settare questi valori dall'interno del thread è semplice: variabile=Thread.new { #Questa riga Thread.current, è come se scrivessimo "variabile"... in poche parole si riferisce al nostro thread Thread.current["nome"]=qualcosa} Come sfruttarlo sta sempre a voi deciderlo... un semplice esempio potrebbe essere dare un nome univoco a ogni thread ["nome"] per l'appunto, poi usando questa comodissima funzione Thread.list otteniamo un array contenente tutti i thread in esecuzione... che potrete riconoscere tramite il vostro valore impostato "nome" Abbiamo infine gli ultimi due metodi utilissimi (ne esistono molti altri ma questa è una introduzione e soprattutto ritengo di aver spiegato le cose basilari e utili per i thread... esistono molte funzioni piuttosto avanzate) Il primo è Thread.stop, va usato all'interno del blocco del thread e lo mette in attesa, facendo eseguire altri threads. variabile=Thread.new { print "ciao" Thread.stop} e l'altro è variabile.wakeup... l'opposto di stop, ovvero riattiva il thread facendolo partire dal punto in cui si era fermato Questa era un'introduzione basilare ai thread... spero possiate sfruttarla in qualche modo, si accettano suggerimenti su come migliorare il tutorial (è il primo che scrivo, quindi criticate anche pesantemente :P )... grazie a tutti

Niente la prima cosa non mi ha saputo "rispondere" nessuno (neanche mio zio che lavora come programmatore a progetti grossi) ...non perchè fosse difficile, perchè dipende da come nel mio cervello organizzo la cosa...di conseguenza se avete qualche suggerimento su come prepararmi a organizzare (attualmente io scrivo tutto su foglio, ma sono al decimo foglio che riscrivo perchè esce sempre un gran casino...)...specialmente, devo cominciare a creare dalla classe piu "esterna" o dalla piu "interna"?(parto dalla classe Personaggio o dalla classe Statistica per dire?)...poi, conoscete qualche buon programma per disegnare diagrammi (magari gratis) e può servire a qualcosa per progettare il tutto? (se conoscete programmi che usate, comodi per progettare ditemi pure...scrivere sul blocco note è semplice ma non è molto pulito e ordinato...scrivere su word non è contempabile, mi cambia le maiuscole a suo piacimento e la mia spaziatura gli sta sul cocomero) per la riflessione immagine ho scoperto che la classe Sprite ha la proprietà mirror=boolean (true/false)... non solo, non mi pare faccia mutamenti dell'immagine (a livello pratico si, ma boh)... mi pare sia molto leggera... tra l'altro comodissima...adesso posso far combattere i pg sia da destra che da sinistra disegnandoli una sola volta...finalmente posso fare gli incontri "presi alla sprovvista!" xD

Posto per informare gli altri della soluzione che ho trovato: avendo fatto il mio bs in una mappetta, l'update va fatto nello Spriteset_Map...io per comodità l'ho messo direttamente nel metodo "update" che aggiorna tutto, cosi non ho dovuto modificare altre parti di codice... va messo alla linea 145 circa (fuori dal for), basta metterci un qualcosa che aggiorna tutti gli sprite personalizzati...io personalmente memorizzo tutti gli sprite creati da me in $sp... quindi #magari qui mettete un controllo se $sp.length è 0...for i in 0..$sp.length $sp[i].updateend cosi vengono tutti felicemente aggiornati :P

Faccio risorgere questo topic per non aprirne uno nuovo: anche io ho un problema col "wait"...ma credo di aver trovato un approccio piu corretto: creo un nuovo Thread,dentro viene runnato uno script che "fa l'animazione del pg da fermo" (in poche parole cambia la sua immagine ogni X tempo)...l'unica cosa che mi viene in mente è mettere dei mini while e farlo aspettare tot frame all'interno del while per poi uscire e proseguire alla riga dopo, essendo il tutto in un thread a parte non dovrebbe bloccare eventi e roba simile... qualcuno ha suggerimenti su come affrontare il mio problema? EDIT: ho avuto qualche idea, una su come creare un "wait", però poi volendo visualizzare una animazione su un pg, mi si è posto il problema su come effettuare gli update ogni frame su tali sprites... volevo sapere se qualcuno sa dove è situato il "ciclo principale di aggiornamento della grafica" (che non mi sembra il "main")...insomma dove viene fatto l'update di picture, chars, etc .... Vi posto qui sotto la mia idea di metodo wait (e pare funzionare con una precisione di decimi di secondo) def wait(x) #Ricavo i frame al secondo (ricordiamoci che variano leggermente #tra (38 e 40) (almeno sul mio pc XD) framealsecondo=Graphics.frame_rate.to_f frametoadd=x.to_f*(framealsecondo/10) #1 decimo di secondo dovrebbe #essere framealsecondo/10 (per logica), quindi x per (framealsecondo/10) #dovrebbe risultare all'incirca come i decimi di secondo voluti #(framealsecondo/10 corrisonderanno a 1 decimo di secondo, basta fare la #moltiplicazione...) #adesso devo capire come fare ad aspettare quei decimi di secondo... #l'unica idea che ho in mente è fare un while che sfruttando il frame count #calcola quanti frame sono passati e continua a fare il while finche non #finiscono #qui vedrete che arrotondo per cercare di essere il piu preciso possibile #nell'attendere una quantità di frame piu vicina possibile al decimo #di secondo (che purtroppo i frame sono interi non vanno quindi pure nei #decimali) toreach=frametoadd.round+Graphics.frame_count while (Graphics.frame_count<toreach) #continua a fare il ciclo fino a che non raggiungiamo il frame desiderato end end Con poche righe (sono tipo 6 non considerando i commenti), questo dovrebbe essere un wait (funzionante per altro)... ovviamente va usato in un processo parallelo O in un altro thread (che a livello pratico sono la stessa identica cosa) A questo punto ho detto, perchè non mostrare un'animazione sopra lo sprite? Ok buona idea...metto l'animazione...ma quella nn progredisce...e mi ricordo che sti sprite "non vengono updatati" ! La soluzione che mi è venuta è fare un mini thread che viene lanciato e esegui gli update... $mt=Thread.new { while (true) for i in 0..23 $sp[i].update end nfc=Graphics.frame_count+1 while (Graphics.frame_count<nfc) end end} Come vedete a livello logico almeno, sembrerebbe che gli sprite vengano updatati ogni frame (frame_count+1...) in realtà non ho ancora capito perchè ma vengono updatati molto piu velocemente (l'animazione è molto piu veloce -.-) considerato questo fatto che ovviamente è molto fastidioso, volevo chiedervi dove posso trovare appunto il posto dove viene effettuato l'update della grafica, cosi ci infilo a mano un bel $sp.update dentro a un for e si aggiorna in automatico (ovviamente questi sono test, quando mi organizzerò meglio farò un bell'array che si aggiorna quando viene creata un'istanza della classe sprite... e quell'array verrà continuamente updatato) EDIT2: Mi sono reso conto che effettivamente non è in un singolo luogo che vengono effettuati gli update... avete suggerimenti per dove updatare questi miei sprites? (RPG::Sprite)

Stavo notando comunque che nella documentazione non c'è alcun animation_id, curioso... è stata fatta male sta documentazione (perchè quello che hai detto tu funziona ed è giusto xD)

Approposito ho capito cosa intendi per "atb controlla tutto"... il problema è che la cosa può essere vista in entrambi i modi...e comunque poi sorgono i problemi sopra citati per le altre classi :P

Ti ringrazio (vedo che qualcuno che di oop ne capisce ci sta :P ), si noto che pure per te questa è un pò brutta come soluzione (non sapevo neanche fosse molto praticata!)...ovviamente sto facendo prima tutto su carta e penna (io l'atb lo vedevo un pò come una statistica come potrebbe invece essere la limit del personaggio) quindi l'esempio dell'atb è uno...ma per esempio, con la limit (che a tutti gli effetti è una classe simile a quella dell'atb, di conseguenza è derivata e ti posto qui sotto il perchè :P ) mi si pone lo stesso problema... poi ho fatto un oggetto "action" che contiene le seguenti informazioni "action_next" "target_next" "action_last" "target_last"...e ci volevo mettere il metodo overridabile "select_action" overridabile in modo che se casco nella classe "Mostro" (derivata di combattente) ci metto l'AI, se invece finisco nella classe "Pg" ci metto il metodo che chiama la visualizzazione del menu etc etc...anche qui, se voglio riferirmi al pg non cambia assolutamente niente Il problema è che se ci rifletti non è illogico quello che sto facendo...immagina: Francesco(io).simuove("Avanti") Francesco.mano.stringelaspada Anche se forse avrebbe piu senso Francesco.stringelapenna (ma a questo punto avremmo problemi perchè francesco avrebbe cosi tanti metodi e proprietà da arrivare di fronte al problema che avevo io precedentemente) purtroppo nella realtà riesco a risalire dalla mia mano a me, in OOP no...possibile che non ci sia un modo? approposito, self equivale a this (in altri linguaggi) o ho capito male? EDIT: Dimenticavo, qui l'esempio di classe atb,limit e della classe da cui ereditano class BarStat#che nome del cavolo... non mi è venuta un'idea migliore xD attr_accessor :speed MAX=100 attr_reader :current attr_accessor :graphic def initialize(bvalue=0) @speed=1 @current=bvalue @graphic=GraphicBar.new#questa è inventata per ora, #come ho detto, è mia intenzione separare la grafica dal resto e questo mi sembra l'approccio migliore #come scritto nell'altro topic end def increase(howmuch=0) if (howmuch==0) @current+=@speed else @current+=howmuch end endendclass BarATB < BarStat attr_accessor :reversespeed def initialize(bvalue=0) super(bvalue) @reverse=false end def reverse=(val) #qualcosa per invertire il caricamento dell'atb, è solo grafico l'effetto end def reverse return @reverse endendclass BarLimit < BarStat def set(val) @current=val endend Come vedi ha un senso... Tra l'altro mentre scrivevo mi è venuto anche in mente che tra le stat del pg ci sarà "position" (che non è la posizione grafica, bensi la posizione fisica in battaglia... ovvero riga (i pg saranno disposti su 3 righe), la colonna (se è piu vicino allo schermo o meno) e poi il lato (ovvero se i pg sono a destra o a sinistra...quanto pesa fare un "reflect horizontal" di un immagine?perchè cosi non devo fare animazioni doppie :P) ovviamente position è un oggetto, verrà naturale fare position.row o position.column=3 e cosi via... come vedi, anche qui poi mi risulterebbe difficile riferirmi all'eroe

Mi spiego meglio con un esempio: class Statistiche attr_accessor :str attr_accessor :dex attr_accessor :int def initialize @str=0 @dex=0 @int=0 @atbmax=100 @atb=0 end def atb=(value) @atb=value if (@atb>=@atbmax) @atb=@atbmax iniziaturno(il_pg) #qua è dove sorge il problema: vorrei risalire a chi contiene l'istanza di "stats" end end def atb if (@atb>@atbmax) return @atbmax else return @atb end end def iniziaturno(chara) #eventuali cose da fare se inizia il turno endendclass Combattente attr_accessor :stats def initialize @stats=Statistiche.new endend Eroe=Combattente.newEroe.stats.str=12Eroe.stats.int=34Eroe.stats.dex=3Eroe.stats.atb=100 #L'atb è carico#come potete vedere non ho un modo per risalire al mio pg da dentro "atb=" La prima soluzione che mi è venuta in mente è qualcosa tipo un campo "handler" dentro a Statistiche per cui class Combattente attr_accessor :stats def initialize @stats=Statistiche.new(self) endendclass Statistiche attr_accessor :handler def initialize(il_pg) @handler=il_pg endend quindi cambiando le classi in questo modo dovrei poter accedere tramite Eroe.stats.handler a "Eroe" e da li quindi vedrei il tutto anche dentro ad "atb=", ora questo è sensato...ma mi sembra una vera e propria porcata. E' un errore di progettazione?Come approccio, dovrei tirar tutto fuori dalle stats immagino? si accettano suggerimenti (mi sto impegnando molto nell'imparare a progettare un programma (gioco) con l'OOP perchè vorrei poi sfruttare ciò che ho appreso anche in altri campi come università/lavoro)