Jump to content
Eternal Lands Official Forums
Fedora

1.5 vs 1.6 graphic engine & Mac

Recommended Posts

Since the introduction of the new graphic engine (shader, vertex program), i had massive frame drop everytime i move the camera, togheter with hd spinning. Both go away in console mode, so i guess is a graphic issue. Moreover the spinning and fps drop get worse with compiled vertex array and vertex buffer object. My hardware is quite old (ati mobility radeon 9200 32mb on a ppc mac). The 1.5 client works smoothly.

 

I would like to investigate my issues, any idea where to start or what the problem might be?

 

Would also be nice to know if uvp 0 means that the client is using the old (1.5) graphic functions (doesnt seem so).

 

I read that Mac virtualizes video ram, so you can load all the stuff you want, and is up to the system to copy what is needed in the vram. I found this while searching the net for a possible solution. I'm an OpenGL n00b, can hardly draw a polygon, but the article seems quite pertinent...feedback from an expert is appreciated :devlish:

 

 

 

Tnx.

Share this post


Link to post
Share on other sites

Eternal Lands is built upon SDL, so to a certain extent we are at the mercy of the SDL programmers to provide an optimized library for graphics. As you, Florian, and I all know, Apple is also not great about updating drivers, especially those for OpenGL.

 

The game also keeps evolving rapidly. Starting with release 1.4, a significant increase in graphics performance was demanded of all computers. With the adoption of eye candy and now shaders, the demands are increasing at an alarming rate from the perspective of Mac users. I managed to keep the game working for quite some time, but my free time is now mostly consumed with other (translated more profitable) activities. That being said, I am toying around with bringing EL to the iPhone and iPod touch. Are there any venture capitalists out there willing to support a free game?

 

The single best thing to do IMNSHO would be porting EL to Cocoa, leveraging Mac's native graphics routines, and removing SDL (at least for graphics). I was previously investigating this possibility, but it was at a time where the OpenGL code was rapidly changing, and I was having trouble just getting the regular SDL-based build functioning. However, by doing so, it would make EL on the iPhone/iPod-touch a possibility.

 

For the next few releases, if the other developers could be convinced to focus on improving the quality of the models or other non-OpenGL based code, there might be enough time to bring EL to Mac natively.

 

Well, that is how I see it.

Share this post


Link to post
Share on other sites

Some eye candy effects really drop the frame rate, I think the particle size is the lever, but I'll investigate that. (which means, play around, trial and error and hope to find something)

 

EL on the iPhone: I'll be glad to alpha test :P

Share this post


Link to post
Share on other sites

I have poor man on, so eye candy is not an issue atm. Is there a way to see if the disk spinning is actually page swapping and what data is being swapped? Should i also do an Opengl profiling on both clients (and look for what)?

 

With EL on the IPhone my life would be ruined...pls go for it :P

Edited by Fedora

Share this post


Link to post
Share on other sites

UVP means the client is using the CPU for the actors rendering and animation, rather than the GPU.

The water shaders can make a big difference.. the new selection might also slow down stuff. I am nticing a 10% or so performance decrease for me, but others reported a performance increase with the new selection.

Other than that, nothing changed (except that the camera and actors animation is done outside the timer).

 

BTW, I wanted to ask, who can build a new MAC client for this coming update?

Share this post


Link to post
Share on other sites

Regarding porting it on other devices, such as the Iphone, that might be problematic, because after this update we want to focus more on performance and nicer graphics, so this will mean that better hardware will be needed. This will take probably over 1 year, so by that time people should be able to update their systems. We will, however, try to maintain some level of compatibility with older hardware, but vertex programs support might become mandatory (unless someone plans to write a CPU path for the whole new engine).

Share this post


Link to post
Share on other sites
Fedora, that is great :omg:

0ctane, did you see this: http://www.kpcb.com/initiatives/ifund/index.html ?

I can still do universal binaries, but it might be better if I passed the torch off to Fedora. I can still help with technical issues or if he has problems with the build.

 

Yeah, I saw that iFund thing. Since there is no real income model for EL, I doubt it would qualify. Although, if I did pursue an iPhone build, I would ask users for a small fee to recover the $99 Apple fee required to even test out code on a iPhone/iPod touch.

 

The iPhone runs on a version of OpenGL 1.5. If the EL codebase allowed for a new "poorman" that capped at version 1.5, then a port to iPhone would still be possible. However, I do understand your desire to make EL as pretty as possible. I think you know that I like a challenge (and EL has been a big one), but "EL-2-go" might be pretty sweet. I have Awn interested in helping too. Time and money....

 

Anyhow, probably should get back to the thread topic. I think a reasonable "poorman" should allow for Mac support into the future. Mac users just need to realize that they don't really have a gaming machine, and they cannot necessarily expect to have all the bells and whistles.

Share this post


Link to post
Share on other sites
I can still do universal binaries, but it might be better if I passed the torch off to Fedora. I can still help with technical issues or if he has problems with the build.

 

Anyhow, probably should get back to the thread topic. I think a reasonable "poorman" should allow for Mac support into the future. Mac users just need to realize that they don't really have a gaming machine, and they cannot necessarily expect to have all the bells and whistles.

 

Well, i can compile universal binaries, but i'm not qualified enough to code for the mac (and dont have time to learn), so your expertise is still needed.

 

And yes, my post is not about poor performances on a not enough powerful machine...i'm just puzzled by the fact that the new client, even with poorman, uvp 0 and sky&selection disabled runs noticeably slower than the previous (1.5=30fps, 1.6=15fps dropping to 2-5).

 

Today i tried the cvs with "render mesh" disabled (no actor drawing)...and the spinning+frame drop is still there. So it is not the actor rendering....any other part of the code beside graphics, has been changed?

Edited by Fedora

Share this post


Link to post
Share on other sites

The latest CVS has a problem, it takes like 400MB, we are not sure why it does that.

Did the previous versions of the CVS (like until a week ago) work for you better?

 

0ctane, I can fork some money for the Iphone version, if you are really serious about it.

Share this post


Link to post
Share on other sites
The latest CVS has a problem, it takes like 400MB, we are not sure why it does that.

Did the previous versions of the CVS (like until a week ago) work for you better?

 

I think the versions before I went to Hong Kong were better, that means mid January.

Share this post


Link to post
Share on other sites
The latest CVS has a problem, it takes like 400MB, we are not sure why it does that.

Did the previous versions of the CVS (like until a week ago) work for you better?

 

I think the versions before I went to Hong Kong were better, that means mid January.

 

exactly...i noticed it in january but i waited to post because it was still experimental code. And i have 768Mb of ram, so i'm quite prone to the problem.

Share this post


Link to post
Share on other sites
Is this MAC related, or also happens on Linux/Windows?

I'd say also on windows, RC11 is slower that 1.5.0patched, but on windows I have no CVS client and can't disable certain features.

 

/EDIT:

by "this" I mean the graphics performance, not the memory usage

Edited by Florian

Share this post


Link to post
Share on other sites
Is this MAC related, or also happens on Linux/Windows?

EL's (today's CVS) currently using about 730 MB on my linux machine (gentoo linux, amd64)

Share this post


Link to post
Share on other sites
Is this MAC related, or also happens on Linux/Windows?

EL's (today's CVS) currently using about 730 MB on my linux machine (gentoo linux, amd64)

 

Mine is pretty much stable:

 

alvieboy 6521 18.1 7.0 212156 145988 pts/1 SLl+ 18:56 3:16 ./el.x86.linux.bin.new

 

So this is surely some option you have that I do not.

 

Can you email me your make.conf to alvieboy <at> alvie <dot> com ?

 

Álvaro

Share this post


Link to post
Share on other sites
Is this MAC related, or also happens on Linux/Windows?

 

The current Windows CVS right now uses 186MB while harvesting turquoise in Arius.

 

But I'm not sure if the memory usage goes up when fighting a lot or when you're on different maps

Share this post


Link to post
Share on other sites

This is the output from Apple's OpenGL profiler app, walking around PL and casting some Eye Candy effects.

(put it in Excel or some other spreadsheet)

 

GL Function;# of Calls;Total Time (µsec);Avg Time (µsec);% GL Time;% App Time
glTexImage2D;222;1369398;6168.46;50.76;2.54
glBegin;52.003;354851;6.82;13.15;0.66
glDrawElements;8.654;266877;30.84;9.89;0.49
CGLFlushDrawable;231;133507;577.95;4.95;0.25
glDrawRangeElements;10.692;95725;8.95;3.55;0.18
glTexImage3D;1;53425;53425.22;1.98;0.10
glVertex3i;186.837;39138;0.21;1.45;0.07
glVertex3f;176.372;36981;0.21;1.37;0.07
glTexCoord2f;337.256;34081;0.10;1.26;0.06
glBufferData;825;30828;37.37;1.14;0.06
glEnd;52.002;29128;0.56;1.08;0.05
glPushMatrix;46.757;19432;0.42;0.72;0.04
glRotatef;33.781;16211;0.48;0.60;0.03
glCreateProgramObjectARB;8;15304;1913.04;0.57;0.03
glBindTexture;39.992;15188;0.38;0.56;0.03
glPopAttrib;771;13477;17.48;0.50;0.02
glCompileShaderARB;8;13045;1630.71;0.48;0.02
glClear;292;12556;43.00;0.47;0.02
glReadPixels;20;11942;597.11;0.44;0.02
glDisable;30.102;11483;0.38;0.43;0.02
glPopMatrix;46.754;11040;0.24;0.41;0.02
glGetFloatv;24.141;9987;0.41;0.37;0.02
glEnable;32.768;8332;0.25;0.31;0.02
glVertex3d;27.156;7674;0.28;0.28;0.01
glMultMatrixf;28.094;7085;0.25;0.26;0.01
glPushAttrib;772;6893;8.93;0.26;0.01
glBindBuffer;12.442;5821;0.47;0.22;0.01
glBlendFunc;39.891;5693;0.14;0.21;0.01
glEnableClientState;25.811;5299;0.21;0.20;0.01
glDrawArrays;248;5273;21.26;0.20;0.01
glPointSize;20.620;5254;0.25;0.19;0.01
glColor4f;41.122;5134;0.12;0.19;0.01
glDisableClientState;12.241;3812;0.31;0.14;0.01
glTranslatef;12.484;3799;0.30;0.14;0.01
glLoadIdentity;13.025;3385;0.26;0.13;0.01
glColor3f;23.797;2905;0.12;0.11;0.01
glVertexPointer;13.490;2635;0.20;0.10;0.00
glTexCoordPointer;11.357;2614;0.23;0.10;0.00
glGetDoublev;3.703;2597;0.70;0.10;0.00
glNormalPointer;11.213;2105;0.19;0.08;0.00
glMatrixMode;7.379;1668;0.23;0.06;0.00
glLockArraysEXT;4.836;1662;0.34;0.06;0.00
glLoadMatrixf;6.775;1199;0.18;0.04;0.00
glAlphaFunc;7.838;1047;0.13;0.04;0.00
glDeleteTextures;14;922;65.90;0.03;0.00
glLinkProgramARB;8;919;114.98;0.03;0.00
glProgramStringARB;1;905;905.60;0.03;0.00
glOrtho;2.167;892;0.41;0.03;0.00
glGetIntegerv;1.868;870;0.47;0.03;0.00
glLightfv;1.997;818;0.41;0.03;0.00
glDepthFunc;5.075;756;0.15;0.03;0.00
glViewport;880;584;0.66;0.02;0.00
glTexEnvfv;2.011;581;0.29;0.02;0.00
glUnlockArraysEXT;4.836;558;0.12;0.02;0.00
glTexParameteri;642;445;0.69;0.02;0.00
glInterleavedArrays;124;342;2.76;0.01;0.00
glColor4ubv;1.991;321;0.16;0.01;0.00
glCopyTexImage2D;1;301;301.66;0.01;0.00
glNormal3f;1.331;285;0.21;0.01;0.00
glGenBuffers;824;282;0.34;0.01;0.00
glScalef;498;230;0.46;0.01;0.00
glVertex2i;412;212;0.52;0.01;0.00
glTexGenfv;248;186;0.75;0.01;0.00
glTexGeni;248;165;0.67;0.01;0.00
glVertex2f;569;143;0.25;0.01;0.00
glGenTextures;225;129;0.57;0.00;0.00
glTexEnvi;264;126;0.48;0.00;0.00
glShaderSourceARB;8;102;12.76;0.00;0.00
glDepthMask;312;86;0.28;0.00;0.00
glBindRenderbufferEXT;7;82;11.74;0.00;0.00
glClearColor;148;80;0.54;0.00;0.00
glActiveTexture;288;75;0.26;0.00;0.00
glTexParameterf;99;67;0.68;0.00;0.00
glLineWidth;416;57;0.14;0.00;0.00
glBindProgramARB;1;57;57.05;0.00;0.00
glLineStipple;104;51;0.50;0.00;0.00
glBindFramebufferEXT;22;50;2.28;0.00;0.00
glFramebufferTexture1DEXT;7;42;6.11;0.00;0.00
glTexEnvf;104;39;0.38;0.00;0.00
glHint;90;37;0.41;0.00;0.00
glTexImage1D;1;35;35.69;0.00;0.00
glDeleteFramebuffersEXT;8;34;4.27;0.00;0.00
glReadBuffer;25;23;0.95;0.00;0.00
glGetObjectParameterivARB;32;22;0.72;0.00;0.00
glDeleteRenderbuffersEXT;5;20;4.10;0.00;0.00
glClientActiveTexture;60;15;0.26;0.00;0.00
glColor3fv;152;14;0.10;0.00;0.00
glFramebufferTexture2DEXT;11;11;1.07;0.00;0.00
glGenFramebuffersEXT;11;10;0.97;0.00;0.00
glMaterialfv;3;9;3.28;0.00;0.00
glGetString;4;9;2.27;0.00;0.00
glLightf;12;9;0.76;0.00;0.00
glGenRenderbuffersEXT;7;9;1.29;0.00;0.00
glDrawBuffer;4;8;2.04;0.00;0.00
glFrontFace;1;7;7.50;0.00;0.00
glCreateShaderObjectARB;8;7;0.93;0.00;0.00
glScissor;1;6;6.75;0.00;0.00
glClearStencil;1;5;5.70;0.00;0.00
glAttachObjectARB;8;4;0.61;0.00;0.00
glFramebufferRenderbufferEXT;7;3;0.49;0.00;0.00
glDeleteObjectARB;8;1;0.20;0.00;0.00
glFrustum;2;1;0.71;0.00;0.00
glShadeModel;1;1;1.28;0.00;0.00
glGetError;2;1;0.59;0.00;0.00
glGenProgramsARB;1;1;1.15;0.00;0.00
glGetProgramivARB;3;1;0.36;0.00;0.00
glMultMatrixd;2;0;0.38;0.00;0.00
glCullFace;1;0;0.49;0.00;0.00
CGLSetSurface;1;0;0.00;0.00;0.00
CGLSetParameter;3;0;0.00;0.00;0.00
CGLGetVirtualScreen;1;0;0.00;0.00;0.00

 

From the Apple OpenGL docs:

 

Use Optimal Data Types and Formats

If you don't use data types and formats that are native to the graphics processor, you'll incur a costly data conversion.

 

For vertex data, use GLfloat, GLshort, or GLubyte data types. Most graphics processors handle these types natively.

 

For texture data, you’ll get the best performance, regardless of architecture, if you use the following format and data type combination:

 

GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV

These format and data type combinations also provide acceptable performance:

 

GL_BGRA, GL_UNSIGNED_SHORT_1_5_5_5_REV

GL_YCBCR_422_APPLE, GL_UNSIGNED_SHORT_8_8_REV_APPLE

The combination GL_RGBA and GL_UNSIGNED_BYTE needs to be swizzled by many cards when the data is loaded, so it's not recommended.

 

http://developer.apple.com/documentation/G..._section_2.html

 

and

 

Making Sure You Use Functions Correctly

 

OpenGL is an evolving specification. As time goes on, programming practices that were acceptable in the past are replaced by techniques that work much better. There are several functions in the OpenGL specification that you should watch for when you profile your application. If you are using any of these OpenGL functions in your application, make sure that you really need to use them, and that you are using them correctly.

 

Avoid glBegin because it signals that you are using immediate mode. Unless you are drawing a simple shape or creating a small prototype, immediate mode is typically not an optimal technique for using OpenGL.

glFinish forces your application to wait until all OpenGL commands in the pipeline have executed on the graphics card.

glFlush is typically not needed because flushing is usually handled by other calls, such as CGLFlushDrawable. The function glFlush flushes at the macro level, an expensive operation. Flushing calls provided by the Mac OS X interfaces (AGL, CGL, Cocoa OpenGL classes) act at a microlevel to give finer control over flushing and, as a result, much better performance.

glTexImage and related calls. Check to see if you are using this function to redefine the texture each frame. If so, change your code to define the texture outside frame rendering. If your data changes, you can instead use a data replacement technique, such as pixel buffer objects, or call glTexSubImage to specify the image again. Keep in mind that you can call glTexSubImage to specify the entire image again (maintaining the current texture parameters), and it will be a less expensive call than glTexImage. You should call glTexImage only if you must specify a larger image.

Any form of glGet or glIs. Getting state values slows your application. Unless your application is a “middle ware” application, you shouldn’t need to retrieve state values. During development, however, it’s quite common to call glGetError. When your application is ready to go into production, make sure that your remove glGetError calls and any other state getting and checking functions. As an alternative during development, you can look for errors by setting OpenGL Profiler to break on errors.

glPushAttrib or glPopAttrib. You should keep track of OpenGL state instead of using the server attribute stack.

The function glDrawPixels is a convenience function that, under the hood, uses screen-aligned textured quads. If you use screen-aligned textured quads directly, you’ll save the overhead of calling glDrawPixels. Make sure that when you use textured quads that you also use appropriate texture filtering.

If you are calling glReadPixels, you should also be using pixel buffer objects.

glProgramLocalParameter and glProgramEnvParameter calls. These calls, defined by the GL_ARB_vertex_program extension, load only one parameter at a time. It’s more efficient to use glProgramLocalParameters and glProgramEnvParameters, defined by the GL_EXT_gpu_program_parameters extension, which loads multiple parameters.

 

http://developer.apple.com/documentation/G..._section_2.html

 

Most of this is gibberish to me, but maybe it helps...

Edited by Florian

Share this post


Link to post
Share on other sites

Ok, the memory issue should be fixed now, Schmurk added some cachine for cal3d animations.

The performance issue you are describing.. I have no idea, at that time there was no new code, mostly some fixes and stuff. Maybe the arrows code, but that shouldn't affect anything..

Share this post


Link to post
Share on other sites

Well, I did a little searching on Apple's site to learn more about their OpenGL, mostly because Xaphier's vertex program code is not working for us. I came upon a very relevant page:

http://developer.apple.com/graphicsimaging...l/capabilities/

To put this in perspective, all MacBook and iMac mini users either have a Intel GMA 950 or X3100, which means the best hardware rendering is only at OpenGL 1.2 levels. Yes, software rendering is available for higher revisions of OpenGL. However, I think this makes a pretty good case for maintaining a poorman path for older OpenGL implementations.

Share this post


Link to post
Share on other sites

i have an ATI on my ibook, UVP is supported as an extension but no texture are displayed when used (lack of videoram?).

 

With Schmurk patch i get some fps more (3-5), but still swapping a lot...going to upgrade to 1.2Gb ram and i'll report.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×