Beiträge von Mars

  • Turnierspiel Kombinationen

    Ich habs mal grafisch dargestellt. Da gibt es natürlich irgendwelche Muster, aber ich wüsste nicht wie man die sinnvoll in Formeln fassen kann. (Es kann auch sein, dass ich da völligen Unfug gefärbt habe^^)

    Edit: Folgende Regeln wurden berücksichtigt:

    - In jeder Runde muss jeder Spieler 1x drankommen

    - Kein Spieler darf 2x hintereinander drankommen

    Edit2: Die zahlen in der letzten Reihe ignorieren, die waren für mich zur Orientierung und ich habe sie ausversehen mit drin.

    Edit3: Es gibt wahrscheinlich unglaublich viele Kombinationsmöglichkeiten die die oben genannten Regeln erfüllen. Ggf ist eine davon durch einfache Formeln fassbar...

    lg

    M

  • GetUniqueColors

    Von Intel gibts auch integrierte Grafikchips die anständig Leistung haben, die werden aber irgendwie nie verbaut (z.B. Iris 650 die etwa so stark wie 50-60€ Grakas ist, also ca. 2x so schnell wie die 620). Wenn das Teil allerdings nur auf einem einzigen Prozessor der von Schamanen in einem heiligen Ritual unterwasser am Nordpol um 12 Uhr Mittags geweiht wurde verbaut wird kann man damit nix reißen.

    Wenn AMD da angreift und integrierte Chips rausbringt die wie eine 1050 laufen muss Intel liefern, sonst sind sie geliefert.

  • GetUniqueColors

    Wie zu erwarten. CPU < Billigstgrafikkarte < Einsteiger Gamingkarte

    Man sieht: Die Intel HD620 ist ähnlich schnell wie eine Nvidia 630GT^^

  • GetUniqueColors

    Zum Überlauf:

    Sobald eine Farbe ein Mal aufgetreten ist, ist der Wert von byte[col] >0 und die Farbe wird nicht erneut gezählt, also ist es nur wichtig wie viele Threads existieren (da bei gleichzeitigem Lesen der Farbe die einzige Möglichkeit besteht, dass sie doppelt gezählt wird) und nicht wie oft die Farbe im Bild vorkommt.

    Zum parallelen Schreiben in die gleiche Variable:

    Das wusste ich nicht, da ich noch nicht viel mit MT betrieben habe. Ich dachte bei gleichzeitigem erhöhen einer Variable wird das irgendwie Prozessorintern behandelt, sodass beide Erhöhungen stattfinden. Wenn da quasi alles von 1 bis 4 herauskommen kann funktioniert mein Ansatz natürlich nicht...

    Scheint doch nicht so einfach zu sein wie zuerst gedacht :D

    Edit: Ich hatte dein Beispiel weiter oben schon gelesen, aber wohl falsch interpretiert. Da hätte mir eigentlich klar sein müssen wie das abläuft.

  • GetUniqueColors

    Man könnte MT nutzen und das Array statt auf den Wert 1 zu setzen um 1 erhöhen (Das Array ist ja sowieso mit byte[] besetzt). Damit springen wir zwar wieder zurück auf die Abfrage "> 0" statt "==0" das sollte in C und ASM aber keinen Unterschied machen (je 1 Takt). Die "zuviel" gezählten Farben müssen nun den "zuviel" gezählten Werten im Array entsprechen.

    Beispiel:

    4 Threads, alle 4 testen gleichzeitig einen Pixel mit der gleichen Farbe.

    -> byte[col] = 4 (nachdem alle Threads fertig sind)

    -> farbcounter = 4 (nachdem alle Threads fertig sind)

    Die Tatsächliche Anzahl Farben ist also: farbcounter MINUS (Summe der Bytestruct MINUS 1 für jedes Element >0) = 4 - 3 = 1

    Zusatzaufwand:

    - Summe der 4 farbcounter (das sind nur ein paar Takte, oder kann man hier Threadübergreifend den gleichen nehmen?)

    - Summe der (Bytestruct - 1) für jedes Element >0. (das wird etwas Zeit brauchen, bei 2^24 Elementen und angenommenen 3ghz -> ca. 15-20 Millisekunden, wobei sich dieser Vorgang ebenfalls parallelisieren lässt in z.B. 4*2^22 Elemente)

    Voraussetzungen:

    - Weniger als 256 Threads (da die Bytestruct sonst im Zweifelsfall überläuft)

    - Information was passiert, wenn 2 oder mehr Threads eine Speicherstelle um 1 erhöhen. Werden dann tatsächlich alle Erhöhungen gemacht?

    M

  • GetUniqueColors

    Das liegt vermutlich daran, dass 256^4 * 1 Byte = 4 Gigabyte sind. Versuch mal das Programm mit 64Bit zu kompilieren, oder 256^4 * 1 Bit (also 1 Bit je Pixelfarbe) zu adressieren. (Für die 1 Bit Variante brauchst du dann aber ein paar Bitshifts, damit du die einsen korrekt speichern kannst, da der Zugriff nur auf 8 Bit Blöcke möglich ist. Alernativ kann man auch per OR und 10000000b das erste, mit OR 01000000b das zweite usw Bit setzen und mit AND 10000000b abfragen ob dieses Bit gesetzt wurde)

  • GDI+ Problem mit Kollision für bestimmten Bereich (Collision)

    Die Sache mit Local und Global ist und bleibt ein Mysterium.

    Prinzipiell wird jede Variable außerhalb von Funktionen Global deklariert, egal was man davorschreibt. Und Innerhalb von Funktionen sollte man normalerweise nicht "Global" als Statement verwenden, da hier das Programm keinen zu jedem Zeitpunkt fest definierten Pool an globalen Variablen mehr hat und dem Programmierer das Leben nur unnötig schwer macht. (z.B. könntest du eine Initialisierungsfunktion schreiben die alle globalen Deklarationen enthält und diese gleich zu Beginn aufrufen. Das wird dir aber an vielen Stellen Warnungen a la "Variable possibly not declared yet" entgegenwerfen, dem muss man dann mit forcedef usw entgegenwirken). Im Regelfall löst man soetwas gekapselt über eigene Dateien. z.B. enthält die GDI+ UDF alle notwendigen globalen Variablen und wenn man ein großes Programm schreibt erstellt man auch einzelne "Module" die jeweils gewisse Programmteile beinhalten die jeweils eigene globale Variablen besitzen.

    Potential hätten diese Scopes, wenn es noch weitere Kategorien wie "Subglobal" = "Lokal außerhalb von Funktionen" oder "Superlocal" = "Global innerhalb einer Funktion" geben würde. Soetwas wurde in AutoIt aber nicht implementiert, sodass man prinzipiell auch überall "Dim" benutzen kann, dieses ist in Fuktionen automatisch lokal und außerhalb automatisch global. Für "sauberen Code" benutzt man überlicherweise aber Local in- und Global außerhalb.

    Edit1: Und noch ein kleiner Tip zur Bewegung:

    Mach dir ein Array mit [_IsPressed, ..., ..., ..] für die 4 möglichen Richtungen. Kommt ein verschachteltes Switch oder If Else um unmögliche bzw simultane Bewegungen zu berücksichtigen. z.B. ist es unsinnig nach rechts UND links zu gehen und diagonale Bewegungen brauchen einen Faktor (Wurzel 2). Weiterhin ist es sinnvoll alle Spielerrelevanten Daten in ein Array zu packen und die Indizes via Enum zu deklarieren. Anbei ist auch ein Beispiel was ich meine (OBACHT: Ich bin mir ziemlich sicher, dass man diese unendlich verschachtelten If Abfragen irgendwie effizienter anordnen kann, aber es funktioniert schonmal :) )

  • GDI+ Problem mit Kollision für bestimmten Bereich (Collision)

    Hier mal eine zusammenfassende Stellungnahme zu dem Skript: (hoffentlich konstruktive Kritik)

    - Memoryleak bei Zeile 84 und 85. Die Grafiken müssen beim "Start" einmal geladen und beim "Ende" wieder freigegeben werden. Sie bei jedem Zeichnen neu von der Platte zu lesen und nicht wieder freizugeben verursacht ein Speicherleck.

    - Das "exit" am Ende der SetOnEvent Funktion ist "unschön". Besser ist es einen Main Loop zu haben der z.B. via "While Not $bExit" läuft. Via Event lässt sich dann das $bExit auf True umstellen, anschließend durchläuft das Programm die aktuell laufende Schleife aber noch vollständig und kann anschließend in der niedrigsten Ebene (also nicht in einer Funktion, einem Event oder sonstigem) terminieren. Zum freigeben der Ressourcen kann man entweder eine Freigabefunktion nach dem Main Loop aufrufen, oder via OnAutoItExitRegister automatisch ausführen lassen sobald das Programm beendet wird. Hier aber auch unbedingt KEIN "exit" reinschreiben.

    - Kollisionsdetektion kann über mehrere Verfahren die sehr einfach zu bewerkstelligen sind erledigt werden. Erstens wäre der Klassiker RectRectCollision oder PointRectCollision (leider wurden die schon millionenfach implementiert und haben jedes Mal einen anderen Namen), oder man benutzt eine 2te Bitmap und weist den Hindernissen explizite Farbwerte zu, diese kann man mit GDIPlusBitmapGetPixel abfragen. Mit Path Funktionen kenne ich mich leider nicht aus, da muss jemand anderes helfen...

    - Unterhalb deiner Linie wo "declaration ------------" steht wird überall Local als Keyword genutzt. Verwende an dieser Stelle lieber Global. Genauso wie bei den GDI+ Objekten die später auch alle mit Local deklariert werden. AutoIt ist zwar gegen solche "Fehler" abgesichert und interpretiert das "Local" dennoch als "Global" (da man in der niedrigsten Ebene ist), das gehört aber zum guten Stil.

    Code
    Func _Kollision_Viereck_Viereck($x1, $y1, $b1, $h1, $x2, $y2, $b2, $h2) ;Selbsterklärend
Return ($x1 + $b1 > $x2 And $y1 + $h1 > $y2 And $x1 < $x2 + $b2 And $y1 < $y2 + $h2)
EndFunc   ;==>_Kollision_Viereck_Viereck

Func _Kollision_Viereck_Punkt($x1, $y1, $x2, $y2, $b2, $h2) ;Selbsterklärend
Return ($x1 > $x2 And $y1 > $y2 And $x1 < $x2 + $b2 And $y1 < $y2 + $h2)
EndFunc   ;==>_Kollision_Viereck_Punkt

    Edit1: Allgemein gibt es 2 Möglichkeiten zu verhindern, dass der Spieler über ein verbotenes Gebiet geht.

    - Die Erste ist das Prognostizieren, dass die gewünschte Bewegung nicht geht und diese verhindern bevor sie ausgeführt wird. (Man berechnet also vorher, dass eine Bewegung nicht möglich ist und führt diese dann nicht aus)

    - Als Zweites existiert die Möglichkeit jede Bewegung per sé auszuführen, egal ob sie möglich ist oder nicht. Anschließend wird festgestellt, dass sich der Spieler in einem Verbotenen Gebiet befindet und "sanft" zurückgedrängt bis er wieder wo steht wo er auch stehen darf.

    lg

    M

  • GetUniqueColors

    Hab eine primitive ASM Version geschrieben. (primitiv im Sinne von "kein SSE und sonstige Extras, sondern wirklich nur extrem einfach"). Da hierbei AutoIt für das calloc zuständig ist (das geht bestimmt auch in asm, aber ich habe das noch nie gemacht und hatte keine Zeit zu googeln :D) gibt es einen größeren Overhead. Daraus folgt, dass die ASM Variante für "kleine" Bilder langsamer als die DLL ist und für große Bilder schneller.

    Edit: Zumindest bei mir lief es für 4K Bilder ca. 30-50% schneller. Aber keine Garantie dass der PC nicht explodiert wenn der Code ausgeführt wird :D

  • GetUniqueColors

    ich hab leider keinen C Compiler hier. Hast du ausprobiert, ob es schneller ist im loop (Zeile 9, 10, 11) VOR die Zuweisung der Zahl 1 eine Abfrage mit If colors[pixel[i] & 0xffffff] == 0 Then colorSum++ einzubauen? Dann muss nicht das komplette Array (was ja von 0 bis 0xffffff geht) durchlaufen werden, sondern nur die Parts die relevant sind. Ich schätze das hilft auch in C und ASM ein wenig.

    Edit1: (je nachdem wie der Compiler intern arbeitet muss man ggf das mehrfache Auftreten von pixel[i] & 0xffffff in eine Variable packen, sonst lässt er das mehrfach ausführen, was mehr Ram-Zugriffe bedeutet und damit langsamer sein sollte)

    Edit2: (wieder je nachdem wie es läuft ist colorsum += (1-colors[pixel[i] & 0xffffff]) schneller als das If)

  • GetUniqueColors

    Nur als kleiner Tip: Die Arrayvariante lässt sich noch etwas aufbohren, wenn man die Farben nicht "zählt" sondern einfach nur eine 0 oder eine 1 hinterlegt, je nachdem ob die Farbe schonmal aufgetaucht ist. (Dann verbraucht man auch keine wertvollen Takte um abzuspeichern, dass die Farbe FF4265 genau 5531x aufgetaucht ist).

    ------------------------------------------------------------------------------------------

    Wenn man jetzt von Arrays auf Structs umsteigt kann man (theoretisch) jedes einzelne Bit als Indikator benutzen ob die Farbe bereits vorhanden war (Geringer Speicherverbrauch, langsam) oder man nimmt die Variante, die dem Prozessor am besten schmeckt und nutzt 8Bit (bei Ungerader Pixelzahl muss hier am Ende ein 32er Register vollgestückelt werden glaube ich) oder 32Bit (supereinfach, superschnell, Speicherintensiv. Das Ganze ist auch in ASM ziemlich einfach, ich kann es aber leider gerade nicht machen... sollte für gewisse Leute hier eine Sache von 5 Minuten sein.

    lg

    M