spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Mir würde spontan kein Prozessorkern einfallen der Hardwareseitiges Multithreading bietet
Höchstens das man auf einen reallen Prozessorkern 2 Prozesse laufen kann, was sich aber Hyper Threading bzw Simultanioues Multithreading nennt, dabei entstehen aus einem reallen Prozessor 2 virteulle Prozessoren, diese werden aber vom Betriebssystem verwaltet und nicht vom Nutzer und dürften bei solch einer Anwendung auch nicht wirklich für höhere Geschwindigkeit sorgen, da ja nicht wirklich 2 Prozessorkerne vorliegen, sondern ledicglich die Registersätze verdopplet werden, das wenn Piplienstufen nicht vom ersten Prozess genutzt werden, sie vom 2ten Prozess genutzt werden können
Und wenn der einzige Unterschied im Multithreading besteht, das kann man unter net auch auf einfacherem besser steuerbarem Wege erreichen, erfordert halt etwas Arbeit vom Programmierer, dafür ist das verhalten aber besser vorhersagbar

Tja... Programm erhalten. Mein Game damit gepackt. Gestarted und... beim Startup abgestürzt.

Nach dieser Pleite habe ich das beiliegende und ungepackte Test-Programm gestartet, dort auf den "Start-Button" für den Zähler gedrückt, das Programm geschlossen, aber... der Prozess lief weiterhin im Hintergrund und ich musste ihn über den Task-Manager abschießen. Das gepackte Beispielprogramm habe ich daraufhin gar nicht erst probiert.

Zitat von »BlueCobold«

Tja... Programm erhalten. Mein Game damit gepackt. Gestarted und... beim Startup abgestürzt.

q.e.d.

Zitat von »3Angle«

Das liegt an den Projektabhängigkeiten, ob es crasht oder nicht.

Was soll das heißen?

Zitat von »3Angle«

Das Testprogramm war ein 1 Minutenprojekt, damit sich der Unpacker schließt muss man das Programm per Application.Exit() oder End schließen!

Was bei Deinem Test-Programm offenbar nicht passiert, wenn man auf das X rechts oben drückt - was auf ehrlich gesagt sehr schlechte Kenntnisse oder Pfuscherei hindeutet. Den Eindruck hatte ich beim Packer übrigens ebenfalls, eine manuelle Eingabe eines Dateipfads statt einem FileOpenDialog ist schon sehr... "dirty"... um höflich zu sein.

Hm das dein Programm andere .NET Programme dazu zwingt sich im MTA Modus auszuführen finde ich interessant.
Ich frag mich gerade echt warum Microsoft darauf besteht Windows Forms Applikationen explizit mit STA zu flaggen...

http://msdn.microsoft.com/de-de/library/…1(v=vs.80).aspx

Zitat von »http://msdn.microsoft.com/de-de/library/system.mtathreadattribute(v=vs.80).aspx«

COM-Threadingmodelle betreffen nur Anwendungen, die COM-Interop verwenden. Das Verwenden dieses Attributs in einer Anwendung, die COM-Interop nicht verwendet, hat keine Auswirkungen.

Zitat von »Jeason«

Hm das dein Programm andere .NET Programme dazu zwingt sich im MTA Modus auszuführen finde ich interessant.
Ich frag mich gerade echt warum Microsoft darauf besteht Windows Forms Applikationen explizit mit STA zu flaggen...

http://msdn.microsoft.com/de-de/library/…1(v=vs.80).aspx

Weil Windows Forms eigentlich nur ein besserer Wrapper um die alte Win32 API ist und die mit mehreren Threads sehr schlecht umgehen kann.