| |
|
|
| Hello Sebastian, with this with XProfan 11 correctly performed View source becomes next to the Kubus a red line drawn - but not if one with the Prf2Cpp 2.0a + Borland 5.5 compiled. have You a idea Why the lying? (Types?) CompileMarkSeparationcls
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 | means by me runs the code first of all times under XProfan not at all... guilt on it is the row
glMatrixMode(GL_PROJECTION)
If I The in
ogl(glMatrixMode,~GL_PROJECTION)
change, functions it - too with Profan2Cpp. resolve the with you evtl. already the trouble?
MfG
Sebastian |
|
|
| Windows XP, XProfan/Profan² 4.5 bis 11 Profan2Cpp-Homepage: [...] Alte Profan²-Seite: [...] | 04/05/09 ▲ |
|
|
|
|
| my trouble is, that one Faster Call of z.B. CompileMarkSeparation of Prf2Cpp not works if The Translation so sounds: CompileMarkSeparation?
successful testing could I, that The Funktionsadresse in __cf1& correctly stored is. |
|
|
| |
|
|
|
Sebastian König | iF
of Prf2Cpp not works if The Translation so sounds: (...) successful testing could I, that The Funktionsadresse in __cf1& correctly stored is.
Ah, i think, I see the trouble: The Thread-context is wrong!
to explanation: In with Profan2Cpp übersetzten Program walk fundamentally two Threads, wovon itself of/ one only circa Fensterverwaltung and Nachrichtenschleife kümmert. in the others runs the übersetzte code. and too The OpenGL-things walk in the context this Threads ex. functions, The via Call() and External() called go, walk but fundamentally in the context the first Threads, from the einfachen reason, that this so well How always The secure electoral is (because tappt im dunkeln could Yes Window manipulating).
I have it now not tested, but I would almost bet, that it again functions, if you for Call-row the behaviour explizit änderst: CompileMarkSeparation The bequemere lane is naturally The usage of oGL(glMatrixMode,...) - and if you with Profan2Cpp work, is it neither slower, as your Call-optimization, because I use quasi the same concept. in the .cpp-File become You The row
OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L));
find...
MfG
Sebastian |
|
|
| Windows XP, XProfan/Profan² 4.5 bis 11 Profan2Cpp-Homepage: [...] Alte Profan²-Seite: [...] | 04/05/09 ▲ |
|
|
|
|
| ogl(glMatrixMode,~GL_PROJECTION)
so has us the mr the taught.... |
|
|
| |
|
|
|
| would be but Garbage because explicit lamer...
The opengl32.dll is present and the Funktionsadresse famous - there must still not constantly to Laufzeit first with Strings compared go etc. if one Call still so plenty fixer goes...
@Sebastian: The row OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L)) contain a String which first to Laufzeit aufgedröselt becomes? (the would Yes then with Weitem not so fix.)
there in play calls on OpenGL-functions The rule are what about me very gladly naturally dank xpse The normalen command write would like instead of ogl Fingerwürg Klammer quotation marks command quotation marks... would this Real pity.
I could the XPSE Perhaps procure opengl32-Calls in the $CPP_mode with P2CPP: umzuschreiben - but faktisch can I so first for me again no Prf2Cpp benefit. (somehow goes me the always so) |
|
|
| |
|
|
|
Sebastian König | iF
would be but Garbage because explicit lamer... The opengl32.dll is present and the Funktionsadresse famous - there must still not constantly to Laufzeit first with Strings compared go etc. if one Call still so plenty fixer goes... @Sebastian: The row OGL_direct(GLFN(0, _S(glMatrixMode)), 1, PV(0x1701L)) contain a String which first to Laufzeit aufgedröselt becomes? (the would Yes then with Weitem not so fix.) there in play calls on OpenGL-functions The rule are what about me very gladly naturally dank xpse The normalen command write would like instead of ogl Fingerwürg Klammer quotation marks command quotation marks... would this Real pity. I could the XPSE Perhaps procure opengl32-Calls in the $CPP_mode with P2CPP: umzuschreiben - but faktisch can I so first for me again no Prf2Cpp benefit. (somehow goes me the always so)
Guck you still time the macro GLFN() in the pgl.h on The String becomes only at first appeal once used, around the address To ermitteln; thereafter is the Result always already present and won't new determined. the meant I so, I in the principle The same optimization How You use, with the appendix, that The Adressen only on demand really certainly go...
MfG
Sebastian |
|
|
| Windows XP, XProfan/Profan² 4.5 bis 11 Profan2Cpp-Homepage: [...] Alte Profan²-Seite: [...] | 04/06/09 ▲ |
|
|
|
|
| Have in the momentum no pgl.h To hand, I faith but not that it from the speed since z.B. hardly something ausmacht in the Ggs. to that direct Call on The function - simply because of the detour.
so would it z.B. too very entmutigend and pity, any direct Calls against into in XProfan slower umzuschreiben, so these in Prf2CPP functions.
there the trouble here imho only OpenGL concerns The question, whether You these Calls not right Thread disembark let can or. whom right Thread these Calls receive let can - so that one Call on Sendmessage functions and a call on glViewPort even too. |
|
|
| |
|
|
|
Sebastian König | iF
Have in the momentum no pgl.h To hand, I faith but not that it from the speed since z.B. hardly something ausmacht in the Ggs. to that direct Call on The function - simply because of the detour.
means The pgl.h find You z.B. in the Ordner with the übersetzten code. but here time integrally konkret:
#define GLFN(n,f) (g_Externals[n] ? g_Externals[n] : (g_Externals[n] = pgl_GetProcAddr(f)))
effectively has one means (except for whom first appeal) one direkts Call, because the address already famous is. The String-comparison is with wiederholten Call not any more necessary, because the function eindeutig over the Integer n number is. this happens already at Übersetzen.
iF
so would it z.B. too very entmutigend and pity, any direct Calls against into in XProfan slower umzuschreiben, so these in Prf2CPP functions.
there the trouble here imho only OpenGL concerns The question, whether You these Calls not right Thread disembark let can or. whom right Thread these Calls receive let can - so that one Call on Sendmessage functions and a call on glViewPort even too. Hmm... the trouble thereby is, that these request (possibly with Stringvergleich the Modulnamens...) then with each Call() come off would. only for Spezialfall OpenGL, for furthermore extra the machinery with oGL(...) vorgesehen is, would I means generally new Overhead to introduce. somehow gefällt me the thought not...
the whole is still in the Grunde a XPSE-specialty... can You whom lever not How You already suggested have, properly there set and USE_CALL_ST use?
MfG
Sebastian |
|
|
| Windows XP, XProfan/Profan² 4.5 bis 11 Profan2Cpp-Homepage: [...] Alte Profan²-Seite: [...] | 04/06/09 ▲ |
|
|
|
|
| |
|
| |
|
|
|
Sebastian König | iF
Call_ST(l__cf1, 1, _L(0x1701L));
the ST standing for same thread, So one Call(), the without change in the context the aufrufenden Threads stattfindet.
MfG
Sebastian |
|
|
| Windows XP, XProfan/Profan² 4.5 bis 11 Profan2Cpp-Homepage: [...] Alte Profan²-Seite: [...] | 04/06/09 ▲ |
|
|
|
|
| And if I z.B. by one Inline-ASM in the Inline-Cpp one CALL write, alights this then in the OGL-Thread?
i will simply each detour over Wrapperfunktionen bypass, if already into faster Calls transformed becomes. |
|
|
| |
|
|