spieleprogrammierer.de

Hi Vison,

scheint so, als ob du vergessen hättest, die DX-Libraries im Release zu linken.

Jo füg mal irgendwo im Code folgendes ein:


Dann dürfte es gehen.

Hallo zusammen

Vielen dank erstmal für die schnellen antworten.
Aber leider ändert sich nichts.

Hier mal eine liste mit allen gelinkten libs
d3d9.lib
d3dx9.lib
dinput8.lib
dsound.lib
strmiids.lib
strmbase.lib
dxerr.lib
dxguid.lib
winmm.lib
kernel32.lib
user32.lib
gdi32.lib
winspool.lib
comctl32.lib
comdlg32.lib
advapi32.lib
shell32.lib
ole32.lib
oleaut32.lib
uuid.lib

ich verwende das DirectX SDk vom February 2010

mfg Vison


Ok also hat sich erledigt hab denn fehler gefunden. hatte von nem früheren projekt noch die x64 variante der libs in den projekt settings muss aber die x86 version sein für 32 bit systeme.

Falsche
D:\Program Files (x86)\Microsoft DirectX SDK (February 2010)\Lib\x64
Richtige
D:\Program Files (x86)\Microsoft DirectX SDK (February 2010)\Lib\x86

ps. vielen dank nochmal.

Mein Problem hat sich auch endlich gelöst, lag nicht am Cuda-Code sondern an die Einstellungen des Projektes, das er halt von Standardprojekten die Libs erbt.
Ich finde diese Einstellung eh etwas fragwürdig.

Hey,

ich versuche gerade die BaseClasses zu kompilieren bekomme aber folgende Fehlermeldung.

1> wxdebug.cpp
1>wxdebug.cpp(11): warning C4603: '_WINDLL' : macro is not defined or definition is different after precompiled header use
1> Add macro to precompiled header instead of defining here
1> wxdebug.cpp(13) : use of precompiled header
1> wxlist.cpp
1> wxutil.cpp
1>D:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(1151,5): warning MSB8012: TargetPath(C:\DEV\TriBase_VS_2010\Include\DShowBaseClasses\.\Release\BaseClasses.lib) does not match the Library's OutputFile property value (C:\DEV\TriBase_VS_2010\Include\DShowBaseClasses\Release\STRMBASE.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1>D:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(1153,5): warning MSB8012: TargetName(BaseClasses) does not match the Library's OutputFile property value (STRMBASE). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1> BaseClasses 2005.vcxproj -> C:\DEV\TriBase_VS_2010\Include\DShowBaseClasses\.\Release\BaseClasses.lib
1> The system cannot find the file specified.
1>D:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "COPY .\Release\BaseClasses.lib ..\..\Lib\StrmBase.lib
1>D:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 1.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

hat jemand eine Idee woran das liegen könnte?

Grüße,
oc1d

Da scheinen Build-Event-Befehle veraltet zu sein. Dazu schau bei den Projekteigenschaften mal unter Build Events -> Post-Build Event
Könnte sein, dass sich das bereits löst wenn du "COPY" mit "copy" ersetzt. Hier hab ich noch was gefunden, was womöglich von belang sein könnte.
Im Zweifelsfall deaktivierst du die Build-Events und führst das was sie machen manuell durch.

Hey! Danke für die schnelle Antwort.

Denke aber, dass es wohl an den Warnings zuvor liegt. Das erstzen hat nichts gebracht.

Also falls man den bei Postbuildereignisse zu COPY $(OutDir)strmbasd.lib ..\..\Lib\StrmBaseD.lib ändert, geht das ganze. Es kommen aber noch mehr Warnungen.

PS: Falls man bei den Eigenschaften: C++ -> Allgemein -> Kompillierung mit mehreren Prozessoren auf Ja stellt, geht es bei den Modernen Mehrkern-Prozessoren schneller.
PS2: Postbuildereignisse vom Tribase Engine sollten nicht unbedingt die dll in System32 kopieren, falls man nur als Benutzer arbeitet. Besser manuell rüberkopieren und die Zeile entfernen. [Habe inzwischen herausgefunden, dass das egal ist, VS 2010 merkt das und bringt nur eine Warnung]

Edit3:
habe eine bessere Lösung gefunden. Falls man im Bibliothekar unter Allgemein bei der Ausgabedatei folgendes eingibt, klappt alles ohne Warnungen:
debug\$(TargetFileName)
Wäre froh, falls das mal einer Testen würde, da ich bei mir in der Zwischenzeit sehr viele Einstellungen geändert habe. (Habe eben lange rumprobiert.)
Für Release muss man das ganze entsprechend schreiben.
Als ich vorkompillierte Header benutzt habe, kamen einige Warnungen, deshalb habe ich die momentan auch ausgeschaltet.

Beim Kompilieren von Tribase tritt aber noch folgender Fehler auf, obwohl das Includeverzeichnis angegeben ist beim Resourcencompiler
Res\Resource.rc(11): fatal error RC1015: cannot open include file 'mfc/afxres.h'.
Mit dem ProcessMonitor fand ich heraus, dass die Datei gar nicht an der Stelle gesucht wird, die ich angegeben habe.

Eine kleine Lösung habe ich auch hier nun gefunden:
In den Projekteigenschaften unter VC++-Verzeichnisse bei Includeverzeichnissen einfach noch den Pfad zum Includeverzeichnis des Platform SDK's eintragen, danach findet er auch in der Resource die Datei.

@ChrisvA ich denke ich kann dir relativ bald sagen ob deine Lösung funktioniert, aber vorher hab ich noch ne Frage in eigener Sache.

hier:
Lösung: TriBase und Visual C++ 2005/2008 Express
wird beschrieben, dass man diese libs:
kernel32.lib user32.lib gdi32.lib winspool.lib comctl32.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib
hinzufügen soll.

Wo mach ich das denn im VS2010?

Gruß Cy

Projekteigenschaften: -> Konfigurationseigenschaften -> Linker -> Eingabe -> Zusätzliche abhängigkeiten.

moin moin!

Dann hab ich ja eigentlich an der richtigen Stelle gesucht...
Aber schau mal, bei mir ist da nichts!?


Servus

ja... diese übersetzungswut ist schrecklich. es wird einfach alles übersetzt was geht xD
der bibliothekar dürfte der linker sein

ein wunder dass die nicht debuger übersetzt haben(entkäferer? XD)

-_- fast schon zu einfach...

Hätte es mir von dein Feldern her eigentlich denken sollen.

Dank dir!