| |
| |
|
 | ¡Hola Sebastian, en diesem con XProfan 11 korrekt ausgeführten Ver código fuente se neben el Kubus una rote Linie suscrito - pero no si uno con el Prf2Cpp 2.0a + Borland 5.5 kompiliert. ¿Tiene un Concepto woran el liegt? (Typen?)
KompilierenMarcaSeparacióncls
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 en me se ejecuta el Code primero a veces XProfan garnicht... Schuld daran Es el Línea
glMatrixMode(GL_PROJECTION)
Wenn Yo el en
ogl(glMatrixMode,~GL_PROJECTION)
ändere, funktioniert lo - auch con Profano2Cpp. Löst esto con usted evtl. auch ya el problema?
MfG
Sebastian |
|
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
Sebastian
König | IF
de Prf2Cpp no klappt si la Übersetzung así lautet: (...)
Erfolgreich testen podría Yo, dass el Funktionsadresse en __cf1& korrekt abgelegt es.
Ah, Yo denke, Yo sehe el problema: Der Hilo-Kontext es falso!
A Erläuterung: In con Profano2Cpp übersetzten Programa laufen grundsätzlich zwei Hilos, wovon se uno sólo en Fensterverwaltung y Nachrichtenschleife kümmert. In el otro se ejecuta el übersetzte Code. Und auch el OpenGL-Sachen laufen en el Kontext dieses Hilos de. Características, el via Call() y Externo() aufgerufen voluntad, laufen aber grundsätzlich en el Kontext des ersten Hilos, de el einfachen Grund, dass dies casi siempre el sichere Wahl es (porque ellos könnten sí Ventana manipulieren).
Yo habe lo ahora no getestet, pero yo sería fast wetten, dass lo otra vez funktioniert, si para el Call-Línea el Comportamiento explizit änderst:
KompilierenMarcaSeparación
Der bequemere Weg es natürlich el Verwendung de oGL(glMatrixMode,...) - y si con Profano2Cpp arbeitest, es auch no langsamer, como Su Call-Optimierung, porque Yo verwende quasi el gleiche Konzept. In el .cpp-Expediente wirst Usted el Línea
OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L));
encontrar... 
MfG
Sebastian |
|
| |
| |
| |
|
|
 | ogl(glMatrixMode,~GL_PROJECTION)
So ha uns el Herr el gelehrt....  |
|
| |
| |
| |
|
|
| Wäre aber Müll porque deutlich lahmer...
El opengl32.dll es disponible y el Funktionsadresse bekannt - como muss doch no ständig a Laufzeit sólo con Cuerdas verglichen voluntad etc. si una Call doch así viel fixer va...
@Sebastian: El Línea OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L)) beinhaltet una String welcher sólo a Laufzeit aufgedröselt se? (Das wäre sí entonces en Weitem no así fix.)
Como en Spielen calls en OpenGL-Características el Regel son y yo muy gerne natürlich dank xpse el normalen Befehle escribir möchte en lugar de ogl Fingerwürg Klammer Anführungszeichen Befehle Anführungszeichen... wäre dies echt schade.
Yo podría el XPSE tal vez beibringen opengl32-Calls en el $CPP_mode con P2CPP: umzuschreiben - aber faktisch kann Yo así primero para mich otra vez kein Prf2Cpp nutzen.  (irgendwie va me siempre así) |
|
| |
| |
| |
|
|
Sebastian
König | IF
Wäre aber Müll porque deutlich lahmer... El opengl32.dll es disponible y el Funktionsadresse bekannt - como muss doch no ständig a Laufzeit sólo con Cuerdas verglichen voluntad etc. si una Call doch así viel fixer va... @Sebastian: El Línea OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L)) beinhaltet una String welcher sólo a Laufzeit aufgedröselt se? (Das wäre sí entonces en Weitem no así fix.) Como en Spielen calls en OpenGL-Características el Regel son y yo muy gerne natürlich dank xpse el normalen Befehle escribir möchte en lugar de ogl Fingerwürg Klammer Anführungszeichen Befehle Anführungszeichen... wäre dies echt schade. Yo podría el XPSE tal vez beibringen opengl32-Calls en el $CPP_mode con P2CPP: umzuschreiben - aber faktisch kann Yo así primero para mich otra vez kein Prf2Cpp nutzen. (irgendwie va me siempre así)
Guck Usted doch veces el Makro GLFN() en el pgl.h a Der String se sólo beim ersten Aufruf una vez gebraucht, a Adresse a ermitteln; danach es el Ergebnis siempre ya disponible y no es neu ermittelt. Das meinte Yo así, dass Yo en el Principio el gleiche Optimierung como Usted verwende, con el Ergänzung, dass el Adressen sólo on demand wirklich determinado voluntad...
MfG
Sebastian |
|
| |
| |
| |
|
|
| Hab en el Moment no pgl.h a Hand, Yo glaube pero no dass lo de el Geschwindigkeit her z.B. kaum algo ausmacht en el Ggs. para direkten Call en el Función - simplemente wegen el Umweg.
So wäre lo z.B. auch muy entmutigend y schade, todos direkten Calls wiederum en el en XProfan langsameren umzuschreiben, así esta en Prf2CPP trabajo.
Como el problema hier imho sólo OpenGL betrifft el Cuestión, si Usted esta Calls no en el richtigen Hilo landen dejar kannst o. el richtigen Hilo esta Calls empfangen dejar kannst - así que un Call en SendMessage funktioniert y una call en glViewPort eben auch. |
|
| |
| |
| |
|
|
Sebastian
König | IF
Hab en el Moment no pgl.h a Hand, Yo glaube pero no dass lo de el Geschwindigkeit her z.B. kaum algo ausmacht en el Ggs. para direkten Call en el Función - simplemente wegen el Umweg.
Also el pgl.h findest Usted z.B. en el Ordner con el übersetzten Code. Aber hier veces bastante konkret:
#define GLFN(n,f) (g_Externals[n] ? g_Externals[n] : (g_Externals[n] = pgl_GetProcAddr(f)))
Effektiv ha uno also (salvo el ersten Aufruf) una direkts Call, porque el Adresse ya bekannt es. Der String-Vergleich es en wiederholten Aufrufen no mehr notwendig, porque el Función eindeutig encima el Integer n nummeriert es. Dies geschieht ya beim Übersetzen.
IF
So wäre lo z.B. auch muy entmutigend y schade, todos direkten Calls wiederum en el en XProfan langsameren umzuschreiben, así esta en Prf2CPP trabajo.
Como el problema hier imho sólo OpenGL betrifft el Cuestión, si Usted esta Calls no en el richtigen Hilo landen dejar kannst o. el richtigen Hilo esta Calls empfangen dejar kannst - así que un Call en SendMessage funktioniert y una call en glViewPort eben auch.
Hmm... el problema esta es, dass esta Abfrage (womöglich con Stringvergleich des Modulnamens...) entonces en cada Call() stattfinden sería. Nur para el Spezialfall OpenGL, para el obendrein extra el Mechanismus con oGL(...) vorgesehen es, sería Yo also generell neuen Overhead einführen. Irgendwie gefällt me el Gedanke no...
Das Ganze es doch en el Grunde una XPSE-Spezialität... kannst Usted el Hebel no como Usted ya vorgeschlagen hast, entsprechend hay ansetzen y USE_CALL_ST uso?
MfG
Sebastian |
|
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
Sebastian
König | IF
Call_ST(l__cf1, 1, _L(0x1701L));
Das ST es para same thread, Así que una Call(), el sin Wechsel en el Kontext des aufrufenden Hilos stattfindet.
MfG
Sebastian |
|
| |
| |
| |
|
|
| Und si yo z.B. por una Inline-ASM en el Inline-Cpp una CALL escribir, landet dieses entonces en el OGL-Hilo?
Yo voluntad simplemente cada Umweg encima Wrapperfunktionen umgehen, si ya en el schnelleren Calls umgewandelt se. |
|
| |
| |
| |
|
(2.167)
Deutsch
English
Français
Español
Italia