Thejuster

Mio modello di PacMan realizzato in blender

Altra screen dal Debugger. Come potete notare, in questa screen c'è l'uso dall CPU, l'fps Meter, e alcune variabili che si possono cambiare come la posizione dell'eroe o la manipolazione delle luci a RunTime. Questo farà risparmiare tempo all'utente durante il debug. ed alla fine, mostrerà una notifica, se si vogliono recuperare le impostazioni e modifiche apportate durante il debug. così si avrà già un bel lavoretto pronto.

si da un problema strano. http://recordit.co/yUYuQI4bnR quando aprite la pagina, cliccate sulla barra degli indirizzi dove c'è il link e navigateci di nuovo esempio premendo invio

Altra bella Feature. Vi presto il Mire Engine Debugger. Attualmente è ancora in fase di preparazione ma cosa fà esattamente? http://recordit.co/yUYuQI4bnR Il super debugger di mire consente come in questa piccola gif, di tenere traccia di tutte le operazioni che svolge il gioco. In questa gif notiamo il costante update del Framerate (Anche se avevo un mare di programmi aperti e stavo in TeamView) Ci consente di modificare direttamente a gioco avviato tutte le variabili e impostazioni di sistema. Come esempio, Possiamo cambiare la coordinata dell'eroe, cambiare le monete, navigare un un'altra mappa, Alterare uno status, o modificare valori di variabili. Insomma, dal debugger di Mire, ci si potrà fare veramente di tutto. Per ora vi ho illustrato questa screen, appena ci saranno altre nuovità vi postero altre belle feature.

Ed ecco qui il risultato finale del componente per la lista delle mappe. Ci è voluto un pò di lavoro per perfezionare tutto, ma alla fine il risultato è notevole 1° Quando si crea una mappa compare una X sopra. Ciò significa che il programma non è in grado di elaborare un'anteprima. Prima di poterla visualizzare bisogna disegnare la mappa, compilarla e salvarla. 2° Fase della compilazione. Anziché mostrare una progressbar generica, viene mostrata direttamente sul componente e quindi indica visivamente all'utente il tempo che occorre per terminare. 3° Spunta Appena terminata la compilazione appare una spunta come quelle presenti sulla altre mappe. Ciò indica che la mappa è stata compilata senza errori. Quindi salvato la compilazione, l'utente finalmente vedrà l'anteprima Spero che sia gradita come cosa. Così si rende il componente delle mappe pieno di funzioni.

eh grazie per l'avvertimento XD me lo ero proprio scordato. Ho rimosso tutto quello che poteva anche minimamente interferire con la eb.

ancora per poco Sto già preparando il set base di mire. completo di Character set e Map Set. Appena ho completato il resource pack base elimino quel video e ne rifaccio un'altro

Nuovità su alcuni fix apportati. Daemond ha ripristinato le anteprime delle mappe finalmente il progetto legge direttamente la folder principale e ne mostra le varie mappe. Ri-Testato nuovamente il sistema di luci e funziona tutto perfettamente come prima. Siamo arrivati già ad un buon punto. Nel frattempo. Abbiamo aperto una bozza su Steam Greenlight. Chiunque voglia pubblicizzarci un pò ci farebbe molto piacere. o magari qualche consiglio o feature http://steamcommunity.com/sharedfiles/filedetails/?id=853291581

il 3°!!!

uhm al max cerco di fargli fare il login automatico senza richidere i dati ogni qual volta che si apre il programma. Ho notato che almeno per me, è fastidio durante il debug a testare e riaprire ogni volta il programma. Invece credo che l'utente una volta aperto lo tiene aperto e non lo chiude in continuazione. Ma comunque è una cosa che devo fixare, è abbastanza noiosa come cosa.

XD bhe genera sempre una curvatura bilanciata. Ah dimenticato di dire un'altro particolare. Quando si avvia il programma richiede i dati di accesso Indipendentemente dalla versione utilizzata, free, basic o pro. Se capita che l'utente è offline, può comunque utilizzare il tool ma non compilare o esportare. L'algoritmo di cifratura è molto particolare che ovviamente non posso rivelare come funziona, E le protezioni anti crack sono veramente tante. Altra cosa, per creare un animazione, è possibile scegliere qualsiasi tipo di immagine e suddividere in griglia una qualsiasi immagine. Prendo esempio un chara di rpgmaker. La suddivisione avviene in modo automatico, l'importante è che l'immagine sia (^2) ovvero una potenza di 2. si può fare esempio 200x100 oppure 130x150 ma non 133 X 151.

Sono stato molto assente in questo periodo per lavoro e altre faccende. Ma vi mostro quel poco che sono riuscito a fare :) In primis, l'updater per i beta tester è ora disponibile. Non dovranno più richiedere o che io debba passargli una nuova versione per ogni nuovo test Il database standard inizia a prendere vita. Con ulteriori parametri e stats ancora da aggiungere Sistema di generazione per la Curvatura dell'esperienza Abbiamo poi il Random Pool. Cosa fà il random pool? Disegnandoci sopra qualsiasi cosa, esso genera una nuova curvatura bilanciata senza che l'utente debba esaurirsi sui vari parametri e combinare pasticci, o creare una curva non proprio bilanciata. Quindi esempio disegnando una G sul pool Si avranno dei parametri generati, e una curvatura ottimizzata. mediante un semplicissimo algoritmo di generazione. L'altra nuovità e che Mire non avrà un template per i vari charaset o tileset. Ma il template lo costruirà l'untente stesso. è ancora il costruzione ma esempio vedremo un qualcosa del genere L'utente prenderà un qualsiasi file di qualsiasi tipo di template è si costruirà il proprio chara. Così come avverrà per i Tileset. (un pò come accade in unity) Negli ultimi test, Mire è stato testato anche su SmartTV Serie 5 Precisamente su una Samsung Curved 55"

Nuovo Aggiornamento anche sul'appstore https://play.google.com/store/apps/details?id=makingitalia.net.mireengine ecco ora il motore girare sul mobile perfettamente. Manca la gui si, la sto realizzando proprio ora. Ma si può notare già il fantastico SplashScreen quello dedicato alla versione Free e la sua partenza instantanea Riguardo ai nodi, Abbiamo avuto un'altra idea. Rot mi ha delucidato su una feature che potrebbe essere molto interessante. tipo l'utente può crearsi dei supernodi. Ovvero, prototipi di funzioni precedentemente assemblati. tipo nell'esempio di prima per fare quel calcolo ci sono voluti tipo 5 o 6 nodi. Raggruppandoli tutti assieme in un super nodo, la funzione sarà la stessa, Ma l'utente avrà creato un prototipo di funzione da poter riutilizzare successivamente

Si tecno forse sicuramente Blue Print di Unreal Engine http://i.imgur.com/T2p18c5.png CryEngine Nodi http://i.imgur.com/KnqOFlD.png Anche in unity ci sono http://answers.unity3d.com/storage/temp/31510-unity+2014-08-25+10-21-55-325.png GG Maker http://www.engine001.com/images/screenshots/2010/scripting.png Insomma praticamente quasi tutti i tool moderni utilizzano i Nodi. Poi ovviamente come sia, c'è anche la possibilità di scriptare. Il più difficile che ho provato, e quello di UDK. Quello è molto ma molto complicato da capire, eppure lo usano le software house di sviluppo con tripla A Il blueprint di UDK gira in un modo tutto suo. Ancora non ho appreso il suo funzionamento. Ma sembra che ogni nodo, sia gestito da un evento di avvio. Quello di Mire funge un pò come quello di GG. Nel senso che si ha uno [ Nodo ] START e via via dicendo a susseguirsi con gli altri. Vantaggi è Svantaggi: Vantaggi: * Si ha la possibilità di copiare, Incollare e condividere il grafico dell'eveto con amici. Cosa che non è possibile fare con gli eventi classici a cui siamo abituati *Runtime Esecution Il contenuto dell'evento può essere manipolato a RunTime, cosa che non è possibile con i classici eventi serializzati in binario Svantaggi: * Bisogna farci un pò la mano all'inizio, ma capito il funzionamento, si fa prima con i nodi che con gli eventi normali. Intanto vi mostro piccoli progressi con il motore web ma ancora da sistemare http://95.254.226.192/MireWeb/

uhm alla fine credo che sia una cosa abbastanza chiara. Mi piace il sistema di daemond spiego http://i.imgur.com/F7I2TzL.png ovviamente può sembrare molto complesso o anche incasinato. Ma in questo caso, credo che ha voluto fare dei calcoli su variabli. mentre un utente può anche tranquillamente fare esempio: Setta alla variabile ID 1 Valore costante 2 , continua Non credo sia poi così chiassoso come sembra. ovviamente, più operazioni si fanno, più moduli si devono inserire. Alla fine ogni tool và imparato non può essere uguale all'altro. Ma è anche vero che puntiamo su due fattori importanti Performance è facilità alla fine credo che in questo esempio anziché vedere un qualcosa come <> Poni, var[00002],var[000001] <> Poni, var[00003],, var[00001] / var[00002] o qualcosa del genere. ma in questo caso, anziché leggere tutto, si ha una visuale di ciò che si sta facendo. bisogna solo farci un pò la mano :D per il resto come detto da Daemond, si procede bene con i due motori Quello in JS è quasi arrivato alla pari con quello di Mire Certo si, Mancano ancora tante cosette, ma si viaggia bene per ora senza intoppi troppo complicati. Il problema più grosso e creare delle classi in Output che siano compatibili sia con il motore di mire per il desktop che per quello in nativo in Javascript.

video privato registrato con il cellulare https://www.youtube.com/watch?v=kFEerQGBVpA&t=2s è un anteprima del progetto.

Bhe l'idea non sarebbe male. Se hai letto i primi topic, il motore inizialmente era stato progettato per il 3D. Ma siccome all'epoca ero ancora molto ma molto inesperto sul 3D non sapevo modellare, e mi limitavo ad usare modelli già creati dagli utenti. Oggi saprei creare qualsiasi modello 3D animato e non. Ma ad un motore avviato già all'80% sarebbe un colpo ricominciare da capo. Ma negli ultimi test abbiamo avuto un bel problema. Come pensavo, Lo shader di Mire per le luci, non funziona sul mobile. Dopo la compilazione ed il porting, una volta aperto rimane bianco. Mentre con una scena semplice si vede tutto bene. A questo punto abbiamo pensato, anziché eseguire un wrapper da C# a Javascript. Tanto vale creare un motore anche in javascript. Ma non basandoci su motori già esistenti come ha fatto MV. Ma ovviamente crearci sempre il nostro motore proprietario. Almeno funziona come noi diciamo, e deve fare ciò che noi vogliamo fare. cosa ben differente.

come feature sembra interessante Però abbiamo risolto alla grande il problema della mappa. Vi mostro una cosa :) proprio per farvi cambiare opinione sulla potenza di Mire. Screen Appena fatta per un test su una mappa Illimitata! Gli FPS non sono taroccati in questo caso li ho voluti misurare volutamente con un tool esterno Fraps per l'appunto 125 FPS non sono pochi eh! ed abbiamo inserito anche un limitatore per il framerate altrimenti credo che superava tranquillamente la soglia dei 700 FPS per questo prima portava via un botto di ram. Ora fila una cannonata

Esatto sono passati ben 8 anni da quando è iniziato il progetto. In alto mare? direi proprio di no. Il motore è pronto, funzionale al 100% I test vengono fatti proprio per l'inserimento delle nuove tecnologie ed aumentare la potenza del tool Che non ha nulla a cui invidiare di un tool professionale anzi... Le directX non sono vecchie anzi. ecco ora a cosa siamo arrivati DirectX 11 e mutazione da DirectX a SDL. L'apk era per mostrare che il motore viene eseguito tranquillamente da un dispositivo mobile. nulla di più e nulla di meno. Il progetto deve vedere la luce, non morirà. Anzi, negli ultimi anni e più vivo che mai. Il progetto è stato sospeso anche per un periodo abbastanza lungo. Avevo perso tutto il progetto. Causa di un incendio provocato dal mio computer nella stanza. Andò tutto in fumo compreso tutti i miei backup su HD esterno. All'epoca non esisteva DropBox o servizi di web storage. Ma esisteva max Altervista che ti dava 100mb di spazio web e potevi farci veramente ben poco. Per il resto come detto, Mire supporta tranquillamente Javascript ed HTML5 senza problemi. in 3D? Certo, volendo, è possibile utilizzare modelli 3D all'interno di Mire. Mire in un certo senso è in 3D non in 2D. C'è una telecamera che punta verso il basso per inquadrare la scena. Lo dimostra anche il fatto del mio particolare Shader delle luci. Che normalmente non è possibile farlo in 2D. Ma le luci funzionano solo su modelli che sono hanno vertici o denominati Quad. Attualmente stiamo lavorando sull'editor. L'editor è il lavoro più duro da fare anche se non sembra. L'editor crea la mappa, Crea gli eventi, crea gli script, gestisce un database e molto altro. L'engine il suo lavoro, e solo quello di interpretare il lavoro svolto dall'editor. La domanda ora è: Perché state rifacendo di nuovo l'editor da capo? Perché le GDI non si ha affidabilità o velocità appropriata per un lavoro del genere. le GDI girano a 3 massimo 5 FPS Cosa veramente penosa. In mire fin quando si lavorava su una mappa 30 x 30 Blocchi (30 * 30 = 900 tile ) andava bene. Ma quando la mappa era più grande, ed i calcoli iniziano a pesare il lag è inevitabile. Con il nuovo editor, Abbiamo testato una mappa di 10.000 pixel l'equivalente di 320.000 Tile senza un briciolo di lag. L'esperimento che abbiamo fatto in questa settimana era quella di ottimizzare la velocità dell'editor Perché il nostro obiettivo è: Non è fare un tool come quelli presenti. Ma farlo migliore! Si mire avrà un prezzo , è perché varrà quei soldi spesi fino all'ultimo centesimo, e non fatto a cavolo solo per guadagnare soldi. Quindi il primo obiettivo sono le prestazioni. Il motore deve essere stressato al massimo, fino alle sue possibilità e deve girare bene. Ne crashare, ne dare problemi o annoiare l'utente mentre lo si usa. Io ho giocato con dei giochi di MV, ma il lag era un qualcosa di impressionate. e l'ho chiuso subito. Era praticamente ingiocabile. Non voglio sindacalizzare ora il lavoro degli altri ma ci vuole. MV usa un engine OpenSource chiamato "pixi.js" gratuito e quando si usa roba OpenSource, si deve anche sapere incontro a quali rischi si hanno. Che ovviamente non potrà mai essere fatto un lavoro come lo stesso autore lo farebbe a pagamento. Mire ha un motore proprio. Non è stato copiato da nessuna parte, anzi. Molti hanno copiato proprio dal motore di mire. per questo ora gli engine si vedono spuntare come funghi. guardando le statistiche di SourceForge, il vecchio motore dal 2009 al 2016 ha avuto circa 20 milioni di download. e questo non è un caso. Ora avendo un valido aiutante finalmente, (Dopo averlo cercato per tanti anni) la velocità di produzione sarà raddoppiata. Se avessi collaborato dall'inizio con un'altro programmatore, avrei impiegato la metà del tempo che ho impiegato normalmente per arrivare a questo punto. Poi parliamo di un motore, Ci sono giochi che sono stati realizzati in più anni. mentre qui parliamo di un programma per Creare giochi, non per giocarci. cosa ben differente.

Per quanto riguarda il combinare 2 mappe, questo è possibilissimo non c'è dubbio. Ma c'è una bella differenza il Motore e l'editor. Nell'editor non puoi suddividere la mappa durante il disegno, anzi rallenterebbe ancora di più il processo caricando e scaricando mappe. un esempio mi trovo qui Mappa 1 <- | -> Mappa2 con un piccolo spostamento sarei costretto a ricaricare la mappa2 viceversa la mappa 1 Minecraft non funziona in questo modo. Minecraft essendo in 3D, la mappa viene già caricata completamente, ma viene renderizzato solo una parte che sarà visibile allo schermo o al Fov. Dopo entra in gioco l'occlusion Culling che oltre a man mano, renderizzare sempre in più bassa qualità, arriva al nulla anche perché non avrebbe senso renderizzare cose che il giocatore non può vedere. Ho appena fatto una correzione all'editor. C'era bisogno di ritardare il rendering. Il metodo Paint arriva fino a 1000 call quindi e come se renderizzassi a 1000 fps per questo la ram perde consistenza e il Grabage Collector inizia ad andare sotto sforzo. Ho semplicemente ritardato il Thread di qualche millisecondo per avere da 1GB Di Ram di cosumo ad un massimo di 6MB PRIMA 919MB di RAM NB: Notate lavoro che mette sotto stress (Simbolo di colore giallo) Dopo 39MB di Ram Con lavoro del GB Minimizzato

Alcuni aggiornamenti sugli sviluppi di Mire. Io e Deamond siamo stati impegnati tutti la settimana a lavorare su Mire. Il perché aveva un grosso problema relativo alle prestazioni. Sebbene le GDI nativamente sono cross-platform hanno grossi problemi di stabilità nella fase di rendering. Daemond mi aveva fatto notare che fin quando si tratta di una mappa 30 x 30 Blocchi = 960 pixel le GDI funzionano a meraviglia, Ma ingrandendo di più la situazione si complica, Le GDI infatti non superano i 3 FPS. E questo era un grosso problema. Successivamente siamo passati ad OpenGL. nel tentativo di velocizzare il disegno ed il rendering della mappa. Terminato il lavoro, siamo giunti alla stessa decisione, che le OpenGL fanno abbastanza pena. Ci sono diverse lamentele online riguardo alla lentezza delle openGL. Purtroppo l'unico rendering che veramente merita sono le DirectX. Sono ineguagliabili sia in termine di prestazioni che di velocità. Facendo qualche calcolo e qualche confronto Rpgmaker MV ha un massimo di 256 x 256 Tile per Mappa l'equivalente di 12.288 pixel per mappa. Rpgmaker 2003 / 2000 ha un massimo di 100 x 100 tile ma con diverse patch arriva a 999 x 999 c'è una differenza però, Rpgmaker 2 / 2k3 utilizza tile 16x16 quindi si dimezza ma cmq è un numero veramente elevato pariamo di un qualcosa come 15.984 pixel per mappa. Ma ci scommetto la testa, che il lag si fa sentire. e anche molto. Ma su questo ho seri dubbi anche perché Rpg 2 2k3 hanno immagini da 256 Colori ad 8 bit. Mentre gli altri 16m di colori a 32bit. Dopo le ultime modifiche, Mire ha avuto come promesso un aumento di prestazioni del 200% Abbiamo usato Mono Framework con un wrapper alle DirectX 11 Essendo Mono Cross-Plattform non dovremmo avere seri problemi. Ma questo lo verificheremo a breve. Fatto sta, che Mire " Non ha limiti di grandezza per Mappa" Esatto, in mire si può avere una mappa grande anche 20.000 pixel Questo grazie all'implementazione di una classe derivante dal motore di Mire. Ho portato parte di una classe del motore di Mire Engine nell'editor Questa modifica ne ha incrementato notevolmente le prestazioni. Perché ho progetto il motore di Mire, per essere un razzo a reazione, Stando attento ad ogni piccolo accorgimento. C'è solo un problema. Maggiore sarà la mappa, Maggiore sarà la memoria RAM utilizzata dal motore. Con una mappa di 2000 pixel il consumo e minimo Ma testando con una mappa di 10.000 Pixel si arriva ad un utilizzo di quasi 900mb di Ram. Ma stiamo parlando sempre di una mappa grande 312 Blocchi * 32 1/4 in più da quella supportata da Rpgmaker MV. Qualche calo di memoria è anche permesso a questo punto no? Ma vedremo in futuro in qualche modo di realizzare qualche controllo mirato su questa cosa. Ma voglio veramente ringraziare Daemond per tutto il lavoro svolto Senza il suo aiuto oltre ad impiegare il doppio del tempo, non avrei fatto diversi algoritmi che Daemond ha implementato per Mire. Quindi lo ringrazio veramente con il cuore. Presto altri aggiornamenti sullo sviluppo

Si perché mire sarà costituito da varie licenze. Free, Basic e PRO la versioni Free e Basic sono abbastanza limitate. un esempio e che con la free si ha lo splash screen obbligatorio. con la Basic lo si può togliere, ma come la free non si possono generare giochi Cross-Platform esempio per android, Linux mac ecc. ecc. solo per win Ma acquistando la licenza PRO si ha tutto. che non è molto costosa. la versione basic costerà 20€ per i primi 6 mesi 10€ così come la PRO 50€ invece di 100 per i primi 6 mesi. non costa poi tanto, mettendo poi di fatto che sia tra le mani un tool molto potente e non di certo un giocattolino. per i beta tester. C'è un EULA ed un contratto da rispettare. Se il contratto viene violato si passa per via legale. Quindi non posso dare a tutti questa possibilità o magari si presenta un ragazzino di 12 anni ed inizia a passare il programma ad amici e parenti. Chiunque partecipa al progetto Mire ha accettato il contratto. 1) Non ci si può ritirare 2) Non si possono dare info, o risorse varie per la rete. (tranne da parte di Making Italia) Immagina ad un ragazzino che prima partecipa e poi non si fà più vedere. Dopo sarebbe un bel problema sia per me che per lui. Quindi evito proprio di fare ciò. Passando la mano a persone più responsabili ed adulte. 3) Perché offriamo Licenze PRO Gratuite. Non possiamo regalare una licenza PRO di 100€ a chiunque partecipasse. Ma come detto nel punto 1 e 2, c'è una clausola da seguire.

Grazie freank :) Porto nuovità sia riguardante l'editor che altre cosette. La campagna partita con mire, offriva a chi si univa come Beta Tester o faceva parte del progetto, riceveva in omaggio la Licenza e Chiave Seriale per Mire PRO Commerciale. Volevo dare il benvenuto ai nuovi membri del progetto. hrot: Beta Tester Ufficiale Italiano Daemond: Programmatore C# e Javascript Koams Beta Tester Ufficiale Tedesco Attualmente si ricercano ancora ruoli come Grafici di risorse esclusive come Tileset o Charaset. Gli altri posti come Beta Tester sono riservati ad utenti di altre nazionalità o utenti che conoscono una certa lingua. Ricerchiamo 1 beta tester per ogni nazionalità. Oppure utenti volenterosi per apprendere il Javascript relativo alle funzionalità di Mire Riguardo all'editor, lo stiamo perfezionando per renderlo ancora più performante. C'era un problema con alcune funzioni grafiche relative al disegno. Con una mappa troppo grande, il disegno rallentava. Più e grande la mappa, maggiori sono i rallentamenti. Abbiamo deciso dunque di utilizzare parte del Motore di Mire direttamente nell'editor. e Renderizzare la mappa direttamente in DirectX o in SDL Per il supporto Cross-Plattform, verrà tutto gestito dall'installazione. Le librerie di riferimento a Windows verranno sostituite con quelle di altri sistemi operativi. Come in questo caso, e possibile sfruttare il rendering SDL2, openGL o DirectX questa modifica all'editor comporterà un aumento delle prestazioni dell'editor di oltre il 200% Avendo un supporto grafico che non passa più per la CPU ma per la GPU si hanno grossi vantaggi in termini di prestazioni e di velocità. La UI rimarrà sempre quella. Cambierà il sistema di rendering di cui ci stiamo già lavorando sopra.

per ora ho preferito di no. Lasciare una dimensione fissa. Ma ci farò un pensierino successivamente. In primis voglio rilasciare almeno una demo giocabile

Ma non credo sia possibile una cosa del genere, anche perché un chara misura 32 x 64. è stato calcolato che i 16pixel dal basso verso l'alto sono collisioni, gli altri vuoti. quindi anche se un ala arriva ai bordi, risulta pur sempre un ostacolo per il player. non potrà a andare sopra o in casi particolari si creano chara fissi e ali su un'altro layer.