English
C ++ Forum

Done: glOrtho fails?

 
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?)
CompileMarkSeparation
cls
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


1.032 kB
Kurzbeschreibung: XProfan11
Hochgeladen:04/05/09
Downloadcounter159
Download
5 kB
Hochgeladen:04/05/09
Downloadcounter232
Download
307 kB
Kurzbeschreibung: prf2cpp2.0a
Hochgeladen:04/05/09
Downloadcounter119
Download
 
04/05/09  
 




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.
 
04/05/09  
 




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
P2CPP: <USE_CALL_ST>
call(__cf1&,$1701)
P2CPP: </USE_CALL_ST&g
re>

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....
 
04/06/09  
 



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)
 
04/06/09  
 




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.
 
04/06/09  
 




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  
 




CompileMarkSeparation
P2CPP: <USE_CALL_ST>
call(__cf1&,$1701)
P2CPP: </USE_CALL_ST&g
re>

would then To welchem c++-Source konvertiert go?
 
04/06/09  
 




Sebastian
König
iF

CompileMarkSeparation
P2CPP: <USE_CALL_ST>
call(__cf1&,$1701)
P2CPP: </USE_CALL_ST&g
re>

would then To welchem c++-Source konvertiert go?


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.
 
04/06/09  
 




Answer


Topictitle, max. 100 characters.
 

Systemprofile:

no Systemprofil laid out. [anlegen]

XProfan:

 Posting  Font  Smilies  ▼ 

Please register circa a Posting To verfassen.
 

Topic-Options

13.147 Views

Untitledvor 0 min.
Sven Bader07/25/21
funkheld05/25/16
iF11/09/11

Themeninformationen



Admins  |  AGB  |  Applications  |  Authors  |  Chat  |  Privacy Policy  |  Download  |  Entrance  |  Help  |  Merchantportal  |  Imprint  |  Mart  |  Interfaces  |  SDK  |  Services  |  Games  |  Search  |  Support

One proposition all XProfan, The there's!


My XProfan
Private Messages
Own Storage Forum
Topics-Remember-List
Own Posts
Own Topics
Clipboard
Log off
 Deutsch English Français Español Italia
Translations

Privacy Policy


we use Cookies only as Session-Cookies because of the technical necessity and with us there no Cookies of Drittanbietern.

If you here on our Website click or navigate, stimmst You ours registration of Information in our Cookies on XProfan.Net To.

further Information To our Cookies and moreover, How You The control above keep, find You in ours nachfolgenden Datenschutzerklärung.


all rightDatenschutzerklärung
i want none Cookie