| |
| |
|
 | allô Sebastian, chez diesem avec XProfan 11 korrekt ausgeführten Voir le texte source wird près de dem Kubus une rote ligne number gezeichnet - mais pas si on avec qui Prf2Cpp 2.0a + Borland 5.5 kompiliert. Avez-vous un concept woran cela liegt? (Typen?)
KompilierenMarqueSéparationcls
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 | alors chez mir fonctionne qui Code zunächst la fois sous XProfan garnicht... Schuld daran ist qui la ligne
glMatrixMode(GL_PROJECTION)
si je qui dans
ogl(glMatrixMode,~GL_PROJECTION)
ändere, funktioniert es - aussi avec Profan2Cpp. Löst cela chez Dir peut-être. aussi déjà cela Problem?
MfG
Sebastian |
|
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
Sebastian
König | iF
de Prf2Cpp pas klappt si le Übersetzung so lautet: (...)
Erfolgreich testen konnte je, dass qui Funktionsadresse dans __cf1& korrekt abgelegt ist.
Ah, je denke, je vois cela Problem: qui Fil-Kontext ist faux!
Zur Erläuterung: dans avec Profan2Cpp übersetzten Programme courir grundsätzlich deux Threads, de quoi sich einer seulement um Fensterverwaltung et Nachrichtenschleife kümmert. dans dem anderen fonctionne qui übersetzte Code. et aussi qui OpenGL-Sachen courir im Kontext cet Threads ab. Funktionen, qui via Call() et Externe() aufgerufen volonté, courir mais grundsätzlich im Kontext des ersten Threads, aus dem einfachen Grund, dass ca si bien comment toujours qui sichere l'élection ist (car vous könnten oui la fenêtre manipuler).
j'ai es maintenant pas getestet, mais je serait presque wetten, dass es wieder funktioniert, si Du pour qui Call-la ligne cela Verhalten explizit änderst:
KompilierenMarqueSéparation
qui bequemere Weg ist naturellement qui Verwendung de oGL(glMatrixMode,...) - et si Du avec Profan2Cpp arbeitest, ist es aussi pas langsamer, comme Votre Call-Optimierung, car je verwende quasi cela gleiche Konzept. dans qui .cpp-Dossier wirst Du qui la ligne
OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L));
trouver... 
MfG
Sebastian |
|
| |
| |
| |
|
|
 | ogl(glMatrixMode,~GL_PROJECTION)
So hat uns qui monsieur cela gelehrt....  |
|
| |
| |
| |
|
|
| Wäre mais Müll weil deutlich lahmer...
qui opengl32.dll ist vorhanden et qui Funktionsadresse bekannt - là muss doch pas ständig zur Laufzeit seulement avec Cordes verglichen volonté etc. si un Call doch so viel fixer allez...
@Sebastian: qui la ligne OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L)) beinhaltet une String quel seulement zur Laufzeit aufgedröselt wird? (cela wäre oui ensuite chez Weitem pas so fix.)
là dans Spielen calls sur OpenGL-Funktionen qui règle sommes et je très volontiers naturellement dank xpse qui normalen Befehle écrivons voudrais statt ogl Fingerwürg Klammer Anführungszeichen Befehle Anführungszeichen... wäre ca vraie tant pis.
je pourrait dem XPSE peut-être beibringen opengl32-Calls im $CPP_mode avec P2CPP: umzuschreiben - mais faktisch peux je avec cela erstmal pour mich wieder ne...aucune Prf2Cpp nutzen.  (irgendwie allez mir cela toujours so) |
|
| |
| |
| |
|
|
Sebastian
König | iF
Wäre mais Müll weil deutlich lahmer... qui opengl32.dll ist vorhanden et qui Funktionsadresse bekannt - là muss doch pas ständig zur Laufzeit seulement avec Cordes verglichen volonté etc. si un Call doch so viel fixer allez... @Sebastian: qui la ligne OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L)) beinhaltet une String quel seulement zur Laufzeit aufgedröselt wird? (cela wäre oui ensuite chez Weitem pas so fix.) là dans Spielen calls sur OpenGL-Funktionen qui règle sommes et je très volontiers naturellement dank xpse qui normalen Befehle écrivons voudrais statt ogl Fingerwürg Klammer Anführungszeichen Befehle Anführungszeichen... wäre ca vraie tant pis. je pourrait dem XPSE peut-être beibringen opengl32-Calls im $CPP_mode avec P2CPP: umzuschreiben - mais faktisch peux je avec cela erstmal pour mich wieder ne...aucune Prf2Cpp nutzen. (irgendwie allez mir cela toujours so)
Guck Dir doch la fois cela Makro GLFN() dans qui pgl.h à qui String wird seulement beim ersten Aufruf einmal gebraucht, à Adresse trop ermitteln; après ist cela Ergebnis toujours déjà vorhanden et wird pas récente ermittelt. cela meinte je avec cela, dass je im Prinzip qui gleiche Optimierung comment Du verwende, avec qui Ergänzung, dass qui Adressen seulement on demand wirklich bestimmt volonté...
MfG
Sebastian |
|
| |
| |
| |
|
|
| Hab im Moment aucun pgl.h trop main, je crois mais pas dass es de qui Geschwindigkeit her z.B. à peine quelque chose ausmacht im Ggs. zum direkten Call sur qui Funktion - simple à cause de dem le détour.
So wäre es z.B. aussi très entmutigend et tant pis, alle direkten Calls wiederum dans qui dans XProfan langsameren umzuschreiben, avec cela cet dans Prf2CPP marcher.
là cela Problem ici imho seulement OpenGL betrifft qui Frage, si Du cet Calls pas im richtigen Fil landen laisser peux bzw. den richtigen Fil cet Calls empfangen laisser peux - so dass un Call sur SendMessage funktioniert et un call sur glViewPort plan aussi. |
|
| |
| |
| |
|
|
Sebastian
König | iF
Hab im Moment aucun pgl.h trop main, je crois mais pas dass es de qui Geschwindigkeit her z.B. à peine quelque chose ausmacht im Ggs. zum direkten Call sur qui Funktion - simple à cause de dem le détour.
alors qui pgl.h findest Du z.B. im Dossier avec dem übersetzten Code. mais ici la fois entier konkret:
#define GLFN(n,f) (g_Externals[n] ? g_Externals[n] : (g_Externals[n] = pgl_GetProcAddr(f)))
effectif hat on alors (jusqu'à sur den ersten Aufruf) un direkts Call, weil qui Adresse déjà bekannt ist. qui String-comparaison ist chez wiederholten Aufrufen pas plus notwendig, weil qui Funktion sans équivoque sur den Integer n nummeriert ist. ca geschieht déjà beim Übersetzen.
iF
So wäre es z.B. aussi très entmutigend et tant pis, alle direkten Calls wiederum dans qui dans XProfan langsameren umzuschreiben, avec cela cet dans Prf2CPP marcher.
là cela Problem ici imho seulement OpenGL betrifft qui Frage, si Du cet Calls pas im richtigen Fil landen laisser peux bzw. den richtigen Fil cet Calls empfangen laisser peux - so dass un Call sur SendMessage funktioniert et un call sur glViewPort plan aussi.
Hmm... cela Problem dabei ist, dass cet Abfrage (womöglich avec Stringvergleich des Modulnamens...) ensuite chez chaque Call() stattfinden serait. seulement pour den Spezialfall OpenGL, pour den obendrein extra qui Mechanismus avec oGL(...) vorgesehen ist, serait je alors generell neuen Overhead einführen. Irgendwie comme mir qui idée pas...
cela Ganze mais est im Grunde une XPSE-Spezialität... peux Du den Hebel pas comment Du déjà vorgeschlagen la hâte, entsprechend là ansetzen et USE_CALL_ST verwenden?
MfG
Sebastian |
|
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
Sebastian
König | iF
Call_ST(l__cf1, 1, _L(0x1701L));
cela ST steht pour same thread, alors un Call(), cela sans change im Kontext des aufrufenden Threads stattfindet.
MfG
Sebastian |
|
| |
| |
| |
|
|
| et si je z.B. per einem Inline-ASM im Inline-Cpp un CALL schreibe, landet cet ensuite im OGL-Fil?
je veux simple jeden le détour sur Wrapperfunktionen tourner autour de, si déjà dans qui schnelleren Calls umgewandelt wird. |
|
| |
| |
| |
|
(790)
Deutsch
English
Français
Español
Italia