wie meinst du das, das wollte ich ja eigendlich wissen ob am eine Berechnung die ca. 2s dauert so als Thread machen kann das das Hauptprogramm ohne stocken weiter läuft ?Macros hat geschrieben:Genau parallel, aber die Rechenleistung deines Computers erhöht sich nicht.
DUNE 2077
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
das heißt es hat überhaupt keinen zweck oder wenig, wenn die die komplette Wegberechnung als Tread laufen lasse.Macros hat geschrieben:Wenn du rechenleistungsintensive Aufgaben im Tread erledigen lässt,
wirkt sich dass auch auf dein Hauptprogramm aus.
Ich habe es nämlich schon umprogrammiert und es wurde ehr noch langsammer

PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
- NicTheQuick
- Ein Admin
- Beiträge: 8807
- Registriert: 29.08.2004 20:20
- Computerausstattung: Ryzen 7 5800X, 64 GB DDR4-3200
Ubuntu 24.04.2 LTS
GeForce RTX 3080 Ti - Wohnort: Saarbrücken
das heißt es hat überhaupt keinen zweck oder wenig, wenn die die komplette Wegberechnung als Tread laufen lasse
Ich habe es nämlich schon umprogrammiert und es wurde ehr noch langsammer
Also eigentlich sollte es nicht wesentlich langsamer sein. Schneller wird es aber natürlich nur, wenn Du mehr als einen Prozessor (core) zur Verfügung hast.
Die Wegberechnung als extra Thread laufen zu lassen finde ich sogar eine sehr gute Idee.

Du könntest sogar die komplette KI in einem extra Thread laufen lassen. Es ist doch gar nicht notwendig, dass das Programm auf die Entscheidung einer einzelnen Einheit wartet. Die überlegt dann halt einen kurzen Augenblick.

Damit könntest Du sehr einfach erreichen, dass das Programm mit konstanten fps durchläuft, und nicht immer wieder stockt. Ok, bei nem RTS ist das nicht ganz so wichtig wie bei Spielen in EGO-Perspektive, aber dennoch schön zu haben.

aha gut danke für eure Hinweise 

PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Also erstmal: echt Klasse, was Du da auf die Beine gestellt hast. Ich hab selbst schon mal angefangen ein RTS zu basteln. Hab's aber wegen Zeitmangel und Freundin (Zitat:"Du sitzt ja den ganzen Tag nur vor'm Rechner...bla") abgebrochen. Meins war Hexagonal aufgebaut... fand ich hübscher
und sollte ne eigenständige Story bekommen, nämlich Vampiere gegen Werwölfe (ein wenig and den Film Underworld angelehnt).
)). Das hab ich mal ausgetestet und es ist ca. 5 bis 10 mal so schnell!!! Nur nicht mit Floats arbeiten!
Noch ein kleiner Tipp: x*0.01 ist um ca. 20% schneller als x/100
Vielleicht hier und da noch mit Pointern arbeiten, das beschleunigt einige Sachen enorm (hab mal ein Programm geschrieben um Sprites umzufärben, also z.B. alles was Rot ist Blau machen), da hat das Einsetzen von Pointern die ganze Sache EXTREM beschleunigt (Faktor 100 oder so... war auf jeden Fall fantastisch).
Benutzt Du StartDrawing() irgendwo? Raus damit! Das bremmst übelst.
Und wie siehts aus mit ClearScreen()? Kannst Dir sparen, wenn Du eh den ganzen Screen neu malst. Das bringt Dir auch nochmal ein ganz klein wenig.
... und besorg Dir UNBEDINGT die aktuelle Version von PB

Wenn Du noch ein wenig Rechenzeit brauchst, kannst Du hier optimieren. Sin und Cos würde ich in Tabellen vorberechnen (einfach ein array z.B. Dim _Sin(360) (hier kannst du auch gleich auf Grad umrechnenSTARGÅTE hat geschrieben:nach dem ich mich jetzt schon 3 Tage nur mit der Kollision und Wegsuch beschäftigt habe ist mir jetzt (5:15) aufgefallen das ich einfach nur "scheiße" berechnet habe (sin() mit cos() vertauscht), da ich aber noch ein paar Winkelkorrekturen mit drinne hatte (jetzt weg) ist das nicht so doll aufgefallen....

Noch ein kleiner Tipp: x*0.01 ist um ca. 20% schneller als x/100
Vielleicht hier und da noch mit Pointern arbeiten, das beschleunigt einige Sachen enorm (hab mal ein Programm geschrieben um Sprites umzufärben, also z.B. alles was Rot ist Blau machen), da hat das Einsetzen von Pointern die ganze Sache EXTREM beschleunigt (Faktor 100 oder so... war auf jeden Fall fantastisch).
Benutzt Du StartDrawing() irgendwo? Raus damit! Das bremmst übelst.
Und wie siehts aus mit ClearScreen()? Kannst Dir sparen, wenn Du eh den ganzen Screen neu malst. Das bringt Dir auch nochmal ein ganz klein wenig.
... und besorg Dir UNBEDINGT die aktuelle Version von PB

.oO SDX Oo.
erstmal danke für die Beschleunigungshinweise
obwohl ich mit der Array(360) für sin und cos überhaupt nicht zufrieden bin. Ich finde es besser wenn ich das direkt berechne außerdem muss ich doch wenn ich ein Array nehme erst int() benutzen oder ?
weil meine winkel meisten im 1/10 bereich sind
StartDrawing() benutze ich nur im Menü aber im Spiel habe ich inzwischen alles rausgenommen das wusste ich schon.
Das X*0.01 schnelle ist ist mir auch schon aufgefallen aber ist es wirklich ausschlaggebend
? Klar auch 100 kleine Verbesserungen ergeben später eine sichtbare beschleunigung 
Aber das mit den Pointern bei Sprites verstehe ich nicht.
HINWEIS: Im ganzen Spiel veränder ich bei keinem Sprite die Farbe.
obwohl ich mit der Array(360) für sin und cos überhaupt nicht zufrieden bin. Ich finde es besser wenn ich das direkt berechne außerdem muss ich doch wenn ich ein Array nehme erst int() benutzen oder ?
Code: Alles auswählen
SinWert(Int(Winkel))
StartDrawing() benutze ich nur im Menü aber im Spiel habe ich inzwischen alles rausgenommen das wusste ich schon.
Das X*0.01 schnelle ist ist mir auch schon aufgefallen aber ist es wirklich ausschlaggebend


Aber das mit den Pointern bei Sprites verstehe ich nicht.
HINWEIS: Im ganzen Spiel veränder ich bei keinem Sprite die Farbe.
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Um die Genauigkeit zu verbessern, bzw. diese Methode erst überhaupt sinnvoll zu machen sollte man die Werte vorher mit 100 multiplizieren und beim benutzen wieder durch 100 teilen (bzw. mit 0.01 multiplizierenSTARGÅTE hat geschrieben:erstmal danke für die Beschleunigungshinweise
obwohl ich mit der Array(360) für sin und cos überhaupt nicht zufrieden bin. Ich finde es besser wenn ich das direkt berechne außerdem muss ich doch wenn ich ein Array nehme erst int() benutzen oder ?weil meine winkel meisten im 1/10 bereich sind...Code: Alles auswählen
SinWert(Int(Winkel))

STARGÅTE hat geschrieben:...StartDrawing() benutze ich nur im Menü aber im Spiel habe ich inzwischen alles rausgenommen das wusste ich schon.

Jup...STARGÅTE hat geschrieben:...Das X*0.01 schnelle ist ist mir auch schon aufgefallen aber ist es wirklich ausschlaggebend? Klar auch 100 kleine Verbesserungen ergeben später eine sichtbare beschleunigung
Also das mit den Sprites war nur ein Beispiel von mir, wo ich gemerkt habe, daß wenn man via Pointern und direktes schreiben in den Speicher einiges an Zeit sparen kann.STARGÅTE hat geschrieben:...Aber das mit den Pointern bei Sprites verstehe ich nicht.
HINWEIS: Im ganzen Spiel veränder ich bei keinem Sprite die Farbe.
Hier mal ein "Bauhof" aus meinem Spiel... andere Gebäude hatte ich noch nicht


Eventuell werde ich jetzt weitermachen mit meinem Spiel. Ich hoffe, ich kann dann auf Dein Wissen zurückgreifen, was die Programmierung von RTS betrifft.
.oO SDX Oo.