DirektX

Re: DirektX

Beitragvon Mathias » 22. Dez 2017, 20:58 Re: DirektX

Dass GDI Funktionen hardwarebescleunigt sind, habe ich bis vorhin nicht gewusst.

Dies ist wie wirklich sehr stark System abhängig, anscheinend hat M$ da einen Rückschritt gemacht.

https://de.wikipedia.org/wiki/3dfx_Voodoo_Banshee
https://de.wikipedia.org/wiki/Graphics_Device_Interface

Ich schätze ein,, dass hier die Vektorrechnung mein Freund ist. Oder braucht es noch mehr?

Das ist OpenGL dein Freund.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 3708
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon thosch » 23. Dez 2017, 11:51 Re: DirektX

Nein, auch mit FPC 3.0.4 funktioniert das Beispiel nicht. Dieselbe Fehlermeldung wie vorher. Die lautet:

Project hat Exception-Klasse TPTCError ausgelöst mit der Meldung "Cannot recycle because it is not alredy open"

Sowohl mit Version 3.0.2 als auch mit Version 3.0.4, mit der Du übersetzt haben willst.

Wie also kann ich von console.Open() aus eine andere Grafikengine, egal ob Open GL, nacktes GDI oder sonstwas einstellen, damit das Beispiel läuft. Ich bin doch schon im Grafikmodus unter Windows auf der GUI. Warum muss das da so kompliziert sein???

Muss da noch irgendwas mit Console.Configure(Filename) irgendwas gemacht werden? Wenn ja, was muss da in die config Datei rein, damit das Beispiel funktioniert, die Konsole ordnungsgemäß geöffnet wird? Es gibt doch die Datei ptcpas.cfg. Welche Optionen muss ich dort durch Löschen des vorangestellten Zeichens "#" einschalten, damit das Beispiel läuft???

Sag mal, kannst Du mir mal bitte die übersetzte PTC zukommen lassen. Vielleicht kann ich die .o Datei(en) der PTC Unit(s) verwenden und verlinken und mir dann einfach eine Interface Unit schreiben mit den nötigen PTC Routinen, die ich dann halt mit der External Klausel versehe. Mit {$L ptc.o} {$L hermes.o} ... kann ich mir ja dann diese Funktionen auch verfügbar machen.
Sollte es damit nicht Objektorientiert gehen, ist ja noch die C_API Schnittstelle da.

Wäre zumindest ein Versuch wert, wenn das Beispiel bei Dir wirklich funktioniert hat. Dann schick mir mal die überestzten binaries für alle Plattformen (GO32,Windows und Linux). Vielleicht komme ich damit weiter. Welches Objektformat (ELF, COFF, ...) wird denn auf den einzelnen Plattformen eigentlich benutzt.

Eine Systemabhängige Initialisierung einer passdenden Grafikschnittstelle sollte anderenfalls erst mal reichen. Hauptsache, ich kriege die PTC zum Laufen.

Ich glaube nicht, dass OpenGL problemloser funktioniert, probier ich aber dennoch später irgendwann mal aus. Allerdings ist mir dabei auch klar, dass ich nach den ersten Gehversuchen vielleicht ganz stolz meine erste 3D Animation präsentieren will, die dann aber für die gestandenen OpenGL Profis eher wie das Hello World Programm daher kommen wird. Wie hier jetzt meine Idee mit dem FPPixlCanv, dieses als Grafikgrundlage zu verwenden.

In OpenGL muss ich mich allerdings ab Punkt NULL komplett neu einarbeiten. Mit PTC habe ich dagegen schon mal mit früheren FPC Versionen programmiert. Deshalb will ich jetzt erst mal PTC, für das was ich mit der Grafik machen will reicht das komplett aus, eine Umschulung auf OpenGL ist da viel zu aufwendig.

Du hast erzählt, Du hättest mit FPC 3.0.4 erfolgreich übersetzt und das Beispiel würde problemlos laufen. Bei mir tut es das nicht. AKtuelles Windows Update, Win10. Heute Morgen die 32 Bit Version von Lazarus 1.0.8 mit Freepascal 3.0.4 installiert. Die 64 Bit Version kommt später dran, spätestens falls Dein FPC Compiler 3.0.4, mit dem Du mein PTC Beispiel funktionsfähig übersetzt hast, die 64 Bit Version ist. Sonst tut es jetzt für mich auch der 32 Bit Compiler. Am Ende stelle ich auf Open GL um, habe Aufwand weil Unitpfade nicht gefunden werden, muss dann mühsam die fehlenden Unitpfade bekannt machen, um dann wiederum festzustellen, das es auch nicht funktioniert. Nein, ich habe in PTC schon zu viel Zeit und Nerven investiert, ich will es damit machen. Ich muss nicht mit irgendwas brandaktuellem kompatibel sein, ich mach das alles ohne Bezahlung im meiner kostbaren Freizeit. Für Linux reicht zur Not die langsamere Unit Graph, da die unter Linux auch svgalib aufsetzt, die ja recht schnell sein soll. Daher ist es mir eher wichtig, dass PTC unter Windows läuft.

Für Plattformübergreifende Sachen nutze ich bedingte Kompilierung:

{$ifdef USE VENOMGFX}
//diese Grafikengine nutzt auch Direct X, es knallt beim Initialisieren der Grafikschnittstelle.
//vielleicht funktioniert es ja mit einer viel älteren FPC Version, wie 2.6.4 oder gar 2.0.0, die habe ich auch noch da. Könnte die auch im Zweifelsfall weiter geben, wenn ein anderer Interessent meiner Grafikschnittstelle auftaucht. Habe auch noch alle alten Lazarus-Versionen vorrätig.
VenomGFX ist eine sehr leistungsfähige Spriteengine.
{$endif}
{$ifdef USE GRAPH}
//kompatibel aber sehr langsam, dürfte wegen svgalib aber in Linux reichen, da svgalib sehr schnell ist, zumindest laut svgalib-Team
{$endif}
{$ifdef USE_PTC}
//das will ich aktuell implementieren
{/endif}
{$ifdef USE_SVGALIB}
//hiermit könnte unter Linux auch die svgalib direkt verwendet werden
{$endif}

Was ich dann noch implementieren muss, ist entweder ein Wrapper für all die verfügbaren Grafikfunktionen oder einer der letztlich FPPixlCanv verwendet, dann brauche ich von der jeweiligen Grafikengine nur die PutPixel() Funktion, eventuell noch Funktionen wie Bogen, Tortenstück, ..., die FpPixlCanv noch nicht anbietet. Schade, dass das offenbar niemand anderes braucht. Aber ich brauche es.

Wie also stelle ich dort für PTC eine andere als die standardmäßig initialisierte Grafikschnittstelle ein. Zur Not das stinknormale GDI, denn Windows basiert ja darauf. Klar könnte ich dann ja auch FppixlCanv gleich mit GDI Funktionen implementieren. Ich will es aber mit PTC machen. PTC ist dazu ausreichend systemunanhängig.

Habe schon

console.OpenGL_Enabled := true

ausprobiert. Leider ohne Erfolg. Meldung "IPTCError -> OpenGL wird von PTC nicht unterstützt!

Dies trotz der in PTC vorhandenen OpenGL Schnittstelle.

Mathias hat geschrieben:Dies ist wie wirklich sehr stark System abhängig, anscheinend hat M$ da einen Rückschritt gemacht.


Logisch, ist ja Windows. Das basiert auf GDI wie XServer auf X11. Ich wüsste nicht was da plattformunabhängig sein sollte.



Da werd ich mich reinlesen.

Mathias hat geschrieben:Das ist OpenGL dein Freund.


Noch nicht, wenn ich erst mal verstehen will, wie die Grafikengine arbeitet. Da muss ich im Fall OpenGL auch in den Unitquelltext schauen, wie zum Beispiel die Funktion gl_vertex implementiert ist. Diese Funktion muss ja ihre Werte irgendwie berechnen.

Habe Abitur und mich nach der Ausbildung autodidaktisch vor langer Zeit mit Vektorrechnung, Analysis, Komplexen Zahlen und anderem Zeig beschäftigt, das nicht alles im Abiturlehrplan enthalten war. Will das verschüttete Wissen mal wieder etwas reaktivieren. Nur mit Mathebuch lernen, ist mir aber zu stupide. Wenn ich aber Grafikquelltexte verstehen will, werd ich da nicht drumrum kommen, aber es ist ja dann für was wirklich praktisches, für eine wirkliche Anwendung. Und ich kann das reaktivierte Wissen dann gleich praktisch anwenden. Wenn ich dagegen einfach gl_vertex() aufrufe, weiß ich immer noch nicht, wie diese Funktion intern arbeitet.
thosch
 
Beiträge: 94
Registriert: 10. Jul 2017, 19:32

Beitragvon Mathias » 1. Jan 2018, 16:28 Re: DirektX

Anscheinend läuft es bei dir mit einem altem FPC.

viewtopic.php?f=13&t=11330


Project hat Exception-Klasse TPTCError ausgelöst mit der Meldung "Cannot recycle because it is not alredy open"
Ich konnte dein Fehler gerade nachvollziehen, ich habe es gearde in der VB mit WinXP probiert. Dies konnte ich dazumal nicht testen, da meine VB nicht mehr funktionierte.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 3708
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon thosch » 1. Jan 2018, 17:12 Re: DirektX

Mathias hat geschrieben:Anscheinend läuft es bei dir mit einem altem FPC.

viewtopic.php?f=13&t=11330


Project hat Exception-Klasse TPTCError ausgelöst mit der Meldung "Cannot recycle because it is not alredy open"
Ich konnte dein Fehler gerade nachvollziehen, ich habe es gearde in der VB mit WinXP probiert. Dies konnte ich dazumal nicht testen, da meine VB nicht mehr funktionierte.


Das Problem ist hausgemacht. Ihr brauchtet nur die alten Compilerfeatures der vorherigen Version so zu belassen, wie sie sind, dann gäbe es das Problem der fehlenden Aufwärtskompatibilität gar nicht. Dann müsstet Ihr nur die neuen Features der nächsten Cpmpilerversion ergänzen und alles was vorher war würde weiterhin funktionieren. So aber nützt mir di8e brandneue Compilerversion nichts. Ich brauche die alten Versionen. WSeil nur damit die alten Bibliotheken wiederverwendbar sind.

Schön, dass Du meinen Fehler jetzt endlich nachvollziehen konntest. Für mich leider zu spät, ich nutze nun eben die ältere Version. Ja da funktioniert das Beispiel. Nur mit der neuen Version nicht. Deshalb habe ich ja auch gefragt, ob es nicht auch eine Möglichkeit mit der GDI Console gibt, die ja funktionieren sollte. oder die .o Daeien der funktionierenden Version oder einer funktionierenden Version. Oder mit Entfernen der richtigen Kommentarkreuze in der Datei ptcpas.cfg!

Warum ist das so kompliziert sobald es um ältere Grafik geht. Ich wollte damit wirklich nur die Beispiele ausprobieren. Für eine GUI mit DOS müsste ich zwingend die Unit Graph verwenden, weil im ppc8086 nur diese Unit nach 16 Bit portiert wurde.
Würde ich da jetzt mit Venomgfx oder PTC anfangen, müsste ich meine GUI dann für die Verwendung der Unit Graph nochmals bauen. Ich wollte also wirklich nur die Beispiele in PTC/examples mal ausprobieren.

Allerdings hatte ich auch schon Fälle wo auch alte Textmode- oder Kommandozeilenprogramme unter GO32 mit neuerem FPC Compiler nicht mehr funktioniert haben. Mit dieser Praxis ist also nicht nur die Grafik gefährdet sondern die Verwendbarkeit des DOS Compilers ganz allgemein. Es ist daher für das Projekt allemal besser, wenn Auf- und Abwärtskompatibilität gewahrt bleibt.

Habe mir für die 16Bit Compilierung sicherheitshalber schon mal alle aktuellen Versionen des ppc8086 runter geladen, einschließlich der vorkompilierten Units. Einer meiner Computerfreunde spielt die alten DOS Spiele und programmiert auch eigene. Der braucht das dann. Und ich habe noch einen alten WIN98 Rechner.

Habe mal bissl hier im Fotum gestöbert. Scheint so dass auch andere User hier an DOS Grafik interessiert sind.

Die brauchen dann halt die älteren Versionen des Compilers.
thosch
 
Beiträge: 94
Registriert: 10. Jul 2017, 19:32

Beitragvon Mathias » 1. Jan 2018, 17:43 Re: DirektX

Schön, dass Du meinen Fehler jetzt endlich nachvollziehen konntest.

Ich habe gerade noch etwas entdeckt. Die Fehlermeldung kommt irgendwie von Lazarus. Wen ich die EXE direkt im Explorer starte, dann läuft es ohne Fehlermeldung.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 3708
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Mathias » 26. Jan 2018, 18:50 Re: DirektX

@thosch

Ich habe gerad etwas entdeckt, was dich interessieren dürfte.
Hast du dir die Unit PTCGraph mal angeguckt ?
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 3708
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon marcov » 26. Jan 2018, 22:14 Re: DirektX

af0815 hat geschrieben: . Es gibt auch Pakete für höhere Versionen, wenn man sucht.


http://clootie.ru/ hat DX10
marcov
 
Beiträge: 1024
Registriert: 5. Aug 2008, 08:37
Wohnort: Eindhoven (Niederlande)
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk) | 
CPU-Target: 32/64,PPC(+64), ARM
Nach oben

• Themenende •
Vorherige

Zurück zu Windows



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

porpoises-institution
accuracy-worried