RM2k/2k3 Graphics (320x240) mikb89

[255]

RM2k/2k3 Graphics (320x240) v. 1.4

Descrizione

Versione per il VX Ace di

questo script

. Rende possibile l'utilizzo di grafica old style (RPG Maker 2000/2003), tileset 16x16 anziché 32x32. Lancia il gioco in risoluzione 320x240 ma con la finestra allargata a 640x480.

È possibile sia mantenere i font del VX Ace sia avere quelli "old style".

 

Old style

METHOD = 1

http://oi39.tinypic.com/mmvpg.jpg

 

VX Ace style

METHOD = 0

http://oi41.tinypic.com/2aah8xk.jpg

 

Autore

mikb89

 

Allegati

Template

:

http://www.mediafire.com/?xdba49176p12w

 

Istruzioni per l'uso

Il contenuto del file zip è un template, ovvero un progetto da cui è possibile partire per creare il proprio gioco.

 

Il modo di organizzare il vostro progetto è quello che segue.

Su Graphics ci vanno le immagini ingrandite (dimensione normale di VX Ace), mentre su MidGraphics ci vanno le immagini in risoluzione RM2k/2k3 (dimezzate).

Le immagini su Graphics servono solo all'editor per visualizzare correttamente i tileset, mentre testando il gioco l'EXE userà le immagini a dimensione ridotta che si trovano su MidGraphics.

 

Lanciando il gioco fuori dal programma, al contrario, l'EXE andrà a leggere la cartella Graphic. Quindi quando volete fare la release del vostro gioco eliminate la cartella Graphics (magari backuppandola prima), e rinominate la cartella MidGraphics in Graphics.

 

Per ridimensionare automaticamente le risorse

(e altre comodità) potete utilizzare questo programma:

http://www.rpg2s.net/forum/index.php?showtopic=15079

 

Per importare direttamente i charset del 2k/2k3

inserite il simbolo # davanti al nome del file. Esempio: '#Chara1'. Così facendo lo script mostrerà correttamente le

direzioni

dei charset (i charset del 2k/2k3 hanno infatti posizioni diverse).

 

Per quanto riguarda il font

leggete i commenti all'inizio dello script.

 

Se non volete utilizzare il template, inserite un nuovo script sotto Material e incollate manualmente il codice che trovate a questo link:

http://pastebin.com/3tyTGSpz

 

Bugs e Conflitti Noti

N/A

 

Edited April 17, 2012 by 255

[Ichika Strize]

Giuro, stavo a giorni per chiedere a mikb (nella sua bottegha) se riusciva a convertirlo per RGSS3 *-*

 

Davvero ottimo lavoro, i miei complimenti *-*

Una stra-figata di script!

Edited April 9, 2012 by Ichika Strize

[255]

Alla fine non c'era nulla da convertire a parte ridimensionare la finestra siccome quella del VX Ace è un po' più piccola. Se poi escono fuori bug si può sempre correggerli ma per ora mi sembra lo script funzioni perfettamente. mikb89 presto lo revisionerà, comunque. Edited April 10, 2012 by 255

[Guardian of Irael]

Ah bene hai tradotto quello di mikb come dicevate nell'altro topic! ^ ^

Anche qui senza risoluzione piccola, piccola, ma tutto raddoppiato! Almeno non fa male agli occhi! XD Ottimo lavoro, speriamo di vedere più progetti con grafica da zero! ^ ^

[255]

Anche se non è da zero ed è rippata è sempre migliore (secondo me) dello stile del VX.

 

Aggiornamento

-template normale con supporto RTP disponibile;

-i due template ora hanno gli script commentati in inglese, non più in giapponese;

-fixato il colore delle finestre.

[La fine di An Another Life]

FAIGO *_*

 

Questo potrebbe essere interessante.

[kaine87]

finalmente ora i tileset cubettosi dovrebbero diminuire nei progetti XD

[Keroro]

Lo script ha diversi imprecisioni/errori:

 

Il primo è che nel modulo Font ridefinisci la keyword method inserita in ruby 1.9.x (quindi togli funzionalità).

Font.method(:simbolo) #equivale a invocare il metodo Font.simbolo

Documentazione

Ti consiglio quindi di usare un altro nome per metodi e variabili, magari più esplicativi.

 

Il secondo è che pur avendo messo un alias, non lo chiami! Quindi sovrascrivi il main togliendo funzionalità!

rgss_main in rpgmaker vx ace rende possibile il reset tramite F12.

Quindi elimina

alias main_rgss rgss_main
def rgss_main
 Graphics.resize_screen(640,480)
 SceneManager.run
end

E sostituiscilo con:

Graphics.resize_screen(640,480)

Metterlo en plein air è il modo migliore di farlo eseguire all'inizio.

I

[255]

La parte che ridimensiona è una mia aggiunta e quindi faccio mea culpa XD D'altra parte non so ancora nulla dell'RGSS.

Provvedo subito a cambiare, grazie.

[Keroro]

Tranquillo, anche io ho iniziato da poco e ho scoperto alcune cose solo leggendo l'help ;o

[255]

Aggiornamento:

* script completamente revisionato;

* il metodo 3 per il font (caratteri in immagini separate) ora funziona.

Edited April 11, 2012 by 255

[Lusianl]

Uao.Un sogno che si realizza.Grande 255.

Aspetta però che non ho capito, nello stesso progetto devi fare due cartelle, mettendo in una la risoluzione 320x240 e nell'altra quelle 640x480, giusto?

In pratica si deve sempre ricorrere all'ingrandimento grafico delle risorse...

[Guardian of Irael]

Aspetta però che non ho capito, nello stesso progetto devi fare due cartelle, mettendo in una la risoluzione 320x240 e nell'altra quelle 640x480, giusto?

In pratica si deve sempre ricorrere all'ingrandimento grafico delle risorse...

Sì, devi comunque raddoppiare le immagini importate! Poi alla fine quelle normali andranno tolte per risparmiare spazio.

^ ^

[255]

@Lusianl

I crediti vanno a mikb89.

 

La cartella con le immagini a dimensione normale serve soltanto per l'editor (cioè per il programma VX Ace, per fargli visualizzare correttamente i tileset).

Non c'è bisogno di convertire Characters, Titles, e altro, è opzionale. Ma i Tilesets è praticamente obbligatorio altrimenti avrai difficoltà a mappare perché il VX Ace visualizza i tilesets a blocchi di 32x32.

 

Aggiornamento

* Sistemata la codifica dei caratteri (ora le lettere accentate si vedono correttamente);

* aggiunta la possibilità di avere grandezze diverse dei font bitmap.

Edited April 11, 2012 by 255

[Lusianl]

Ops.Grande mikb allora.=)

Ho capito il funzionamento.

[255]

Aggiornamento

* programma per ridimensionare automaticamente le risorse.

[Kingartur2]

Innanzitutto complimenti bello script.

Ho così uno sguardo sommario(sono l'una non potevo fare di meglio XD) e ho visto l'ultima parte di codice, così com'è è scritta bene, però secondo me giusto per evitare casini potresti scrivere:

 

 

class Window_EquipStatus
 if [1,3].include?(RM2K::FONT_TYPE)
def draw_right_arrow(x, y)
  change_color(system_color)
  draw_text(x, y, 22, line_height, \">\", 1)
end
 end
end

 

il funzionamento è lo stesso però il codice risulta molto più pulito e meglio interpretabile.

 

 

P.S. : ho appena dichiarato guerra all'editor

Edited April 11, 2012 by kingartur2

[mikb89]

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!

[Keroro]

Concordo con kingartur, eval è un comando che andrebbe usato solo in casi estremi e non ci sono alternative, in questo script è usato due volte :s

[mikb89]

I motivi quali sono?

Leggibilità a parte.

[Keroro]

Per i motivi basta che cerchi su google "eval evil" o "eval bad".

La quasi totalità dei programmatori ruby ritiene che eval vada usato solo quando strettamente necessario.

Ed in questo caso non fai che valutare stringhe statiche quindi è ancora meno necessario del solito.

Il primo:

eval "class Window_Base; def update_tone; end; end" unless RM2K::CHANGE_SKIN_TONE

è banalmente sostituibile con

unless RM2K::CHANGE_SKIN_TONE
 class Window_Base
def update_tone
end
 end
end

Il secondo come dice king artur.

 

Se tutti usassero eval non si capirebbe più una mazza negli script, sono stringhe valutate in real time, molto meglio che l'errore spunti in fase di caricamento.

[mikb89]

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 ^^

[255]

Non è questione di errori, ma di convenzioni e di leggibilità. Parlo in generale.

[mikb89]

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

[Guest clyde]

Anche il seguente codice funziona e per quantità di dati minime non causa rallentamenti apprezzabili. Clyde si domanda perché non usarlo.

def assegna(val)
a = val
b = a + 14
c = b + a - 12
d = c - 14
a = d + 12
a -= val
end