| |
| |
|
 | Hallo Sebastian, bei diesem mit XProfan 11 korrekt ausgeführten Quelltext wird neben dem Kubus eine rote Linie gezeichnet - aber nicht wenn man mit der Prf2Cpp 2.0a + Borland 5.5 kompiliert. Hast Du eine Idee woran das liegt? (Typen?)
KompilierenMarkierenSeparierencls
var xx&=width(%hWnd)
var yy&=height(%hWnd)
ogl(init,%hWnd,0,0,0,0)
ogl(posmode,1)
ogl(clear)
ogl(color,3,0,0,3)
ogl(move,0,0,-5)
ogl(cuboid,1,1,1)
ogl(origin,0,0,0)
glMatrixMode(GL_PROJECTION)
ogl.ortho(0,yy&-1,xx&,-1,0-xx&,xx&)
ogl.line(10,10,200,100)
ogl(show)
waitInput
end
proc OGL.ORTHO
PARAMETERS X&,Y&,XX&,YY&,Z&,ZZ&
OGL(glLoadIdentity)
OGL(glViewport,0,0,WIDTH(%HWND),HEIGHT(%HWND))
DECLARE MEM#
DIM MEM#,48
FLOAT MEM#,0=X&,XX&,Y&,YY&,Z&,ZZ&
OGL(glOrtho,LONG(MEM#,0 ),LONG(MEM#,4 ),LONG(MEM#,8 ),LONG(MEM#,12),LONG(MEM#,16),LONG(MEM#,20),LONG(MEM#,24),LONG(MEM#,28),LONG(MEM#,32),LONG(MEM#,36),LONG(MEM#,40),LONG(MEM#,44))
DISPOSE MEM#
endproc
proc OGL.LINE
PARAMETERS X!,Y!,XX!,YY!
OGL(glBegin,1)
OGL(glVertex3f,X!,Y!,0)
OGL(glVertex3f,XX!,YY!,0)
OGL(glEnd)
endproc
|
 |
| |
| |
| |
|
|
Sebastian
König | Also bei mir läuft der Code zunächst mal unter XProfan garnicht... Schuld daran ist die Zeile
glMatrixMode(GL_PROJECTION)
Wenn ich die in
ogl(glMatrixMode,~GL_PROJECTION)
ändere, funktioniert es - auch mit Profan2Cpp. Löst das bei Dir evtl. auch schon das Problem?
MfG
Sebastian |
|
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
Sebastian
König | iF
von Prf2Cpp nicht klappt wenn die Übersetzung so lautet: (...)
Erfolgreich testen konnte ich, dass die Funktionsadresse in __cf1& korrekt abgelegt ist.
Ah, ich denke, ich sehe das Problem: Der Thread-Kontext ist falsch!
Zur Erläuterung: In mit Profan2Cpp übersetzten Programm laufen grundsätzlich zwei Threads, wovon sich einer nur um Fensterverwaltung und Nachrichtenschleife kümmert. In dem anderen läuft der übersetzte Code. Und auch die OpenGL-Sachen laufen im Kontext dieses Threads ab. Funktionen, die via Call() und External() aufgerufen werden, laufen aber grundsätzlich im Kontext des ersten Threads, aus dem einfachen Grund, dass dies so gut wie immer die sichere Wahl ist (denn sie könnten ja Fenster manipulieren).
Ich habe es jetzt nicht getestet, aber ich würde fast wetten, dass es wieder funktioniert, wenn Du für die Call-Zeile das Verhalten explizit änderst:
KompilierenMarkierenSeparieren
Der bequemere Weg ist natürlich die Verwendung von oGL(glMatrixMode,...) - und wenn Du mit Profan2Cpp arbeitest, ist es auch nicht langsamer, als Deine Call-Optimierung, denn ich verwende quasi das gleiche Konzept. In der .cpp-Datei wirst Du die Zeile
OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L));
finden... 
MfG
Sebastian |
|
| |
| |
| |
|
|
 | ogl(glMatrixMode,~GL_PROJECTION)
So hat uns der Herr das gelehrt....  |
|
| |
| |
| |
|
|
| Wäre aber Müll weil deutlich lahmer...
Die opengl32.dll ist vorhanden und die Funktionsadresse bekannt - da muss doch nicht ständig zur Laufzeit erst mit Strings verglichen werden etc. wenn ein Call doch so viel fixer geht...
@Sebastian: Die Zeile OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L)) beinhaltet einen String welcher erst zur Laufzeit aufgedröselt wird? (Das wäre ja dann bei Weitem nicht so fix.)
Da in Spielen calls auf OpenGL-Funktionen die Regel sind und ich sehr gerne natürlich dank xpse die normalen Befehle schreiben möchte statt ogl Fingerwürg Klammer Anführungszeichen Befehle Anführungszeichen... wäre dies echt schade.
Ich könnte dem XPSE vielleicht beibringen opengl32-Calls im $CPP_mode mit P2CPP: umzuschreiben - aber faktisch kann ich damit erstmal für mich wieder kein Prf2Cpp nutzen.  (irgendwie geht mir das immer so) |
|
| |
| |
| |
|
|
Sebastian
König | iF
Wäre aber Müll weil deutlich lahmer... Die opengl32.dll ist vorhanden und die Funktionsadresse bekannt - da muss doch nicht ständig zur Laufzeit erst mit Strings verglichen werden etc. wenn ein Call doch so viel fixer geht... @Sebastian: Die Zeile OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L)) beinhaltet einen String welcher erst zur Laufzeit aufgedröselt wird? (Das wäre ja dann bei Weitem nicht so fix.) Da in Spielen calls auf OpenGL-Funktionen die Regel sind und ich sehr gerne natürlich dank xpse die normalen Befehle schreiben möchte statt ogl Fingerwürg Klammer Anführungszeichen Befehle Anführungszeichen... wäre dies echt schade. Ich könnte dem XPSE vielleicht beibringen opengl32-Calls im $CPP_mode mit P2CPP: umzuschreiben - aber faktisch kann ich damit erstmal für mich wieder kein Prf2Cpp nutzen. (irgendwie geht mir das immer so)
Guck Dir doch mal das Makro GLFN() in der pgl.h an Der String wird nur beim ersten Aufruf einmal gebraucht, um die Adresse zu ermitteln; danach ist das Ergebnis immer schon vorhanden und wird nicht neu ermittelt. Das meinte ich damit, dass ich im Prinzip die gleiche Optimierung wie Du verwende, mit der Ergänzung, dass die Adressen nur on demand wirklich bestimmt werden...
MfG
Sebastian |
|
| |
| |
| |
|
|
| Hab im Moment keine pgl.h zu Hand, ich glaube aber nicht dass es von der Geschwindigkeit her z.B. kaum etwas ausmacht im Ggs. zum direkten Call auf die Funktion - einfach wegen dem Umweg.
So wäre es z.B. auch sehr entmutigend und schade, alle direkten Calls wiederum in die in XProfan langsameren umzuschreiben, damit diese in Prf2CPP funktionieren.
Da das Problem hier imho nur OpenGL betrifft die Frage, ob Du diese Calls nicht im richtigen Thread landen lassen kannst bzw. den richtigen Thread diese Calls empfangen lassen kannst - so dass ein Call auf Sendmessage funktioniert und ein call auf glViewPort eben auch. |
|
| |
| |
| |
|
|
Sebastian
König | iF
Hab im Moment keine pgl.h zu Hand, ich glaube aber nicht dass es von der Geschwindigkeit her z.B. kaum etwas ausmacht im Ggs. zum direkten Call auf die Funktion - einfach wegen dem Umweg.
Also die pgl.h findest Du z.B. im Ordner mit dem übersetzten Code. Aber hier mal ganz konkret:
#define GLFN(n,f) (g_Externals[n] ? g_Externals[n] : (g_Externals[n] = pgl_GetProcAddr(f)))
Effektiv hat man also (bis auf den ersten Aufruf) ein direkts Call, weil die Adresse schon bekannt ist. Der String-Vergleich ist bei wiederholten Aufrufen nicht mehr notwendig, weil die Funktion eindeutig über den Integer n nummeriert ist. Dies geschieht schon beim Übersetzen.
iF
So wäre es z.B. auch sehr entmutigend und schade, alle direkten Calls wiederum in die in XProfan langsameren umzuschreiben, damit diese in Prf2CPP funktionieren.
Da das Problem hier imho nur OpenGL betrifft die Frage, ob Du diese Calls nicht im richtigen Thread landen lassen kannst bzw. den richtigen Thread diese Calls empfangen lassen kannst - so dass ein Call auf Sendmessage funktioniert und ein call auf glViewPort eben auch.
Hmm... das Problem dabei ist, dass diese Abfrage (womöglich mit Stringvergleich des Modulnamens...) dann bei jedem Call() stattfinden würde. Nur für den Spezialfall OpenGL, für den obendrein extra der Mechanismus mit oGL(...) vorgesehen ist, würde ich also generell neuen Overhead einführen. Irgendwie gefällt mir der Gedanke nicht...
Das Ganze ist doch im Grunde eine XPSE-Spezialität... kannst Du den Hebel nicht wie Du schon vorgeschlagen hast, entsprechend dort ansetzen und USE_CALL_ST verwenden?
MfG
Sebastian |
|
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
Sebastian
König | iF
Call_ST(l__cf1, 1, _L(0x1701L));
Das ST steht für same thread, also ein Call(), das ohne Wechsel im Kontext des aufrufenden Threads stattfindet.
MfG
Sebastian |
|
| |
| |
| |
|
|
| Und wenn ich z.B. per einem Inline-ASM im Inline-Cpp ein CALL schreibe, landet dieses dann im OGL-Thread?
Ich will einfach jeden Umweg über Wrapperfunktionen umgehen, wenn schon in die schnelleren Calls umgewandelt wird. |
|
| |
| |
| |
|
(948)
Deutsch
English
Français
Español
Italia