PB 2D-Engine
-
- Beiträge: 972
- Registriert: 04.10.2004 18:42
- Computerausstattung: Amiga, LinuxMint, Windows7
- Wohnort: gotha
- Kontaktdaten:
naja, kommt drauf an
entweder du wrappst dx oder gl und erweiterst/erstellst ein paar handliche befehle in einer lib
oder du baust ne chunky2planar engine..aber selbst die wird dann durch eines der beiden oberen dargestellt ^^
entweder du wrappst dx oder gl und erweiterst/erstellst ein paar handliche befehle in einer lib
oder du baust ne chunky2planar engine..aber selbst die wird dann durch eines der beiden oberen dargestellt ^^
amiga rulez...
Rebirth Software
Rebirth Software
- Fluid Byte
- Beiträge: 3110
- Registriert: 27.09.2006 22:06
- Wohnort: Berlin, Mitte
Basierend auf was?Ich wollte eine eigene 2D-Engine baun
PS: Was ist ein Analysing?
Windows 10 Pro, 64-Bit / Outtakes | Derek
wieso zeitaufwändig ?, wie würde dann deine Schleife aussehen?
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
- Fluid Byte
- Beiträge: 3110
- Registriert: 27.09.2006 22:06
- Wohnort: Berlin, Mitte
Nein. Was du meinst ist Antialiasing.Kantenglättung.
Die Frage bleibt, eine 2DEngine basierend auf was? DirectX, OpenGL oder PB's nativen 2D Befehlen?
Windows 10 Pro, 64-Bit / Outtakes | Derek
Es wäre natürlich schön wenn ich mir meine eigene engine programieren könnte, aber muss ich da dx oder gl verwenden? Ich würde es gern alleine nur mit PB machen.
@STARGÅTE
Sorry hab deinen Beitrag übersehen.
@STARGÅTE
Sorry hab deinen Beitrag übersehen.
Code: Alles auswählen
For y=0 To SreenHeight()
For x=0 to ScreenWidth()
;blablabla
Next
Next
Da du scheinbar noch ganz am Anfang stehst würde ich dir raten erstmal ein paar der grundlegendsten dinge zu lernen.
PBs eingebaute Bibliotheken (eine Engine ist etwas anderes) verwenden selbst DirectX. Wenn du weder DirectX noch OpenGL verwenden willst müsstest du deinen Bildschirm Inhalt im Speicher zusammensetzen (was kein Problem ist) und das ganze per BitBlit funktionen des GDI auf das Fenster Bringen, aber dann nutzt du wieder GDI.
Unter Windows zu Programmieren ist was anderes als an einer PDP11 zu hacken. Wenn du keine Zauberelfen zur Verfügung hast wirst du um die Schutzmechanismen des Betriebsystems nicht vorbei kommen. Also wenn du direkt die Hardware Programmieren willst empfehle ich dir DOS, einen DOS-Emulator oder einen C64... alternativ kannst du auch deine eigenen Treiber schreiben, aber dann wirst du ebenfalls auf Purebasic verzichten müssen.
PBs eingebaute Bibliotheken (eine Engine ist etwas anderes) verwenden selbst DirectX. Wenn du weder DirectX noch OpenGL verwenden willst müsstest du deinen Bildschirm Inhalt im Speicher zusammensetzen (was kein Problem ist) und das ganze per BitBlit funktionen des GDI auf das Fenster Bringen, aber dann nutzt du wieder GDI.
Unter Windows zu Programmieren ist was anderes als an einer PDP11 zu hacken. Wenn du keine Zauberelfen zur Verfügung hast wirst du um die Schutzmechanismen des Betriebsystems nicht vorbei kommen. Also wenn du direkt die Hardware Programmieren willst empfehle ich dir DOS, einen DOS-Emulator oder einen C64... alternativ kannst du auch deine eigenen Treiber schreiben, aber dann wirst du ebenfalls auf Purebasic verzichten müssen.
-
- Beiträge: 752
- Registriert: 14.09.2004 21:39
- Kontaktdaten:
Im Allgemeinen ist es aber relativ ratsam bei einer komplett selbstgeschriebenen Engine erst einmal mit dem Zusammensetzen der Grafik Speicher zu beginnen (Software Rendering halt, nur in 2D) und dann mithilfe anderer Libs das Bild auf dem Screen anzeigen zu lassen. Aber wirklich Speed kann man mit der Software-Rendering-Geschichte nur bedingt raushauen. Schreibst du direkt in einem Speicherbereich im VRAM (Grafikkarte) über DirectX, hast du einen sehr langsamen Zugrifff kannst aber bei einfachen Funktionen wie Sprites anzeigen lassen einfache Techniken anwenden, um nicht immer den gesamten Bildschirm neuzeichnen zu müssen. Versuchst du aber dein Bild erst im RAM zusammenzusetzen, wirst du das Problem haben, dass große Auflösungen (z.B. 1024x768) ziemlich lange brauchen, bis sie komplett übertagen worden sind. Dafür kann man auf kleinen Auflösungen mit guter Geschwindigkeit alle möglichen Spielereien verwirklichen.
Es kommt auch oft auf deine Technik des Beschreiben des Bildschirmspeichers an: Zuviel ist zu langsam, Vorberechnen ist speicherfressende und rechenintensive Formeln sind eine starke Belastung für die CPU. In jedem Fall wirst du noch ne ganze Menge lernen müssen, um ne Engine schreiben zu können, die in den Grundlegenden Funktionen mit DX mithält.
Dann kommt noch die Hardware-Beschleunigung hinzu. Nervige Sache. Wenn man es aber ganz rauslässt, ist man (fast) Hardware-Feature-unabhängig. Und genau das ist eine sehr schöne Angelegenheit, vor allem da man wirklich jeden PC von X nach Y mit der Engine versorgen kann.
Es kommt auch oft auf deine Technik des Beschreiben des Bildschirmspeichers an: Zuviel ist zu langsam, Vorberechnen ist speicherfressende und rechenintensive Formeln sind eine starke Belastung für die CPU. In jedem Fall wirst du noch ne ganze Menge lernen müssen, um ne Engine schreiben zu können, die in den Grundlegenden Funktionen mit DX mithält.
Dann kommt noch die Hardware-Beschleunigung hinzu. Nervige Sache. Wenn man es aber ganz rauslässt, ist man (fast) Hardware-Feature-unabhängig. Und genau das ist eine sehr schöne Angelegenheit, vor allem da man wirklich jeden PC von X nach Y mit der Engine versorgen kann.
Also wenn's Dich hauptsächlich nur interessiert, wie das alles so abläuft, dann würde ich einfach ein bißchen was über DirectX usw. lesen. Im Grunde ist es halt so, daß man in den Grafikspeicher schreibt, und dessen Inhalt wird an den Monitor geschickt. Früher hat man eben direkt reingeschrieben, heute macht man das nicht mehr, weil das Betriebssystem einem die Möglichkeit erstmal nicht bietet. Unter DOS z.B. hat man noch direkt adressiert, das ist heute gar nicht mehr möglich. Jedoch hat man dann, damit die Leute zu Win95 wechseln und nicht bei DOS bleiben, DirectX rausgebracht, um den Spieleprogrammierern zumindest auf die begehrten Ressourcen Zugriff zu gewähren.
Die 2D-Library von Purebasic verwendet wie gesagt DirectX, und schreibt dann z.B. wenn Du ein Sprite anzeigst einfach die entsprechenden Pixel-Werte (3 Byte) in den Speicher. Allerdings wird dafür eine Funktion der DirectX-API aufgerufen. Unter Umständen können manche Effekte auch direkt hardwarebeschleunigt realisiert sein, z.B. Alphablending usw. (weiß jetzt nicht, wie das im Falle PB abläuft, aber insgesamt bietet da eben die Hardware oft bestimmte Möglichkeiten, dies wird dann aber auch über die entsprechende DirectX-Funktion geregelt. Transparenz oder sowas muß dann in einem solchen Fall nicht vom Programmierer umgesetzt werden).
Dann ist es noch so, daß heute mit zwei Buffern gearbeitet wird, diese befinden sich jedoch auch direkt auf der Grafikkarte. Das heißt, Du hast den Video-RAM zweimal, und es gibt einen kleinen "Schalter", der bestimmt, welcher gerade beschrieben werden kann. Der andere wird solange auf dem Bildschirm angezeigt. Und diesen Schalter legst Du eben mit "FlipBuffers()" um. Das heißt, Du mußt auch hier kein 2D-Array im normalen RAM benutzen, dieses vollschreiben und dann alles komplett in den Video-RAM reinschreiben, sondern die Hardware unterstützt Dich dabei bereits. Natürlich war auch das früher nicht so, und drum hat man dann oft versucht, nur das neu zu zeichnen, was sich verändert hat. Heute ist das allerdings kein Thema mehr.
Wie gesagt, lies Dich mal ein bißchen durch die Grundlagen durch, da lernst Du sicher einiges dabei und kannst Dir dann nochmal überlegen, inwiefern Du jetzt eine 2D-API / Engine basteln willst.
Die 2D-Library von Purebasic verwendet wie gesagt DirectX, und schreibt dann z.B. wenn Du ein Sprite anzeigst einfach die entsprechenden Pixel-Werte (3 Byte) in den Speicher. Allerdings wird dafür eine Funktion der DirectX-API aufgerufen. Unter Umständen können manche Effekte auch direkt hardwarebeschleunigt realisiert sein, z.B. Alphablending usw. (weiß jetzt nicht, wie das im Falle PB abläuft, aber insgesamt bietet da eben die Hardware oft bestimmte Möglichkeiten, dies wird dann aber auch über die entsprechende DirectX-Funktion geregelt. Transparenz oder sowas muß dann in einem solchen Fall nicht vom Programmierer umgesetzt werden).
Dann ist es noch so, daß heute mit zwei Buffern gearbeitet wird, diese befinden sich jedoch auch direkt auf der Grafikkarte. Das heißt, Du hast den Video-RAM zweimal, und es gibt einen kleinen "Schalter", der bestimmt, welcher gerade beschrieben werden kann. Der andere wird solange auf dem Bildschirm angezeigt. Und diesen Schalter legst Du eben mit "FlipBuffers()" um. Das heißt, Du mußt auch hier kein 2D-Array im normalen RAM benutzen, dieses vollschreiben und dann alles komplett in den Video-RAM reinschreiben, sondern die Hardware unterstützt Dich dabei bereits. Natürlich war auch das früher nicht so, und drum hat man dann oft versucht, nur das neu zu zeichnen, was sich verändert hat. Heute ist das allerdings kein Thema mehr.
Wie gesagt, lies Dich mal ein bißchen durch die Grundlagen durch, da lernst Du sicher einiges dabei und kannst Dir dann nochmal überlegen, inwiefern Du jetzt eine 2D-API / Engine basteln willst.


ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.