[PROG] Codice base su cui poter iniziare

Ecco il risultato, giocando un po' con OpenGL:
http://xyle.altervista.org/OpenGL/Esempio_OpenGL.zip

Parpacak ha scritto:Ecco il risultato, giocando un po' con OpenGL:
http://xyle.altervista.org/OpenGL/Esempio_OpenGL.zip

Non me lo fa salvare, mi apre semplicemente altervista, non credo si possa usare altervista come file storage, se non sei loggato.

JJ

Ah non sapevo, è un servizio che non uso molto.
Da qui si arriva?
http://cid-c802fc7743b13994.skydrive.live.com/self.aspx/Pubblica/Esempio%7C_OpenGL.zip

Parpacak ha scritto:Ah non sapevo, è un servizio che non uso molto.
Da qui si arriva?
http://cid-c802fc7743b13994.skydrive.live.com/self.aspx/Pubblica/Esempio%7C_OpenGL.zip

Pare di si, ma dice che è corrotto... Non so

JJ

lol, sarà mica destino..
Ho provato ad inviartelo tramite email, altrimenti ti passo il codice e te lo compili.

Parpacak ha scritto:lol, sarà mica destino..
Ho provato ad inviartelo tramite email, altrimenti ti passo il codice e te lo compili.

Puoi inviarlo come file nell'apposita sezione su tk programmatori comunque

Comunque non funziona, mi dice che non può partire perchè la configurazione è scorretta, di provare a reinstallare. O l'hai compilata con un compilatore di prova (esempio una versione studenti) che quindi genera eseguibili non funzionanti senza ide installato, oppure deve leggere dei dati dal registro di windows e non li trova. Oppure manca una libreria esterna. O non so

JJ

Lol, forse ho capito, ti mancano le librerie GLUT.

- freeglut.dll in: ‘C:\WINDOWS\system32\’
- glut32.dll in: ‘C:\WINDOWS\system32\’

Ti invio i file che ti servono.

Parpacak ha scritto:Lol, forse ho capito, ti mancano le librerie GLUT.

- freeglut.dll in: ‘C:\WINDOWS\system32\’
- glut32.dll in: ‘C:\WINDOWS\system32\’

Ti invio i file che ti servono.

Continua a non andare...

Aaaarg.
Se vuoi ti passo il codice (progetto Visual Studio 2008) e le cose che ho installato per le librerie glut?

Parpacak ha scritto:Aaaarg.
Se vuoi ti passo il codice (progetto Visual Studio 2008) e le cose che ho installato per le librerie glut?

Non ho da compilarlo, che versione Visual Studio hai installato? Hai compilato con le librerie e tutto l'ambaradan incluso nel codice? Perchè il sorgente mi sembrava un po' tanto piccolino per essere di visual studio

JJ

la versione è la 2008.
Ora provo a vedere di compilarlo per bene.

Ecco ecco ora funziona, è carino postalo da qualche parte che possano vederlo tutti, al limite mettilo su tkprogammatori.

JJ

L'ho postato sul gruppo di yahoo.
Comunque non è granchè, è il mio primo progetto in OpenGL.
Inoltre mi interessava capire, più che altro, alcuni concetti di programmazione grafica, piuttosto che ottenere qualcosa di bello.

Ho fatto qualche stress test su coffemud e direi che regge piuttosto bene anche, se la soluzione che usa quando il combat si fa troppo complesso è quella di far terminare completamente il combat nella room. Il carico di cpu è notevole comunque, bisognerebbe fare un test con 10 persone che combattono e vedere cosa succede. Ho il dubbio che che già con pochi gruppi di pg che combattono il lag si mostri. (Mi fa venire in mente quando ho iniziato a giocare a leu che sapevo a che punto erano della quest del tarrasque a seconda del lag che si mostrava in gioco, ma li era diverso non veniva nemmeno rispettato il tic di 75 secondi).
Come già accennato confermo che è praticamente scritto tutto su file java, in pratica o si prosegue dall'impostazione data, oppure è meglio buttare via tutto e tenere solo quello che non fa parte della meccanica del mud ma solo I/O, chat, log-in ecc...

In ogni caso se si vuole implementare un sistema multi mud, quindi con meccaniche diverse ma db in comune, coffee mud è assolutamente inadatto.

Ora bisogna decidere cosa fare, se partire con il progetto di fare un mud interessante e parzialmente versatile (the keeper mud) oppure un sistema totalmente nuovo completamente personalizzabile senza dover toccare il codice (the keeper core).
La strada che seguirei la cercherei in base a chi è interessato a questo sviluppo, sopratto all'interesse dei coder. E soprattutto valutando la difficoltà TKM è facile ma per nulla breve, TKC è estremamente difficile.

JJ

Jumping Jack ha scritto:Ho fatto qualche stress test su coffemud e direi che regge piuttosto bene anche, se la soluzione che usa quando il combat si fa troppo complesso è quella di far terminare completamente il combat nella room. Il carico di cpu è notevole comunque, bisognerebbe fare un test con 10 persone che combattono e vedere cosa succede. Ho il dubbio che che già con pochi gruppi di pg che combattono il lag si mostri. (Mi fa venire in mente quando ho iniziato a giocare a leu che sapevo a che punto erano della quest del tarrasque a seconda del lag che si mostrava in gioco, ma li era diverso non veniva nemmeno rispettato il tic di 75 secondi).
Come già accennato confermo che è praticamente scritto tutto su file java, in pratica o si prosegue dall'impostazione data, oppure è meglio buttare via tutto e tenere solo quello che non fa parte della meccanica del mud ma solo I/O, chat, log-in ecc...

In ogni caso se si vuole implementare un sistema multi mud, quindi con meccaniche diverse ma db in comune, coffee mud è assolutamente inadatto.

Ora bisogna decidere cosa fare, se partire con il progetto di fare un mud interessante e parzialmente versatile (the keeper mud) oppure un sistema totalmente nuovo completamente personalizzabile senza dover toccare il codice (the keeper core).
La strada che seguirei la cercherei in base a chi è interessato a questo sviluppo, sopratto all'interesse dei coder. E soprattutto valutando la difficoltà TKM è facile ma per nulla breve, TKC è estremamente difficile.

JJ

ottimo finalmente abbiamo qualche cosa di veramente tangibile in mano! come dici tu secondo me l'unica parte da tenere di coffee è lo scheletro iniziale poi da li si parte da zero. che tra le altre cose se il progetto "rimborso" va in porto dobbiamo anche necessariamente avere un codice "nostro".

sinceramente sarei per il TKC ovviamente momentaneamente incentrato sulla creazione di un singolo mud ma programmando sempre nella direzione di poter creare il sistema.

Per il TKC escluderei java a priori. Mi venuto il voltastomaco per i 30 minuti che ho dovuto aspettare mentre coffemud importava 48 aree. Scritto con un qualunque altro linguaggio il tempo massimo che gli concedo è di 10 secondi e già sono una marea, il tempo che dovrebbe metterci è "0".
E' come se io dovessi applicare un filtro con photoshop a un immagine 800x600 e ci mettessi 10 giorni.

JJ

Jumping Jack ha scritto:Per il TKC escluderei java a priori. Mi venuto il voltastomaco per i 30 minuti che ho dovuto aspettare mentre coffemud importava 48 aree. Scritto con un qualunque altro linguaggio il tempo massimo che gli concedo è di 10 secondi e già sono una marea, il tempo che dovrebbe metterci è "0".
E' come se io dovessi applicare un filtro con photoshop a un immagine 800x600 e ci mettessi 10 giorni.

JJ

ihihih grazie per l'esempio "architettonico" si capisco la cosa si direi che è decisamente troppo figuriamoci quando avremo a che fare con una 10ina di mud che uppano stanze...

Salve a tutti,
scusa se mi intrometto nella discussione ma è solo per fare un appunto.
CoffeeMUD ha un sacco di impostazioni strane e il tempo di caricamento dell'area è direttamente legato al DB che hai scelto e come lo hai impostato.
Se avete fatto i benchmark con il default stava quasi sicuramente usando il fakedb che ha delle prestazioni veramente misere...
Il problema maggiore di CoffeeMUD è che carica tutto in RAM per cui su aree molto trafficate si mette a consumare un sacco di memoria.

Sito

e giusto per una maggiore precisazione. Molte aree , se non vengono usate, non vengono neanche caricate in RAM (cosi' non consumano nulla). Dipende tutto da come lo si imposta.

Sito ha scritto:Salve a tutti,
scusa se mi intrometto nella discussione ma è solo per fare un appunto.
CoffeeMUD ha un sacco di impostazioni strane e il tempo di caricamento dell'area è direttamente legato al DB che hai scelto e come lo hai impostato.
Se avete fatto i benchmark con il default stava quasi sicuramente usando il fakedb che ha delle prestazioni veramente misere...
Il problema maggiore di CoffeeMUD è che carica tutto in RAM per cui su aree molto trafficate si mette a consumare un sacco di memoria.

Sito

Si, ho usato il fakedb, vedrò di rifare il caricamento delle aree con un'altro db.
Il fatto che carichi tutto in ram non è il problema maggiore... DEVE caricare tutto in ram, non è accettabile che il serve abbia dei rallentamenti di caricamento, mai. Anche perchè nell'ipotesi che il mud diventi florido e ci siano un centinaio di giocatori le aree sarebbero sempre tutte caricate, quindi di base DEVE funzionare perfettametne con tutto caricato, poi, eventualmente si può alleggerire.
Comunque vale sempre il discorso fatto altrove, il serve deve essere leggero e gestire le cose non immagazzinare dati. Quindi un server non deve avere problemi di ram, ma solo problemi di calcolo.
Ribadisco con estrema certezza che coffemud va bene solo per fare un clone di quel mud, altrimenti è meglio partire da altro senza ombra di dubbio. Sempre confutabile eh questa affermazione...

JJ

Nickewen ha scritto:e giusto per una maggiore precisazione. Molte aree , se non vengono usate, non vengono neanche caricate in RAM (cosi' non consumano nulla). Dipende tutto da come lo si imposta.

Un appunto su questo, circle smaug ecc... fanno la stessa cosa e non serve assolutamente a nulla se non ad avere un rallentamento la prima volta che uno mette piede in un'area.

JJ

Jumping Jack ha scritto:

Nickewen ha scritto:e giusto per una maggiore precisazione. Molte aree , se non vengono usate, non vengono neanche caricate in RAM (cosi' non consumano nulla). Dipende tutto da come lo si imposta.

Un appunto su questo, circle smaug ecc... fanno la stessa cosa e non serve assolutamente a nulla se non ad avere un rallentamento la prima volta che uno mette piede in un'area.

JJ

io jj resto dell'idea se ci va e se ci torna utile di utilizzare le basi di configurazione di coffee mud e poi programmare il "nostro mud", primo perche coffee mud è pensato per "1" mud e non per gestire tanti mud, secondo perche cmq se affronteremo il discorso delle sponsorizzazioni (cosa che voglio assolutamente portare avanti) è consigliabile avere quantomeno un gioco "originale".

Jumping Jack ha scritto:

Sito ha scritto:Salve a tutti,
scusa se mi intrometto nella discussione ma è solo per fare un appunto.
CoffeeMUD ha un sacco di impostazioni strane e il tempo di caricamento dell'area è direttamente legato al DB che hai scelto e come lo hai impostato.
Se avete fatto i benchmark con il default stava quasi sicuramente usando il fakedb che ha delle prestazioni veramente misere...
Il problema maggiore di CoffeeMUD è che carica tutto in RAM per cui su aree molto trafficate si mette a consumare un sacco di memoria.

Sito

Si, ho usato il fakedb, vedrò di rifare il caricamento delle aree con un'altro db.
Il fatto che carichi tutto in ram non è il problema maggiore... DEVE caricare tutto in ram, non è accettabile che il serve abbia dei rallentamenti di caricamento, mai. Anche perchè nell'ipotesi che il mud diventi florido e ci siano un centinaio di giocatori le aree sarebbero sempre tutte caricate, quindi di base DEVE funzionare perfettametne con tutto caricato, poi, eventualmente si può alleggerire.
Comunque vale sempre il discorso fatto altrove, il serve deve essere leggero e gestire le cose non immagazzinare dati. Quindi un server non deve avere problemi di ram, ma solo problemi di calcolo.
Ribadisco con estrema certezza che coffemud va bene solo per fare un clone di quel mud, altrimenti è meglio partire da altro senza ombra di dubbio. Sempre confutabile eh questa affermazione...

JJ

Il mio era solo un appunto perche' un po con CoffeeMUD ho smanettato e la sua configurabilita' a volte e' un arma a doppio taglio.
Dall'esterno secondo me fate bene a ripartire da 0, perche' modificare CoffeeMUD rischia di creare piu' problemi di quanti ne risolve.

Sito

Il fatto che carichi tutto in ram non è il problema maggiore... DEVE caricare tutto in ram, non è accettabile che il serve abbia dei rallentamenti di caricamento, mai. Anche perchè nell'ipotesi che il mud diventi florido e ci siano un centinaio di giocatori le aree sarebbero sempre tutte caricate, quindi di base DEVE funzionare perfettametne con tutto caricato, poi, eventualmente si può alleggerire.

Su questo non sono molto d'accordo. Perchè non creare un sistema di Cache per le locazioni della mappa?
Ovviamente bisogna valutare la situazione in base ad i numeri che si hanno di fronte.
Ovvio che se ho 10 caselle, mi conviene caricarle tutte in RAM.
Non altrettanto se il mondo ne dispone di 10000 dove solo il 5% viene utilizzato in un momento generico e solamente l'1-2% necessita di essere utilizzato sempre.
(Parlo per esperienza personale: In qualche mud che ho frequentato, capita di giocare quasi sempre nelle stesse locazioni, a meno di non mettersi a viaggiare)

Lo vedo uno spreco di risorse caricare tutto quando solamente una piccola percentuale viene presa in considerazione.

Poi ovviamente è da valutare bene, ma non escluderei a priori determinate soluzioni.

Jumping Jack ha scritto:In ogni caso se si vuole implementare un sistema multi mud, quindi con meccaniche diverse ma db in comune, coffee mud è assolutamente inadatto.

Sul punto del multi-mud: se l'idea è quella di avere un unico mega-engine in grado di far funzionare numerosi MUD contemporaneamente, allora la sconsiglio: se "cade" il processo del mega-engine si spengono tutti i MUD; forse conviene avere numerose copie (istanze) dello stesso engine (classe) le quali si differenziano per la loro configurazione iniziale (setup).
Inoltre, l'idea di avere un unico istanza di DB in esecuzione va ancora bene: normalmente un database dovrebbe essere più stabile di un MUD.
In ogni caso, sia con un mega-engine sia con delle istanze multiple dell'engine, ciascun MUD dovrebbe usare una connessione al DB dedicata per ciascun MUD.

Jumping Jack ha scritto:Ora bisogna decidere cosa fare, se partire con il progetto di fare un mud interessante e parzialmente versatile (the keeper mud) oppure un sistema totalmente nuovo completamente personalizzabile senza dover toccare il codice (the keeper core).
La strada che seguirei la cercherei in base a chi è interessato a questo sviluppo, sopratto all'interesse dei coder. E soprattutto valutando la difficoltà TKM è facile ma per nulla breve, TKC è estremamente difficile.

Vorrei tentare di estendere l'engine del MUD che ho scritto in Perl in modo da tentare di far funzionare tale engine in modalità mega-engine...

M.