Beiträge von Mars

Das Skript verwaltet leider nur grafikgenerierende Funktionen, es beinhaltet keine (außer den standard GDI+ Funktionen)
Was man damit anstellen kann wissen wir alle. Anbei eine von mir zusammengebastelte 80 Frames lange Animation. Ist völlig unoptimiert und braucht daher einige Ladezeit, und aussehen tuts auch nicht dufte
Mit minx' Pixelsetzfähigkeiten kann das Teil natürlich nicht mithalten, das was man hier eigentlich betrachten soll ist der Aufbau der Bilddatei (und ob man so ein Konstrukt überhaupt gebrauchen kann)

lg
M

Habs gefunden.
Wer reinschauen möchte darf gerne die Test.au3 zünden, sollte mit der aktuellen Stable laufen. Habe aber jetzt noch nichts daran verändert, das ist noch sehr unfertig
Bitte die Kommentare in der Test.au3 beachten, sonst werden die Bilder falsch geladen...

Durch Andys Verlinkung habe ich mich gerade wieder an etwas erinnert...
Vor einiger Zeit habe ich mal eine ziemlich umfangreiche Version in Bezug auf Prozedurale Grafiken in AutoIt gebastelt. Die bietet wesentlich mehr als die verlinkte Version. Wenn ich mich recht erinnere z.B.
- Eigene Funktionen IN der Prozedur (man kann der Prozedur also eigene Funktionen verpassen, sodass man mit einem einheitlichen Interpreter arbeiten kann der von Haus aus nur wenige Funktionen besitzt).
- Erzeugen von Objekten (Brush/Pen/Bitmap/usw) IN der Prozedur und anschließendes verwenden.
- Echte Parameter zum Rendern (man kann ein Bild mit verschiedenen Parametern ausstatten, sodass es z.B. Animiert werden kann, oder Seeds für Zufallsfunktionen gesetzt werden).
- Animationen (werden allerdings gepuffert, da eine Echtzeitanzeige zu langsam wäre), es ist möglich Die gleiche Animation in unterschiedlichen Frameraten und Auflösungen zu rendern.

Das wirkliche Schmuckstück ist aber leider noch unvollendet: Prozeduren in Prozeduren. So kann man z.B. eine Animation erzeugen die eine Animation enthält, die eine Animation enthält, ..., usw. Mit dieser Funktionalität ließen sich komplette simple Animationsfilmchen erzeugen. (je nach Schachtelung kann das Rendern aber mal 5Minuten dauern^^).
Ton wird nicht unterstützt, da ich mich damit nicht auskenne.
Ich werde das Skript morgen mal suchen und schauen ob ich es Benutzerfreundlicher und Forentauglich zurechtbiegen kann.

Die Bilder und Sounds sind als Ressource (Bilddaten der Bilddateien) in einer Datei zusammengefasst. Der Aufbau dieser Datei ähnelt dem .Tar Format.

Bei mir sind es 3 Spiele:

#1: The Legend of Zelda: Oracle of Ages/Oracle of Seasons
Das Spiel ist für den GB/GBA entwickelt worden und in 2D. Die Story ist eine typische Zelda Story.
Was mich an dem Spiel beeindruckt ist die Liebe zum Deteil und die vielen kleinen versteckten Quests/Gebiete/Gegenstände.
+ "Verlorene Wälder"
+ Wände die man mit Bomben zerstören kann, obwohl man es ihnen nicht ansieht
+ eine Hand voll Items die aber jeweils in einigen Levels vorliegen, sofern man sie findet/erwirbt.
+ Viele "Schlösser", viele "Endgegner" in diesen und jeweils Items die man finden muss um an bestimmte Orte zu gelangen

#2: Sudeki
Ist ein Spiel für den PC und wurde irgendwann im letzten Jahrzehnt entwickelt. Es ist in 3D.
~ Die Grafik ist nichts besonderes (für damalige Verhältnisse durchschnittlich, heute aber ziemlich überholt)
+ Sehr interessante Story, viele Wendungen, Fantasy
+ Gesprochene Dialoge die teilweise sehr lustige Betonung, pure Erotik (Ailish, sexy, yeah !)
+ 2 Klassen fürs Kampfsystem, Fern und Nahkämpfer, keine weitere Klassenunterteilung.
+ Linearer Handlungsablauf (ich persönlich ziehe das der heutzutage verbreiteten Ansicht Linearität sei negativ vor)
- Teils nervt es wenn man durch gebiete wandert und andauernd Gegner auftauchen. Der Vorteil ist, dass man dadurch levelt.
~ Sehr primitives Kampfsystem (finde ich so wie es ist ganz ok, könnte aber besser sein)
+ Viele verschiedene Gebiete die man bereisen kann. Viele verschiedene Endgegner (sie sehen nicht nur verschieden aus, sondern erfordern allesamt eine eigene Strategie)

#3: Mass Effect 1/2/3
Modernes Spiel aus den letzten paar Jahren, sehr gute 3D Grafik.
+ Interessante Story
+ Einige Charaktere mit jeweils unterschiedlichen Fähigkeiten
+ Die absolut unbesiegbare standardpistole in Mass Effect 1 (wenn man Handfeuerwaffen voll skillt und sich eine anständige knarre zulegt braucht man keine anderen Waffen mehr, das mag zwar doof klingen aber lustig ist es dennoch^^)
+ Viele Missionen
- Langwierige/Langweilige Erkundungen fremder Planeten (es gibt 100erte). Man braucht ewig viel Zeit bis man überall war, und das obwohl man in der Regel kaum etwas brauchbares findet.
+ Sexy Tali gibts in allen 3 Teilen mit Raumanzug. Übergeil !
+ Hurmorvoll gestaltete Charaktere.

Für ein großes 3D Spiel braucht man die richtige Ausbildung und ein großes Team, ich gehöre zu einer Gruppe von ca. 25 Personen die gerade eins basteln (seit über 1,5 Jahren schon^^). Dafür habe ich den einzigen Part übernommen für den man wirklich programmieren können muss, nämlich den Launcher und die Dateiverwaltung und Downloads usw (in AutoIt !). Alles weitere wird in der UDK erledigt. 3D Modelle werden in Blender gebastelt. Vorteil ist, dass man zum erstellen eines Spiels kaum Programmieren können muss, da die UE alles mitbringt. Im Prinzip ist die UDK wie ein riesiger Leveleditor mit dem man sich ein Spiel selbst erstellen kann.

Daher rate ich dir: Wenn du wirklich irgendwas richtung 3D machen willst, nimm die UE und tue den Teufel AutoIt dafür zu verwenden. Selbst wenn du in Irrlicht oä ohne Probleme 3D Szenen erstellen kannst, das ganze Skripten (für NPC, Gegner, Protagonisten, Itemsystem, usw usw) ist mehr Programmierarbeit als man sich vorstellen kann. In der UE ist das alles enthalten, sodass du (vorsicht übertreibung) mit 5 Klicks einen NPC hast der dir Waffen verkaufen kann.

lg
M

Auch einen Glückwunsch aus dem Rheingau, prost !

Hab mal die Bilder von 13 hübschen Mädels übereinandergelegt (mit einem Grafikbearbeitungsprogramm).
Dabei wurden die Bilder ausschließlich gedreht und Skaliert, sodass die Augen übereinander liegen.
Beim Resultat sieht man deutlich, dass keine anständige Kopfform herauskommt...

Aber der Schatten über dem einen Auge hat wohl stil, der hat sich durchgesetzt

Edit: Hab wohl mit der Transparenz etwas unfig getrieben, die 13 Bilder sind NICHT gleichwertig ins Resultat eingegangen...

Wir haben unsere(n) Hausmeister auch immer gerne gehabt, allerdings hat er nichts verkauft. Dafür hatten wir einen "Stückchenstand" wo es allerlei knabbergebäck gab. Der wurde ebenfalls wegen irgendwelchen sinnlosen Gesetzen dicht gemacht.

+1

Und umgetauft wurde er auch noch. Und das im Alter von 25 Jahren in Bonn... ääh, Berlin.

Techmix benutzt Psywelle,
OpenCL ist Paralysiert.

Es steht nirgends geschrieben, dass man einen Kompressionsalgo nicht portieren kann, nur dass er wahrscheinlich nicht wesentlich schneller läuft als auf einer CPU. Das größte Problem ist die Parallelisierbarkeit. Da du vorhast deine Dateien in 16KB Stücke zu zerhacken und diese einzeln zu komprimieren, ist das aber kein Problem und sollte auch einen großen Temposchub ermöglichen. (z.B. eine 1MB datei -> 64 Teile -> 64 Threads -> Schnell)

Moin,

Um das Problem anzugehen gibt es mehrere Methoden. Die einfachste ist natürlich Brute Force.
Ein weiteres Hindernis ist die nicht vorhersehbare Anzahl aufspaltungen (in deinem Beispiel läuft das alles mit 2 oder 3 Summanden, aber was ist mit 4, 5, 6, ..., n ?)
Da man in AutoIt keine variable Schleifenschachtelung hat (hab keine Ahnung ob es eine Sprache gibt die sowas besitzt), kann man kein Programm schreiben, welches sich auf die Anzahl Aufspaltungen automatisch anpasst. (In Deutsch: Mit einem Programm mit 2 Schleifen kann man ausschließlich 2 Summanden bestimmen, aber nicht 3, 4, ..., n)

Da wir aber nicht gänzlich bescheuert sind, basteln wir uns diese Funktionalität einfach selbst.
Dazu nimmt man ein n Dimensionales Array welches die einzelnen Schleifenzähler darstellt (Array = Anpassbar).
Anschließend zählen wir die Schleifen (rekursiv) Stück für Stück nach oben. (Rekursion ist hier unumgänglich !).
Das Resultat: Eine Variable Schleifenverschachtelung.

Ein kleines Beispiel gibts hier. Das kann natürlich noch optimiert werden. (Man kann große Ergebnisräume ausschließen wenn z.B. die erste Zahl eine 4 ist braucht man nicht mehr 4+2, 4+3, usw absuchen).

lg
M

Wunderbar
Entdeckt habe ich nur sehr kleine Kleinigkeiten:
1. Typo im Configbildschirm Pafe = Pfade
2. Flackern im neues Projekt erstellen Fenster (wahrscheinlich nur ein SetData in einer Schleife)

Sonst läufts geschmeidig

lg
M

Es gibt dafür auch ein sehr schönes Programm: https://autoit.de/index.php?page=Thread&threadID=18191
Edit: bitte keine (unnötige) Leichenschändung betreiben, der obige Thread ist so gut wie er ist

lg
M

name22, du hast jetzt nicht ernsthaft genau das gleiche wie ich fabriziert

Damit hast du 2 funktionierende Lösungen

lg
M

Wenn du das Programm nicht andauernd erweitern und neu Einstellen willst empfehle ich eine kleine interne Sprache zu erstellen.
z.B. könnte man das so speichern: (Achtung alles nur Fiktion, ich habe keine Installation zur Hand die ich beschreibe)

[Rechner_123] ; name der Installation
Click Weiter
Check "I Agree*" ; * als wildcard
UnCheck "ASK*"
Click Finish

Diese interne Sprache umfasst dann einige Befehle die Anwendungsspezifisch hintereinandergereiht die Installation automatisieren.
Der Vorteil zum direkten AutoIt nutzen ist die Erweiterbarkeit. Kommt eine Installation hinzu braucht man z.B. nur eine 0.5kb große Daten irgendwo hinzuzufügen, und schon ist diese Installation abgedeckt.

Kann auch sein, dass ich das falsch verstanden habe, und der obige Ansatz das Ziel verfehlt.

lg
M

Das mit den Datentypen ist finde ich wirklich so eine Sache. Intern wird ständig herumgecastet, obwohl das in den meisten Fällen garnicht notwendig wäre. (z.B. das was letztens in der SB angesprochen wurde mit Mod(10, 5.0) = Double). Das Einfügen der handelsüblichen Datentypen wäre aus meiner Sicht sehr sinnvoll. Wie Oscar schon sagte könnte man Variant immer dann nutzen, wenn nichts explizit vorgegeben ist. Das wäre vorallem Praktisch für Handles (da gibts in den meisten Sprachen 10 verschiedene, obwohl alle eigentlich nur ein 32Bit int sind).

Auch wenn das immer wieder zur Sprache kommt: Mehr Tempo bei vorgegebenen Datentypen könnte auch drin sein. Ich vermute, dass AutoIt intern bei jeder Operation mit einer Variable erst deren Typ geprüft wird, das würde dann entfallen.

Dann wünsche ich mir noch Variablen mit festlegbarem Scope. Man stelle sich vor es existieren 2 Skripte mit jeweils vielen Globalen Variablen. Möchte man diese Skripte zusammenführen, müssen unmengen umbenennungen vorgenommen werden. Könnte man einfach ein Scope um die einzelskripte lesen wäre das eine Sache von 5 Minuten statt 5 Stunden. (leicht übertrieben ausgedrückt)

Es wird allgemein von Adlib abgetaren, weil man als Programmierer die Kontrolle verliert an welchem Punkt die Funktion ausgeführt wird.
Eine Registrierte Funktion kann also Daten (z.B. Globale Variablen) beeinflussen, ohne dass man exakt weiß wann diese Beeinflussung stattfindet.

Mit Timern und Static lassen sich extrem einfach Funktionen bauen die nur alle x ms ausgeführt werden.
Vorteile:
- Falls die Funktion ausgeführt wird weiß man genau an welcher Stelle, Komplikationen wie mit Adlib können nicht auftreten.
- Man kann über die Position von TimerInit() (in der Funktion) bestimmen wie gezählt wird. Ist TimerInit direkt nach TimerDiff wird keine Rücksicht auf die Laufzeit der Funktion genommen, sie wird dann einfach alle x ms aufgerufen. Ist TimerInit ganz am Ende der Funktion wird die Laufzeit einbezogen.
Nachteile:
- Man muss die Funktion in die Schleife schreiben, Adlib kann einfach außerhalb der Schleife erledigt werden.
- Man kann die Funktion nicht anderweitig nutzen. (Man kann also nicht die gleiche Funktion alle 100ms und z.B. alle 500ms laufen lassen, das ließe sich mit etwas Programmieraufwand beheben, aber so komplex braucht man das nicht)
- Wenn Laufzeiten berücksichtigt werden wird der Programmfluss aufgehalten, kann man aber umgehen, sofern das Problem teilbar ist.

lg
M

Jop läuft. Auf dem Atom Holzrechner brauchts 5 Sekunden

läuft leider auf meinem Intel Atom 330 läuft der Code leider nicht.
Auf nem anderen Rechner (mit i5) teste ich das später, hab jetzt leider keine Zeit...

lg
M