mikb89
-
Posts
655 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Everything posted by mikb89
-
Purtroppo non era un errore di battitura D: Comunque ora sono cosciente si scriva così. Grazie per la correzzione ^^ (questa l'ho fatta apposta :P) In effetti 'lettore di beta' ha senso, anche se non avevo mai esteso il termine beta a delle bozze. Bon, ok, felice proseguimento =)
-
Io di script non ci capisco niente u.u Però quelle che dici tu sono le espressioni regolari (regular expression) e puoi trovare tutte le spiegazioni nella guida ^^ Il miglior modo per capirle è, credo, provarle fino a quando fai pratica. La funzione dovrebbe essere gsub!, quindi "stringa".gsub!(RegExp, "sostituto") se devi soltanto fare semplici sostituzioni oppure puoi usare un blocco: "stringa".gsub!(RegExp){ |risultato| risultato.upcase } Esempio stupido: a = "stringa" a.gsub!(/g/, "f") p a Mostra "strinfa" a = "stringa" a.gsub!(/g/){|r| r.upcase} p a Mostra "strinGa" Per tutte le varie possibilità delle espressioni regolari vedi come detto la guida (per il fatto che te la trovi sempre lì a portata) così come puoi anche cercare ".gsub" all'interno dello script editor per vedere come è stato usato. Poi c'era un sito che ti permetteva di testare rapidamente le regexp, se lo trovo lo metto. EDIT: trovato! http://rubular.com/ E comunque sì, il tuo esempio è molto poco concreto xD
-
Grandi per il tema trattato! Io purtroppo non sono né studente e né lavoratore e non entrambi i miei genitori lavorano, perciò non servo a niente D: Però volevo dirti che è una bella iniziativa ^^
-
Tutti i test li ho postati perché dal messaggio di clyde sembrava che io fossi un mostro per il fatto di avere usato eval ;) In realtà il problema non si poneva minimamente, data la situazione precisa, però abbiam voluto approfondire e tanto vale farlo per bene. Per quello segnalato da te in effetti mi ero fatto prendere un po' la mano xD e infatti l'ho tolto subito. Per quello che definisce il metodo vuoto, non cambia niente il modo di farlo. Volevo soltanto approfondire questa cosa di eval, perché essendo molto utile e gridandomi tutti a gran voce (xD) che NON va usata mai e poi mai, boh, mi sono incuriosito :3 Ok per il codice messo da te, ma il livello di complessità di Window_Base.class_eval("def update_tone; end") è di molto inferiore, oltre a non poter dare errori in nessun caso mi pare. Comunque, per la gioia di tutti, ho messo (class Window_Base; def update_tone; end; end) if condizione che è un misto fra quel che consigliava keroro e quel che volevo io ^^ Mi sono reso però conto che stiamo andando OT in maniera impressionante xD così se avete commenti sullo script o su altre parti di codice che non vi quadrano ok, però la questione dell'eval va bene così! Nel caso poi si parla in un topic a parte ^^ 255, quando vuoi puoi aggiornare il topic, ho finito di uppare sia il template che lo script ^^
-
Alla prossima versione lo userò sicuramente! lol EDIT: Metodi vari: class A; def a; end; end a = Time.now A.class_eval("for i in 0...1000000; def a; end; end") p Time.now - a a = Time.now class A for i in 0...1000000 define_method(:a){} end end p Time.now - a a = Time.now class A for i in 0...1000000 def a end end end p Time.now - a a = Time.now for i in 0...1000000 A.send(:define_method, :a){} end p Time.now - a a = Time.now A.class_eval("for i in 0...1000000; define_method(:a){}; end") p Time.now - a Mi dà (mediamente): 4.098234 6.253357 4.427254 6.524373 6.284359 Evidenziando che la scelta migliore consiste nel NON usare define_method, e che class_eval è addirittura più performante della definizione diretta, se escludiamo il costo della chiamata al metodo stesso. Da gli stessi valori anche a voi o è sballato il mio computer? Ovvio che diminuiranno/aumenteranno in base al computer, quello che bisogna notare è il gap fra i metodi. Mi sembra elegante anche questo qui: Window:Base.send(:define_method, :update_tone){} Però è quello che pesa di più. Quindi la scelta: convenzioni o performance? Io direi performance tutta la vita (: Se mi fornite motivazioni valide tuttavia potrei anche mettere la versione di keroro, non è che la mia è una presa di posizione! xD Solo prima di accettare voglio capire il perché, tutto qui ^^
-
Fatti test. A definire 100 metodi, eval impiega 0.006 secondi, define_method ne impiega 0.005. A definire 10.000 metodi, eval impiega 0.298 secondi, define_method ne impiega 0.098. Il metodo che vado a definire è uno solo però, se la differenza è quasi inesistente con 100 non vedo il problema. Non uso define_method perché, essendo protetto, non posso utilizzare la sintassi Classe.quellochedevofare, cosa che class_eval mi consente. Cioè, siate tecnici! È un modo anche per insegnarmi qualcosa xD
-
Beh, ma sono dispute, mica dicono che non bisogna usarlo e basta. Comunque che errore vuoi che dia in def qualcosa; end? xD Il secondo l'ho rimosso del tutto, il primo l'ho messo più visibile e contratto. (Window_Base.class_eval("def update_tone; end")) Al prossimo aggiornamento dello script queste cose saranno incluse, nel frattempo vedo di fare qualche test di performance fra eval e define_method, perché il codice come l'hai scritto sopra non mi piace (: Grazie anche a te per l'intervento ^^
-
I motivi quali sono? Leggibilità a parte.
-
Un programma che fa questa cosa ce l'ho! Però è scritto in C#, non sono tipo da C++ ^^ In ogni caso per usare un chara senza scombinarlo aggiungi # al nome del file e le direzioni verranno convertite via codice. Comunque ottimo per gli aggiornamenti! =D ahahaha eh sì xD
-
Uhm sì, tra l'altro ho pensato che c'è un modo alternativo che rimuove del tutto questa parte qui, ma fino a quando non crea problemi e non aggiorniamo per altri motivi può restare così ^^ Grazie per la segnalazione!
-
Una cosa un po' passata inosservata: per i chara puoi usare anche direttamente quelli del 2000 mettendo nel nome del file un # seguito dal nome originale. Chessò, People1.png diventa #People1.png e le direzioni verranno convertite automaticamente ^^ Che comunque, visto che è la prima volta che usi il VX, perché non usi invece l'Ace? Prendilo se vuoi come un consiglio, altrimenti come una semplice curiosità ^^
-
Buahaha conigli, criceti parlanti (scriventi D:), fine del mondo xD Benvenuta! Sii coscente di quel che hai scatenato xD Conosci tante lingue, complimenti! ^^ Beta-reader non l'avevo mai sentito e tutt'ora non ho ben capito cosa significa xD Beh, se hai cominciato da poco con la pixel art allora buon miglioramento. E buona permanenza sul forum ^^
-
Ok, allora: VX Ace Fatto! ^^
-
Ah, uhm, che succede se una cartella non esiste in MidGraphics? Perché tipo nel VX non ci sono né Tilesets, né Titles1 e 2. No, va bene che quelle per cui non serve ridimensionamento (tipo Characters) vengano copiate originali, anzi meglio! Però ci sono altre cartelle che non processa, tipo Pictures, ma giusto per fare un esempio. È vero che uno può fare copia e incolla, però se già che c'è il programma gestisce tutto è molto meglio (: Se vuoi ti do la lista delle cartelle, anche di VX, con scritto se devono essere raddoppiate o no ^^
-
Grande!!! *______* Lo aggiungo in vista dentro al topic! Ma come mai hai scelto solo quelle cartelle? Ottimo il fatto che non vengono processate le sotto cartelle e che vengono presi in considerazione solo i file immagine! Grazieee!!!
-
Aggiornato a 1.3 in armonia con la versione per Ace e sistemato il topic aggiungendo anche il pacchetto font a parte e una demo più leggera.
-
Uhm, questo posto mi ricorda qualcosa... *pulisce le ragnatele dagli angoli* xD sono stato un po' assente ultimamente, eh? Guardando il listino prezzi, mammamia, ma devo complicarmi così tanto a far conti? Vabé che sono ragioniere, ma... xD Facciamo che sì, sono aperto. In ogni caso, però, attualmente ho dei lavori anche arretrati quindi non fate richieste perché non potrei accettarle. Appena mi libero un po', posto il via libera ^^
-
Ti ringrazio per il consiglio, però visto che initialize, update e perform_transfer richiedono comunque un alias, remove_town_sprite preferisco lasciarla lì perché dall'esterno si può così chiamare $game_player.remove_town_sprite per rimuoverla e check_town mi pare stia bene lì, tutto questo sarebbe solo per reset_audio ^^ Poi quando lo sprite non è visibile le variabili diventano nil, e l'update controlla che non sia così prima di fare qualsiasi cosa. Penso che una classe esterna a questo punto costi di più per le varie chiamate. Alla prossima modifica però rimuoverò i vari $game_player. lasciando solo screen_x e screen_y ^^ Grazie per la segnalazione ^^ EDIT: Aggiornato a 2.8, ma ho praticamente solo cambiato il nome e 'standardizzato' quindi non faccio un nuovo post xD
-
:) Una piccola spiegazione riguardo al Tint screen: non è che non funziona più! Siccome l'oscurità va regolata via Call script, c'è un opzione che ti fa specificare i valori, anziché via script, tramite appunto il Tint screen, disattivando però la sua funzione originaria. L'opzione è Surface_UE e basta settarla a false per usare il Tint screen normalmente ^^
-
Per ora non ci stiamo sentendo con Pech, quindi ognuno lavora per conto proprio ^^ Non avevo ancora risposto qui, per far rispondere il boss xD Però prima o poi dovevo farlo ed eccomi xD Tantissimi commenti, tutti molto entusiasti :Q___ Grazie grazie grazie grazie :D Riapparirò di nuovo quando verranno poste domande tecniche inerenti agli script ^^
-
Be', bros, ci sono più persone che capiscono l'inglese rispetto a quelle che capiscono il giapponese ^^ Grazie mille! ^^ Spero non vada contro nessun regolamento postare la guida in pubblico D: Sono furbo, eh eh eh xD
-
Gran scripter Khas. Bello questo pixel movement, anche se il suo script che più mi è piaciuto è quello del light effect *.*
-
Pecche varie da risolvere prima di ritenere RpgMaker utilizzabile
mikb89 replied to 255's topic in RGSS3 (VX-Ace)
Comunque, per raddoppiare la grafica, puoi anche usare programmi che lo fanno in sequenza, così non hai da farle a una a una. Oppure, usando XnView ShellExt, puoi mettere un'estensione al menu dei file immagine che, fra le varie opzioni, ti da quella di convertirla e/o ridimensionarla rapidamente. Molto comodo. -
Pecche varie da risolvere prima di ritenere RpgMaker utilizzabile
mikb89 replied to 255's topic in RGSS3 (VX-Ace)
Allora, a una prima occhiata mi pare che lo script così identico vada anche su Ace. E be', sì, le differenze di ace valgono la pena ^^ Comunque, questa cosa devi farla comunque visto che il programma necessita di risorse di quella grandezza. È vero che puoi anche abbozzarle in quanto ti servono giusto come 'segnaposto', però la versione doppia ci vuole, almeno in fase di develop. Il vantaggio dello script è che, a release, e comunque nel test, andrà ad usare la grafica piccola allargandola :) -
Pecche varie da risolvere prima di ritenere RpgMaker utilizzabile
mikb89 replied to 255's topic in RGSS3 (VX-Ace)
Se vuoi convertirlo ci penso io (: Quella funzione ingrandisce la finestra, però devi anche vedere se i menu si ridimensionano giusti.