Beiträge von minx

Der Umstieg von GDI zu OpenGL. Wie bereits mehrfach erwähnt ist OpenGl nicht darauf ausgelegt Einfachst-Befehle zu bieten. Wenn dies der Wunsch ist, dann habe ich für diesen Zweck das ext-Include gemacht.

Such ich nach OpenGl Tutorials (NeHe, das offizielle, BASIC) dann zeigt OpenGl seine Stärken, die in den immer gleichen Befehlen liegt! Man kann es 1:1 portieren ^^. Der Nutzer kann weit über 50% der vorhandenen OpenGl Tuts nutzen :P, so wie ich es auch getan habe.

Klar ist OpenGl 2D wie auch 3D begabt. Dazu gibt es übrigens noch einige Funktionen in der soil. Manchmal hilft es auch einfach die API Doku zu lesen, welche bei glfw, ogl, soil eine der Besten ist, die ich je lesen durfte.

-> Wenn du abstrahieren willst, dann erstelle die Funktionen im der ext. ABER, damit man Standard-Ressourcen nutzen kann - jeder - sollten die originalen Befehle erhalten bleiben, DENN dies ist bei GDI genauso der Fall und einfach Standard beim Programmieren. Erst wenn die Funktionen - die genau das tun, und genau so aussehen wie in der DLL oder anderen Programmiersprachen - funktionieren, kann man abstrahieren. Dennoch muss die Systemübergreifende Kompatibilität gewährleistet sein, was der Grundgedanke bei OpenGL ist. Soviel dazu

Wenn dich erste Gehversuche frustrieren, dann befass dich weiter damit, oder frag einfach ^^. (Für OpenGl gibts übrigens auch eine wunderbare Onlinehilfe). Gegen einfache Befehle hat keiner was - schon gar nicht ich - allerdings müssen die Grundstrukturen verfügbar sein. Ansonsten sind alles bloß "blinde Nutzer", die bei Tweaks, die manchmal nur durch einen einzelnen kleinen Befehl erreicht werden, nicht mehr weiterwissen.

Mal OT:
GDI wird von Microsoft auch gerade etwas verstoßen (eigentlich schon länger). Statt sich weiter auf den "Ausbau" von GDI zu konzentrieren sollte man den von MS vorgeschlagenen Weg gehen und mal DirectX benutzen ^^. Denn irgendwann ist Sense mit dem GDI Zeugs - und dann stehn se da

Na aber nicht zu weit absrahieren. Sonst bringen allgemeine Tutorials für OpenGl den Nutzern nichts mehr

James hat einen C nach Au3. Allerdings nehmen einige Funktionen, wie z.B. die ...fv Arrays auf. Da wäre es gut von Hand nachzubessern. GLEW und allgemein die EXT_... sind auch wichtig für das ganze - schön, dass du dich doch ranwagst

Generell kann man erstmal automatisch konvertieren, dann aber selbst Hand anlegen. Eben wegen den Typen. Einbinden kannst du das als ogl_glew_{functions/constants} direkt nach der eigentlichen (ogl_gl_functions). Dann kannst du als DLL gleich die Konstante mitbenutzen.

Du kannst alle GLFW Befehle weglassen und die alte Funktion nehmen. Allerdings ist dies weder sicher noch gut im Handling. Embedded geht aber nur so. Viellicht füge ich das noch als Extension hinzu.

In jedem Format gibt es Auflistungen der Vertices des Objekts. Die musst du parsen, dann kannst du per glVertex3f() einen Vertex setzten. Es gibt dazu unzählige Tuts, am besten ist dies von NeHe.

Es gibt einen Zauberwürfel - zwölfseitig - der heißt MegaMinx. Mir gefiel >Minx<.

Bis ich entdeckt habe, was minx übersetzt heißt... Da bekommt allerdings auch der Würfel eine falsche Bedeutung

Ich finde keine Spezifikationen dazu im Internet. Aber du kannst dir einen Parser bauen mit der neuen [url=http://autoit.de/index.php?page=Thread&threadID=35697&highlight=]UDF

Sie ist bereits relaesed.

https://autoit.de/index.php?page=Thread&amp;threadID=35697

AutoIt richtig geschrieben und schreibfreudig. Aus dir kann was werden

Das ist ein Microsoft Agent - Character.

@IPU Ih Gitt!!!

_ReplaceStringInFile()

aus der File.au3. [url=http://www.autoitscript.com/autoit3/docs/libfunctions/_ReplaceStringInFile.htm]Hilfeartikel

Vielleicht kannst du das ja mit den Structs verknüpfen, die in der nächsten AutoIt-Version kommen und jetzt schon in der Beta verfügbar sind.

$Meier = Struct
$Meier.Beruf = "Müller"
$Meier.Alter = "42"

[Blockierte Grafik: http://l02.img-up.net/Screenshot8293.jpg]

Hatten wir auch schon. Das liegt wahrscheinlich daran, dass $h immer mehr für spezifische Fälle wie Fenster oder DCs verwendet wird. Es sollte als $hGui, aber $idButton1 heißen.

whatever

Akzeptiere es doch, wenn es in den offiziellen Beispielen steht. GuiGetMsg() gibt kein Handle zurück, sondern eine Zahl, die manchmal ein Handle präsentiert. $h… gilt nur für Funktionen, die ausschließlich Handles zurückgeben, das ist der Standard.

Nene.

GuiGetMsg() gibt manchmal ein Handle zurück, aber immer einen numerischen Wert. Deshalb wird $nMsg genutzt, es ist sinnvoller. Du kannst nicht einfach von den Events absehen.

Nein GuiGetMsg gibt einfach einen numerischen Wert zurück. In diesem Fall geht es dabei um kein Handle. Es kann das Handle aufnehmen, gibt es aber nicht zurück. GuiCreate() gibt ein Handle zurück

Oft durch $nMsg gekennzeichnet. Ich denke, dass ist der Standard.

Bitte beachten: alte UDF ;). Die eigentliche Funktion ist noch kompatibel, allerdings alles um die Gui nicht

Schau dir mal die Beispiele der neuen UDF an, die sind (finde ich) netter

//
Die 3-teilige Sache bringt eigentlich projektspezifisch auch nichts. Meine Meinung wäre: Kurze Einleitung worum es geht, und darauf ein grammatikalisch und rechtschreibmäßig, sowie optisch annehmbar formatierter eigener Text zum Programm. Änderungen sollten nicht mit einem Change-log im Startpost gekennzeichnet werden, dazu sollte man das Skript lieber zippen und eine README sowie CHANGELOG und vlt. TODO Datei hinzufügen. Wenn ein Skript aktualisiert wird, so sollte die neue Änderung stets als neuer Post im Thema erwähnt werden, zum Ersten kann man so die chronografische Entwicklung des Skripts verfolgen und zum Zweiten wird das Thema damit automatisch gepusht, was auch andere auf das Skript hinweist. natürlich darf man dies nicht übertreiben.