Torna indietro   BaroneRosso.it - Forum Modellismo > Categoria Software > Simulatori


Rispondi
 
Strumenti discussione Visualizzazione
Vecchio 20 novembre 07, 02:22   #11 (permalink)  Top
User
 
Data registr.: 04-10-2007
Residenza: Vercelli
Messaggi: 251
Invia un messaggio via Yahoo a TheFoggy
Citazione:
Originalmente inviato da andrex71
ciò che affermi non è del tutto vero ma corrisponde al vero nel 99% dei casi e ciò che conta e far andare il trabicolo

saluti
Andrea
La directory in cui c'è l'eseguibile è SEMPRE la prima directory in cui un eseguibile cerca una dll. A meno di cambiare la directory di lavoro..ma per farlo devi cambiare le impostazioni del collegamento da cui lo lanci..in pratica se metti la dll nella cartella dell'exe funziona!

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!
TheFoggy non è collegato   Rispondi citando
Vecchio 20 novembre 07, 02:39   #12 (permalink)  Top
User
 
L'avatar di andrex71
 
Data registr.: 10-09-2007
Residenza: trieste
Messaggi: 264
Citazione:
Originalmente inviato da TheFoggy
...è SEMPRE la prima directory in cui un eseguibile...
l'eseguibile fa solo ciò che un programmatore ha scritto, e se viene richiesto un caricamento di una dll da una specifica directory ecco che quanto affermi non è più vero.

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)
andrex71 non è collegato   Rispondi citando
Vecchio 20 novembre 07, 03:15   #13 (permalink)  Top
User
 
L'avatar di andrex71
 
Data registr.: 10-09-2007
Residenza: trieste
Messaggi: 264
Citazione:
Originalmente inviato da TheFoggy
La directory in cui c'è l'eseguibile è SEMPRE la prima directory in cui un eseguibile cerca una dll. A meno di cambiare la directory di lavoro..ma per farlo devi cambiare le impostazioni del collegamento da cui lo lanci..in pratica se metti la dll nella cartella dell'exe funziona!

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!
anzi dirò di più, la normale chiamata alle Windows API è della forma:

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)
andrex71 non è collegato   Rispondi citando
Vecchio 20 novembre 07, 11:16   #14 (permalink)  Top
User
 
Data registr.: 04-10-2007
Residenza: Vercelli
Messaggi: 251
Invia un messaggio via Yahoo a TheFoggy
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!
TheFoggy non è collegato   Rispondi citando
Vecchio 20 novembre 07, 15:06   #15 (permalink)  Top
User
 
L'avatar di andrex71
 
Data registr.: 10-09-2007
Residenza: trieste
Messaggi: 264
Citazione:
Originalmente inviato da TheFoggy
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!
E' assolutamente giusto ciò che dici, soprattutto nella programmazione di winsoz che si basa (purtroppo) sun vasto uso di pragma.

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)
andrex71 non è collegato   Rispondi citando
Vecchio 21 novembre 07, 13:11   #16 (permalink)  Top
User
 
Data registr.: 04-10-2007
Residenza: Vercelli
Messaggi: 251
Invia un messaggio via Yahoo a TheFoggy
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!
TheFoggy non è collegato   Rispondi citando
Vecchio 22 novembre 07, 02:33   #17 (permalink)  Top
User
 
L'avatar di andrex71
 
Data registr.: 10-09-2007
Residenza: trieste
Messaggi: 264
Citazione:
Originalmente inviato da TheFoggy
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!
FANTASTICO!

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)
andrex71 non è collegato   Rispondi citando
Vecchio 22 novembre 07, 17:50   #18 (permalink)  Top
User
 
Data registr.: 04-10-2007
Residenza: Vercelli
Messaggi: 251
Invia un messaggio via Yahoo a TheFoggy
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?
TheFoggy non è collegato   Rispondi citando
Vecchio 28 novembre 07, 14:52   #19 (permalink)  Top
User
 
L'avatar di andrex71
 
Data registr.: 10-09-2007
Residenza: trieste
Messaggi: 264
Citazione:
Originalmente inviato da TheFoggy
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?
Scusa il ritardo, ma aspettavo la notifica di risporta dal barone e non è arrivata la mail, così oggi ho dato un'occhiata e ho viisto che avevi risposto.

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)
andrex71 non è collegato   Rispondi citando
Vecchio 29 novembre 07, 01:12   #20 (permalink)  Top
User
 
Data registr.: 04-10-2007
Residenza: Vercelli
Messaggi: 251
Invia un messaggio via Yahoo a TheFoggy
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!
TheFoggy non è collegato   Rispondi citando
Rispondi

Bookmarks




Regole di scrittura
Non puoi creare nuove discussioni
Non puoi rispondere alle discussioni
Non puoi inserire allegati
Non puoi modificare i tuoi messaggi

BB code è Attivato
Le faccine sono Attivato
Il codice [IMG] è Attivato
Il codice HTML è Disattivato
Trackbacks è Disattivato
Pingbacks è Disattivato
Refbacks è Disattivato




Tutti gli orari sono GMT +2. Adesso sono le 02:23.


Basato su: vBulletin versione 3.8.11
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
E' vietata la riproduzione, anche solo in parte, di contenuti e grafica. Copyright 1998/2019 - K-Bits P.I. 09395831002