D3DRM.dll
 

Ciao a tutti, sono " nuovo " e in attesa che arriva il mio eli, volevo imparare con un simulatore.
Ho preso questo
http://cgi.ebay.it/ws/eBayISAPI.dll?...m=280151916679

Il problema è che mi dice che manca D3DRM.dll e devo scaricarlo in c/windows/system32
Purtroppo, lo scarico ma non riesco a installarlo e esce questo messaggio : NON SI DISPONE DELLE AUTORIZZAZIONI NECESSARIE PER SALVARE I DATI IN QUESTO PERCORSO.
PER OTTENERE LE NECESSARIE AUTORIZZAZIONI CONTATTARE L' AMMINISTRATORE.
Cosa devo fare ? il mio sistema operativo è un Vista

Grazie per l' aiuto !!!

Ciao, quel messaggio significa che non sei l'amministratore del sistema, per cui non hai i permessi per scrivere nella cartella di sistema che contiene le dll (librerie a collegamento dinamico).

I casi sono due:

1) il computer non è tuo, ma di un altro utente o di una rete aziendale e devi chiamare l'amministratore per farti installare la libreria

2) il computer è tuo, ma il sistema operativo ti è stato installato in negozio o da terzi e non ti è stata data la password dell'amministratore.

fammi sapere il tuo caso.

saluti
Andrea

Caso 3:
Hai Windows Vista..... :fiu:

se vai nel pannello di controllo (dopo esserti loggato come utente aministratore) puoi disabilitare momentaneamente il sistema di protezione di Windows. Copi il file nella cartella e poi riattivi.

Ciao

ciao, io sono utente amministratore......ma andando nel pannello di controllo, puoi spiegarmi meglio come disabilitare momentaneamente il sistema di protezione di Windows ? non so cosa devo fare .....:blink: :wacko:
Grazie !!!!!

dunque se non sei amministratore e non vuoii combinare casini con Windows Vista ti consiglio di utilizzare il vecchio metodo di Administrator,cioè antrare con il pc in modalità provvisoria,andare in administrator e abilitarti come admin totale,in modo che successivamente non avrai problemiB)

C'è un altro metodo più semplice: metti la dll nello stesso percorso dell'eseguibile del simulatore. Quella è sempre la prima cartella in cui un programma cerca una dll!
Non è il metodo migliore, ma almeno funziona! :)

Grazie che mi aiutate !!!
ieri non sono riuscito ......:angry:
Puoi spiegarmi meglio cosa devo fare ? sono un po' negato con il pc:unsure:

sono riuscito !!!!!
Grazie per i vostri consigli !:wink: :D :)
ciao

Si,certo ma poi il problema potrebbe porsi con altre applicazioni dato che è un file di directx-_-

ciò che affermi non è del tutto vero ma corrisponde al vero nel 99% dei casi e ciò che conta e far andare il trabicolo:lol:

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!

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

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:icon_rofl


saluti
Andrea

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ò:icon_rofl.

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

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

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

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!

Mollare? ora che ho trovato un altro matto come me? non ci penso prorpio.

Per quanto riguarda gli esami non ti preoccupare, anch'io ho un mare di cose da fare, e il bello dell'OS è che siccome non ti paga nessuno possimo prenderlo con calma, la differenza la fa il fatto che abbia grip sugli altri oppure no :).

Invece per quanto riguarda le lib grafiche mi pare bene che cominci da li, io potei dare un occhaita a quelle fisiche.

Per quanto riguarda la fisica dei simulatori di volo, avendone provati un po mi sono reso conto di quanto segue.

1) l'approccio + realistico è quello che si basa su un calcolo su elementi finiti di alcune equazioni di fluidodinamica sub e supersonica. Questo è l'approccio che si usa nella progettazione degli aerei prima di testare in galleria del vento e l'unico gioco che sfrutta tali finezze è XPlane che infatti ha un volo molto realistico.

Gli altri simulatori di solito usano equazioni semplificate dove in base a parametri + o meno noti per i vari modelli, realizzano una fisica fittizia di simulazione che nulla a che fare con la reale forma dell'oggetto.

Per capirsi, in microsoft flight sim metto i parametri di un f16 su una palla da bowling, quella volerà come un f16, su XPlane invece non metto i parametri, metto la forma della palla' il suo peso ecc.. e volerà come una palla da bowling (cioè male :) ).

Ora, io non so cosa ne pensi, ma nell'ottica di avere qualcosa da utilizzare presto per allenarsi gratis, forse l'approccio meno nobile dei parametri è + indicato di quello puro della fluidodinamica...

Però se la pensi diversamente possiamo pensare anche all'approccio iperrealiastico, magari contattando qualcuno addetto al mestiere di progettazione degli aerei che bazzica qui sul forum.

Fammi sapere

saluti
ANdrea

La cosa bella delle Ode? Tu puoi dire: prendi un oggetto fatto così con questo peso, collegaci in modo fisso (senza cerniere) un altro oggetto fatto coì, di quent'altro peso e lui lo vede come un corpo solo di peso p1+p2, e col baricentro in base alla forma e al peso dei due elementi! Su questo, quindi, è abbastanza buono. Per contro, gestisce solo sfere, cubi e "capsule". Può disegnare e calcolare anche le collisioni di una mesh di triangoli (un classico modello poligonale..), ma non so come gestisca la sua dinamica in movimento! Su questo c'è da provare! Peccato che l'Havok Engine sia a pagamento anche per uso personale..