gibt es nicht einfach eine kleine funktion, die das einfach startet?
z.B. CallFunctionFast(label) ???
wenn ja welche?
ich habe keine lust alles wieder zu ändern
exe2 in exe1 speichern und exe2 starten
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
hier gehts nit nach lust, sondern nach können. 
ne, ehrlich:
der umbau, alle deine bisherigen programmteile in eine exe zu integrieren
und über threads korrekt ablaufen zu lassen, wäre die bessere lösung.
als ich gelesen hab:
ganz ehrlich, befasse dich mit threads.
du musstest schon eine externe kommunikation zustandebringen, um zwei exe draus zu machen.
daraus nur zwei threads zu machen, wird die kommunikation sogar vereinfachen,
weil zwei threads derselben exe auf dieselben Globals zugreifen können, zwei getrennte exe jedoch nicht.
mag sein, dass es neu für dich ist, aber du hast hier den allerbesten ansatz an problemstellung,
wofür jemand threadsteuerung lernen kann.
viele wollen ganz einfach threads, und saugen sich sinnfreie problemstellungen aus den fingern.
du hast den vorteil, dass du sie wirklich brauchen kannst.
ne, ehrlich:
der umbau, alle deine bisherigen programmteile in eine exe zu integrieren
und über threads korrekt ablaufen zu lassen, wäre die bessere lösung.
als ich gelesen hab:
da hab ich spontan gedacht: das klingt nach zwei threads.das problem ist jetzt beim, das ich einmal im ganzen durchlauf auch die Daten der anderen spieler erhalten muss.... und wenn ich 10 spieler habe, und nur 40 frames die sekunde dann bewegen sich bei mir auf den bildschirm alle figuren nur 4 mal in der Sekunde. Für nen Shooter ist das ********. Jetzt habe ich mir ein 2tes programm geschrieben, was 200 mal in der sekunde durchläuft und 30 mal pro sekunde meine position weiterschickt. und 300 mal in der überprüft, ob vom server informationen gekommen sind. (das tuts auch).
ganz ehrlich, befasse dich mit threads.
du musstest schon eine externe kommunikation zustandebringen, um zwei exe draus zu machen.
daraus nur zwei threads zu machen, wird die kommunikation sogar vereinfachen,
weil zwei threads derselben exe auf dieselben Globals zugreifen können, zwei getrennte exe jedoch nicht.
mag sein, dass es neu für dich ist, aber du hast hier den allerbesten ansatz an problemstellung,
wofür jemand threadsteuerung lernen kann.
viele wollen ganz einfach threads, und saugen sich sinnfreie problemstellungen aus den fingern.
du hast den vorteil, dass du sie wirklich brauchen kannst.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
> z.B. CallFunctionFast(label) ???
Warum? Für Threads brauchst du nur eine Zeile:
CreateThread(@DeineProzedur(), 0)
Das war's und tut weniger weh als ne Spritze beim Arzt (buah, wenn ich daran nur denke...).
Glaubs mir/uns, Threads sind einfacher, als du denkst!
Warum? Für Threads brauchst du nur eine Zeile:
CreateThread(@DeineProzedur(), 0)
Das war's und tut weniger weh als ne Spritze beim Arzt (buah, wenn ich daran nur denke...).
Glaubs mir/uns, Threads sind einfacher, als du denkst!
PB 4.30
Code: Alles auswählen
Macro Happy
;-)
EndMacro
Happy End-
ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
Genau das ist meist der grosse IrrtumAND51 hat geschrieben:Glaubs mir/uns, Threads sind einfacher, als du denkst!
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
is ja scho recht, ts....
aber in diesem falle würde ich wirklich zu threads raten.
wer in der lage ist, sich zwei parallele exen um die ohren zu haun, der wird auch mit zwei threads klarkommen.
...is eigentlich nen guter indikator...
hast du ein problem, für das du zwei parallele exen erstellen würdest?
ja?
dann darfst du mit threads anfangen, gratuliere.
vorher nich.
aber in diesem falle würde ich wirklich zu threads raten.
wer in der lage ist, sich zwei parallele exen um die ohren zu haun, der wird auch mit zwei threads klarkommen.
...is eigentlich nen guter indikator...
hast du ein problem, für das du zwei parallele exen erstellen würdest?
ja?
dann darfst du mit threads anfangen, gratuliere.
vorher nich.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Hätte ich damals, als Neuling, gewusst wie einfach Threads sind, hätte ich sie sofort verwendet. Ich ärger mich heute noch drüber, dass ich so manche Sachen nicht schon früher ausprobiert habe. Nach meiner Meinung heute hätte ich das früher schon schaffen können. So auch mit Threads.ts-soft hat geschrieben:Genau das ist meist der grosse IrrtumAND51 hat geschrieben:Glaubs mir/uns, Threads sind einfacher, als du denkst!
Ich kann Kaeru nur zustimmen und er nur mir. Was wollen wir also mehr?
PB 4.30
Code: Alles auswählen
Macro Happy
;-)
EndMacro
Happy End-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
es kommt vor allem auf die denkweise an.
manche leute machen mit threads kaum fehler, weil sie von anfang an in den richtigen wegen denken.
das würde ich hier durchaus vermuten, wenn jemand lieber zwei getrennte programme erzeugt.
aber viele denken bei threads in verflixte falsche richtungen.
war nicht der gedanke "ein thread pro objekt" von dir?
musste man dich nicht explizit auf den unterschied zwischen "multithread" und "multiobject" hinweisen?
manche leute machen mit threads kaum fehler, weil sie von anfang an in den richtigen wegen denken.
das würde ich hier durchaus vermuten, wenn jemand lieber zwei getrennte programme erzeugt.
aber viele denken bei threads in verflixte falsche richtungen.
war nicht der gedanke "ein thread pro objekt" von dir?
musste man dich nicht explizit auf den unterschied zwischen "multithread" und "multiobject" hinweisen?
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
> war nicht der gedanke "ein thread pro objekt" von dir?
ja, das ist richtig.
Aber hier geht es (noch) nicht, um den Verwendungszweck des Threads, sondern um die Handhabung. Ich fragte nach dem WOFÜR?, hier in diesem Thread wird aber nach dem WIE? gefragt.
Wie benutze ich einen Thread? Und mein Beitrag von wegen, ich hätte Threads schon früher erlernen können, bezog sich auch auf das WIE?.
ja, das ist richtig.
Aber hier geht es (noch) nicht, um den Verwendungszweck des Threads, sondern um die Handhabung. Ich fragte nach dem WOFÜR?, hier in diesem Thread wird aber nach dem WIE? gefragt.
Wie benutze ich einen Thread? Und mein Beitrag von wegen, ich hätte Threads schon früher erlernen können, bezog sich auch auf das WIE?.
PB 4.30
Code: Alles auswählen
Macro Happy
;-)
EndMacro
Happy End
Was mir grad zu diesem Thread einfällt, auch wenn's mit dem eigentlichen Thema nix zu tun hat:
Es kommt verdammt oft vor, daß einer erstmal was völlig abstraktes schildert, und dann fangen schon die ersten an, ihm dazu Tips zu geben - aber nach 5 Postings kommt erst so langsam raus, was der Originalposter EIGENTLICH vorhat (und daß das eigentlich ganz anders gemacht wird). Meiner Meinung nach sollte man a) in der FAQ oder sowas erwähnen, daß man nicht nur seine Probleme schildern soll, sondern auch erklärt, was man damit eigentlich erreichen will, und b) sollten die, die antworten, möglichst auch nicht gleich loslegen und genau auf das Problem eingehen, sondern vielleicht erstmal nachhaken, was überhaupt der Zweck ist.
Ist mir jetzt schon öfter aufgefallen, daß das oft so abläuft, und dann ist es klar, daß es erstmal 'ne Weile dauert, bis so ein Problem gelöst ist (bzw. angefangen wird, zu lösen ).
Es kommt verdammt oft vor, daß einer erstmal was völlig abstraktes schildert, und dann fangen schon die ersten an, ihm dazu Tips zu geben - aber nach 5 Postings kommt erst so langsam raus, was der Originalposter EIGENTLICH vorhat (und daß das eigentlich ganz anders gemacht wird). Meiner Meinung nach sollte man a) in der FAQ oder sowas erwähnen, daß man nicht nur seine Probleme schildern soll, sondern auch erklärt, was man damit eigentlich erreichen will, und b) sollten die, die antworten, möglichst auch nicht gleich loslegen und genau auf das Problem eingehen, sondern vielleicht erstmal nachhaken, was überhaupt der Zweck ist.
Ist mir jetzt schon öfter aufgefallen, daß das oft so abläuft, und dann ist es klar, daß es erstmal 'ne Weile dauert, bis so ein Problem gelöst ist (bzw. angefangen wird, zu lösen
).
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
das mit den FAQ wär ne nette idee, aber ich sag dir was:
die liest eh keiner
so ein lehrfilm, auf's PureBoard abgestimmt wär mal was.
http://www.albinoblacksheep.com/flash/posting.php
ich frag ja oft nach, was der betreffende eigentlich will...
dummerweise halten sich die wenigsten an so eine vorgehensweise,
und er bekommt erstmal ein paar lösungsvorschläge und codes um die ohren gehaun,
dass er mein posting komplett ignoriert.
so wie hier:
http://www.purebasic.fr/german/viewtopic.php?t=12755
die liest eh keiner
so ein lehrfilm, auf's PureBoard abgestimmt wär mal was.
http://www.albinoblacksheep.com/flash/posting.php
ich frag ja oft nach, was der betreffende eigentlich will...
dummerweise halten sich die wenigsten an so eine vorgehensweise,
und er bekommt erstmal ein paar lösungsvorschläge und codes um die ohren gehaun,
dass er mein posting komplett ignoriert.
so wie hier:
http://www.purebasic.fr/german/viewtopic.php?t=12755
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.