-
Posts
96 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Posts posted by Fire-Dragon-DoL
-
-
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
-
Beh, che io ricordi non era tanto complicato da implementare (poi io l'ho usato solamente all'interno dell'esame di strutture dati): erano due funzioni e una ventina di righe di codice non troppo complicato da capire, se capisci il ragionamento che c'è dietro (divide et impera).. serve un po' di pratica con la ricorsione principalmente.
Ad ogni modo, a livello di tempi di computazione è sicuramente il migliore (volendo c'è anche radixsort, ma secondo me è molto più incasinato, oltre al fatto che serve se vuoi ordinare una lista secondo più campi chiave).
Però ripeto, se non vuoi impazzire con l'implementazione, puoi partire tranquillamente con quello per selezione o inserzione.. 24 elementi non sono niente: gli effetti si sentono solamente all'interno di liste da almeno oltre 500 elementi ^^
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!
-
A questo punto, se proprio vuoi avere una computazione molto buona in ogni caso, ti consiglio di usare merge sort, visto che ha un tempo di n*logn in ogni caso ed è anche di facile implementazione.. poi non se la tua lista inizialmente è inversamente ordinata o totalmente casuale, ma in ogni caso dovrebbe essere la cosa migliore ;)
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?
-
Mi è venuto in mente un algoritmo, ma è un po incasinato, dipende se vuoi ordinarli per maggiore o minore, ma il funzionamento e sempre quello.
si fa un ciclo i che va da 0 a N(dimensione array) e un altro ciclo che va da V a N.
V all'inizio vale 0, si fa il ciclo dove si trova il piu grande tra v e n, e lo si mette nella cella v, poi v e i aumentano di 1.
penso che funzioni...
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...)
-
Uhm, ma se è solo di 24 elementi non ti conviene semplicemente usare l'ordinamento normale (non mi viene il nome ora)?
Tutti gli altri magari hanno tempi migliori, ma le differenze si notano solamente se hai liste da numeri mooolto alti.
Avevo fatto qualche mese fa delle analisi sui tempi di computazione su vari tipi di lista con qualsiasi algoritmo di ordinamento, e tutti quelli con meno di 100 elementi non impiegavano più di 0 secondi ;)
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
-
Visto che il grosso dell'array viene ordinato all'inizio e resta abbastanza invariato come composizione, invece di fare mioarray.push(nuovo_elemento_in_coda) e rieseguire l'ordinamento, si potrebbe fare direttamente mioarray.insert(posizione, nuovo_elemento) dopo aver stabilito posizione tramite ricerca binaria/dicotomica che, vista la dimensione massima dell'array, dovrebbe richiedere nel peggiore dei casi 5 passaggi.
Per il sorting iniziale puoi benissimo usare la funzione incorporata nel ruby mioarray.sort! (che equivale a mioarray = mioarray.sort), specificando il criterio di ordinamento se diverso da quello tradizionale . . .
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
-
Sono un po di fretta ma provo a risponderti comunque.
Allora per capire quanto dura un secondo come credo avrai capito devi vedere il frame rate, quindi l'immagine per attraversare lo schermo ci mette, (640 / frame_rate) secondi, nel caso di 40 FPS ci mette 16 secondi con lo spostamento di un pixel ad ogni update.
Non occorre nessun wait, ti basti sapere che la funzione update è chiamata una volta a frame e quindi ti puoi regolare di conseguenza, non so fai un contatore che ti conta n frame e poi si riazzera quando ha raggiunto n e gli fai fare quello che vuoi (pratica molto usata, mi sembra anche gli eventi fanno così), ti prendi il resto della divisione del frame_count per vedere se sono passati tot frame o secondi (questa non so quanto sia affidabile xD), puoi sbizzarrirti come più ti piace, non è poi tanto difficile dopo che ci prendi la mano.
Per quanto riguarda il frame_rate, quello dovrebbe rimanere invariato a meno che non lo cambi, solo che come hai detto tu il tuo pc ne riproduce di meno a schermo (credo, dovrei approfondire con qualche esperimento).
Altra cosa, perchè usi tutte variabili globali? è solo un esempio vero? Altra cosa, in questo caso (come in molti casi in rpg maker) la creazione di altri thread è prettamente inutile, ti conviene mettere tutto in un metodo update che poi richiamerai ad ogni aggiornamento.(scusa la spiegazione da cani ma meglio di così non riesco a spiegarmi :P)
Ora vado che mi stanno trascinando via dal PC, buona pasqua e buona programmazione

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
-
Ottimo!
Ma la funzione .update, non fà più o meno la stessa cosa?
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/VXAutore: Fire-Dragon-DoLDescrizione: 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: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...) senzache 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 tempidi 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 tutorialParto 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 possausare 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 ATBcontinuerà anche dopo la battaglia... portando a non voglio sapere quali errori).Sintassivariabile=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 breveSe 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 vocisono 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 peruscire dal while...che era un metodo più certo e tranquilloEsistono 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 modovariabile["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 otteniamoun 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 funzionipiuttosto 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 fermatoQuesta 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 -
Non credo di avere capito questo pezzo...
Sì, self è come this.
Sulla riflessione delle immagini non ci ho mai lavorato molto, non saprei se e quanto è rapida.
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
-
Questa pratica di usare degli handler è diffusa, anche se trovo anche io che non sia perfettamente in stile OOP.
Il punto qui secondo me è che il sistema di controllo dell'atb non dovrebbe essere parte del Combattente, bensì di una struttura esterna che lo controlla, che contiene i diversi oggetti Combattente, accede al campo atb, ma poi fa lei tutti i controlli.
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)

Scelta di algoritmo di ordinamento per array di 24 elementi
in Supporto RGSS (XP)
Posted · Edited by 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."