20 novembre 07, 02:22 | #11 (permalink) Top | |
User | Citazione:
Capisco anche che sia un file dx, la soluzione alternativa, potrebbe essere di scaricare l'ultima release DX e installarle. Magari qualche altra applicazione ha eliminato quel file. PS2: cmq, se apri windows/system32 e fai incolla, ti chiede i diritti per copiare il file! é impossibile che non te li chieda! | |
20 novembre 07, 02:39 | #12 (permalink) Top | |
User Data registr.: 10-09-2007 Residenza: trieste
Messaggi: 264
| Citazione:
Non esistono solo le MFC di windows ma anche un codice di + basso livello, o applicativi scritti in altri linguaggi. In java una dll può essere caricata da sys32 ma anche da una precisa directory, cito testualmente: There are two different ways to load a native library into a running Java program: System.loadLibrary(String) and System.load(String). The System.loadLibrary method allows us to load a library from the "default" path. System.load allows us to load a library from anywhere via its absolute path. e in un programma interpretato qual'è la directory del programma? Quella dell'interprete o quella del file di comandi. Nel software ci sono raramente punti divista assoluti e la parola SEMPRE si può usare assai di rado. Saluti Andrea
__________________ La natura non può essere ingannata. (Richard Feynman) | |
20 novembre 07, 03:15 | #13 (permalink) Top | |
User Data registr.: 10-09-2007 Residenza: trieste
Messaggi: 264
| Citazione:
HMODULE WINAPI LoadLibraryEx( __in LPCTSTR lpFileName, __reserved HANDLE hFile, __in DWORD dwFlags ); dove lpFileName cito testualmente: The name of the executable module (either a .dll or an .exe file). This name is the file name of the executable module; it is not related to the name stored in a library module itself, as specified by the LIBRARY keyword in the module-definition (.def) file. If the string specifies a path, but the file does not exist in the specified directory, the function fails. When specifying a path, be sure to use backslashes (\), not forward slashes (/). If the string does not specify a path, and the file name extension is omitted, the function appends the default library extension .dll to the file name. However, the file name string can include a trailing point character (.) to indicate that the module name has no extension. If the string does not specify a path, the function uses a standard search strategy to find the file. See the Remarks for more information. If mapping the specified module into the address space causes the system to map in other, associated executable modules, the function can use either the standard search strategy or an alternate search strategy to find those modules. See the Remarks for more information. Quindi come vedi lo sviluppatore ha perfettamente la possibilità di caricare una dll solo se si trova dove + lo aggrada. Caricare da sys32 o da . è solo una convenzione perchè i programmatori sono PIGRI!!1 saluti Andrea
__________________ La natura non può essere ingannata. (Richard Feynman) | |
20 novembre 07, 11:16 | #14 (permalink) Top |
User |
D'accordissimo che non esistono solo le MFC (mai usate, programmo piccoli videogiochi con Visual Studio, non RPGmaker e simili), e infatti il mio discorso vale anche per gli altri applicativi! Il discorso che fai tu è valido se usi il LoadLibraryEx (extern), ma in un programma normalmente, le librerie vengono auto incluse utilizzando la direttiva #include <nome_h.h>, dopo aver opportunatamente impostato le directory dei file di inclusione nelle proprietà del progetto. Fatto ciò, il programma cerca, cmq, prima nella directory in cui si trova l'eseguibile. Serve apposta per far sì che i programmatori evitino il più possibile di mettere dll a caso nelle directory di sistema. Sarò "limitato" io, ma da quando programmo (10 anni circa), non ho mia avuto il bisogno del LoadLibraryEx..al max uso il #pragma comment(lib,"nomelib.lib"). E anche "nomelib.lib" non importa che sia un riferimento assoluto, se hai impostato correttamente le directory delle lib, sempre nelle proprietà del progetto! Per quanto riguarda Java..non lo prendo neanche in considerazione, dopo vari test (e una tesi di laurea di un paio di miei compagni), il risultato è stato che impiega mediamente il 30% in più per l'esecuzione dello stesso programma. Preferisco "sbattermi" un pochino di più, ma avere maggior efficienza! |
20 novembre 07, 15:06 | #15 (permalink) Top | |
User Data registr.: 10-09-2007 Residenza: trieste
Messaggi: 264
| Citazione:
Io infatti ho affermato fin da subito che nel 99% dei casi è come dici tu. Ho solo contrastato l'utilizzo del termine ASSOLUTAMENTE (scritto in maiuscolo) per puntualizzare che non è una situazione necessaria, ma solo una convenzione molto usata. In quanto laureato in fisica so che la parola assolutamente dovrebbe essere tolta dal linguaggio scientifico! Sono felice che programmi da 10 anni, spero non solo su winsoz però. Se così non fosse allora potresti appoggiarmi nella mia proposta di fondare un progetto open source per la realizzazione di un sumulatore di volo rc, così la gente potrà smettere di lottare con interfacce hardware di controllo e altro. Saluti Andrea
__________________ La natura non può essere ingannata. (Richard Feynman) | |
21 novembre 07, 13:11 | #16 (permalink) Top |
User |
So Linux ho programmato poco, però (diciamoci la verità), le differenze sono davvero minime in termini di programmazione! Forse forse, mi piace di più la gestione dei thread di Win, rispetto al fork() di Linux, ma sono gusti miei personali! Sul simulatore rc..in effetti ci stavo pensando anch'io! Io uso middleware freeware quali Ogre, ODE e openAL. Il vantaggio di questi tools è che sono indipendenti dalla piattaforma! Poi, date le tue conoscenze in fisica, si potrebbero eliminare le ODE, ma credo che sarebbe più utile farlo in un secondo momento, una volta sicuri che tutto il resto funzioni! Bisognerebbe, però, reclutare altra gente..in due lo si porta avanti per anni! |
22 novembre 07, 02:33 | #17 (permalink) Top | |
User Data registr.: 10-09-2007 Residenza: trieste
Messaggi: 264
| Citazione:
Mi fa molto piacere vedere che già conosci il dominio del problema! Io non ho mai programmato giochi se non cosine personali estremamente idiote, ma mi occupo di software gestionale o di calcolo scientifico. Se tu già conosci le problematiche dello sviluppo di videogiochi potremmo effettivamente raggiungere risultati interessanti in un tempo ragionevole. Concordo con te sulla necesità di trovare altri partecipanti al progetto, ma per farlo partire bastiamo anche noi, poi se la cosa ingrana le gente arriva, te lo assicuro. Per quanto rigurada rifare l'ode non credo sia necessario, per quanto io sia un fisico non credo che potrei da solo fare meglio di quanto già c'e'. Al limite se è tutto open si può ritoccare quà e la se ci servono features particolari non ancora presenti. Il riutilizzo prima di tutto. Invece vorrei dare al progetto uno stampo il più possibile open, cioè sorgenti aperti, configurazioni aperte assolutamente multipiattaforma Linux/mac/winsoz ecc... Fammi sapere che ne pensi e se secondo te le lib che mi hai elencato supportano i requisiti. Saluti Andrea
__________________ La natura non può essere ingannata. (Richard Feynman) | |
22 novembre 07, 17:50 | #18 (permalink) Top |
User |
Tutti i tools che ho elencato sono multipiattaforma e tutti supportano sia Win, sia Linux e MacOS. Alcuni, addirittura supportano Sun, XBox, X360, PS3, quindi ci sarebbe spazio per tutto! Sicuramente l'Ogre eviterei di modificarlo..è davvero ben realizzato ed efficiente. Le Ode sono un pochino incasinate e soffrono delle varie approssimazioni (se metti due sfere ESATTAMENTE l'una sull'altra, restano in equilibrio..ma è una cosa che capita molto di rado in un mondo dinamico!), per contro, ora godono del pieno supporto dell'Ogre (fino a due versioni fa dovevi farti il porting..una grana assurda!). Per quanto riguarda openAL, sono librerie audio discretamente buona, con supporto pieno al Dolby (mi sembra fino al 7.1). Quindi, con questi tools, dovremmo essere subito pronti a partire! Un altro vantaggio delle ode è che tu gli dici: prendi questo pezzo fatto così, attacca questo qui fatto cosà (ad esempio fusoliera+ali) e lui da solo te lo gestisce come un corpo unico, calcolandone baricentro e fisica! Sul discorso free: siamo obbligati! Uno perchè così chiunque può contribuire a darci una mano, due perchè le licenze commericali hanno costi parecchio elevati! Diciamo, cmq, che realizzare qualcosa tipo FMS, sarebbe già un buon traguardo..bisogna partire da un progetto "semplice" e poi evolvere, se no si finisce per deprimersi e lasciare le cose a metà.. Tu su cosa programmi? Linux o Win? |
28 novembre 07, 14:52 | #19 (permalink) Top | |
User Data registr.: 10-09-2007 Residenza: trieste
Messaggi: 264
| Citazione:
Quoto tutto quello che hai detto e direi che potermmo cominciare a decidere dove pubblicare il progetto. IO ho programmato su windows fino al com e prima di dot net in c/c++ ho programmato in c su linux , ma da qualche anno programmo quasi esclusivamente in java. Ma questo no è un problema, i linguaggi non sono poi così diversi e riesco a lavorare bene un po' con tutti. Fammi sapere come vuoi ch eprocediamo, saluti, Andrea
__________________ La natura non può essere ingannata. (Richard Feynman) | |
29 novembre 07, 01:12 | #20 (permalink) Top |
User |
Pensavo avessi già abbandonato l'idea! In questi giorni sono preso dagli esami universitari, ma al più tardi verso Natale volevo mettermi a studiare l'Ogre (quello che sarà il motore grafico), così da riuscire a disegnare qualcosa su schermo in modo decente, e la sua integrazione con le ODE (le librerie fisiche..delle quali è appena uscita la versione 0.9.quella precedente risaliva a 3 anni fa!). Queste ultime le ho appena compilate sotto win e..sono piene di warning, ma di errori no (strano..di solito qualche errorino salta sempre fuori!). A voler essere pignoli, si potrebbero limare i warning con i giusti cast, ma tanto funziona ugualmente.. Per quanto riguarda l'audio, non lo considererei fino a circa metà del lavoro! Volevo più che altro iniziare a disegnare qualcosa di simile a due assi unite da una "cerniera", "lanciarla" e muovere la giunzione, così da vedere se l'effetto alettone (o elevatore) funziona già di suo. E, successivamente, di realizzare una pseudo-elica e vedere se facendola girare, da o meno la spinta propulsiva. Altrimenti, se dovessimo farci le routine fisiche, diverrebbe alquanto innaturale, a meno di calcoli discretamente complicati e pesantezza del software! Nel caso non funzionassero..cercherò qualche altra libreria free (sotto licenza GPL, ovviamente) da utilizzare! Per la pubblicazione..io ho un forum di programmazione..non è molto frequentato, ma potremmo postarci lì le informazioni, gli aggiornamenti, i sorgenti e le varie versioni intermedie funzionanti. Se vuoi, inizia a dare un'occhiata ai vari tools, così mi dici cosa ne pensi! I link sono http://www.ogre3d.org, www.ode.org e http://www.openal.org. Il sito meglio realizzato è quello di Ogre, con screenshots e demo di quello che può fare! |
Bookmarks |
| |