Jump to content
Eternal Lands Official Forums
Sulla

Mac OS X Lion AKA 10.7 issues

Recommended Posts

Hey folks,

 

So being "that guy" I updated my mac to the new OS on day 1. All works great EXCEPT EL. Would get anywhere from ~2-3 mins to 30 secs before crash.

 

To save a long read on the opening post, I did some troubleshooting and, worked it down to get EL working. I had to go into "Poor Man" to get the crashing to stop. Basically, the point of my post is to get the word out that in Snow Leopard (10.6) no issues, now forced into poor man for 10.7

 

I don't have the chops to figure out the ump-teen thousand lines of code. Those of you who do, ROCK ON! A simple Lion compile may fix it, or could be an Open-GL issue, or more. Any idea's, and solutions i'm all ears.

 

Thanks!!!!!!

 

Sulla

Edited by Sulla

Share this post


Link to post
Share on other sites

A recompile on 10.7 may help but I don't have it; though it is not a general solution to that problem, as the client is compiled for 10.4 for maximum backwards compatibility.

I'll try to catch you in-game for further discussion...

Share this post


Link to post
Share on other sites

A recompile on 10.7 may help but I don't have it; though it is not a general solution to that problem, as the client is compiled for 10.4 for maximum backwards compatibility.

I'll try to catch you in-game for further discussion...

 

Thanks for the quick response. Just wanted to put it out there for other Mac users to be aware of. We'll talk in game.

Share this post


Link to post
Share on other sites

Ok Sir_Odie saw the issue in my logs. Apparently it is something in Open-GL with the OS update. So the work around for the time being is to TURN OFF Eye Candy and all works well. Why poor man worked before I don't know, must have just been luck.

 

Now time to see if I can learn Open-GL code and see if a fix can be found.....updates to come if I discover anything.

Share this post


Link to post
Share on other sites

Ok small update:

 

Xcode 4 for Lion DOES have Repositories. However it does not have CVS, but it does support GIT.

 

From what I can tell it is the current stable version (what I selected) but if I'm wrong pass the word. That said here is a QUICK writeup how to get it going:

 

1) From the Xcode 4 splash screen you can select Repositories. IF you have the splash screen disabled, goto Window -> Organizer.

 

2) Click the "+" to add a Repository (like is most Apple app's)

 

3) In the screen, name it EternalLands (probably your choice what to call it)

 

4) Location: git://git.berlios.de/elc

 

5) Type: GIT

 

6) Click Next

 

7) If you have a developer account on Berlios here is where you put in username and password. I do not so I left it black.

 

8) Pick your directory and hit the "Clone" button. It downloads the code and you're off to the races.

Edited by Sulla

Share this post


Link to post
Share on other sites

Another update,

 

I got it compiling! Had to fight with the old Xcode project on the repository and add/delete files. But I won.

 

So YES, it still crashes with Eye Candy enabled. Meaning it is not a local build issue (I was hoping). So time to learn openGL and see what I can see......updates to come as found.

Share this post


Link to post
Share on other sites

So I figured it was time to get back to seeing what I can do about this. I took a break for some RL stuff. So I have downloaded the test client for the OpenGL2, and same thing. Downloaded the code to compile myself, and after STRUGGLING to get it compiling (more on that in a bit) Eye Candy lasted longer but still crashed. Looking at the logs it crashes on a call to the Driver, meaning of course something changed in the OS driver (which Sir_Odie suspected from the beginning). I've done some reading and apparently a few other games have had this issue and from what I read the developers changed a few calls and all was well (one I remember was Duke Nukem, who said they were waiting on quality control thumbs up to distribute but don't remember the date). So I will get to reading what I can find on what OpenGL calls OS X Lion does not like.

 

One thing that MAY matter (I don't see how but putting it out there) is Lion is OpenGL 3 native; maybe something changed in the SDK.

 

Now back to my compile issue, and I KNOW it's my stupid mistake somewhere in X-Code but for the life of me I just can't see it. When building, I got several errors of items not being defined. I discovered that some classes were not linked to the project. Easy fix, I just dragged them in. I am down to 5 which I can not get to go away (without commenting them out) and I KNOW they are related. In fileutil.c, the line "err = XzUnpacker_Create(&state, &lzmaAlloc);" The compiler is telling me XzUnpacker_Create is not defined. Well it is....in "xz/Xz.h" Xz is included in fileutil, and is part of the project. I have a few others but they all link to same file so finding my stupid mistake should take care of it all. Is there a work around I'm missing, or is everybody having issue with the Xz files?

 

Open for all ideas on both subjects. See everybody in game.

 

Sulla

Share this post


Link to post
Share on other sites

Thanks to the amazing Sir_Odie I got past the non compiling issue. Now I got the GL2 version working and crashing. Thanks to the wonders of crash reports got it down to the method, now to dig deep......

 

1-4 are all register addresses before the crash.

 

5 com.apple.GeForceGLDriver 0x8f177375 gldUpdateDispatch + 916

6 GLEngine 0x02d21768 gleDoDrawDispatchCore + 454

7 GLEngine 0x02cc4c7f glDrawArrays_ACC_Exec + 265

8 libGL.dylib 0x93c8e20c glDrawArrays + 44

9 com.eternal-lands.EternalLands 0x000f214f ec::Effect::draw_particle_buffer() + 447 (eye_candy.cpp:303)

Share this post


Link to post
Share on other sites

*clears throat* Don't pop the champagne but I have a fix and it is working.

 

In eye_candy.cpp the call:

glDrawArrays(GL_QUADS, 0, particle_count * 4);

is what was causing the crash.

 

So doing some reading when the count variable (particle_count) goes negative the call generates an error. From what I can determine there is no error handling in the code, but up until this point it has not been an issue. I can only assume the new Apple OpenGL drivers aren't handling errors either (why....who knows). So I added a simple error check before calling and it is working perfect! I'm going to compile as release and test it for awhile. I want to dig a little deeper and find out where it goes either negative or worse... nil. So that's the update, anybody who wants to see the call right now it is:

 

if (particle_count) {

glDrawArrays(GL_QUADS, 0, particle_count * 4);

}

 

I don't have an account to upload, but will sort that later.

Share this post


Link to post
Share on other sites

Iirc, "if (particle_count)" is true for negative values of particle_count, so this only prevents a value of zero...

But if it works, fine :)

(just that it is not what you say you want to prevent, I'd use "if (particle_count > 0)" as test,

also, I don't like using an int as a boolean value, but that's my C++ background)

Share this post


Link to post
Share on other sites

Iirc, "if (particle_count)" is true for negative values of particle_count, so this only prevents a value of zero...

But if it works, fine :)

(just that it is not what you say you want to prevent, I'd use "if (particle_count > 0)" as test,

also, I don't like using an int as a boolean value, but that's my C++ background)

 

Good to hear Revi! I'm a hobby programmer so always happy to hear corrections. I was just getting it to function, and it worked so I just let go. Would you do something like:

BOOL countExists = (particle_count > 0);

if (countExists) ........

?

Sorry about the formatting, that's my Objective-C habits but you get the gist. Since it is a C++ program, would want to use C++ conventions.

 

Thanks for tracking this down!

 

I've updated the MAC-Client on my website (see link below)...

 

Thanks Sir_Odie! I'll keep digging and see if I can track down the underlying issue, but we're running for now.

Share this post


Link to post
Share on other sites

Would it not be better just to exit the draw_particle_buffer() function if particle_count is less than 1? In any case, is someone committing the fix?

Share this post


Link to post
Share on other sites

Would it not be better just to exit the draw_particle_buffer() function if particle_count is less than 1? In any case, is someone committing the fix?

 

It very well might a better option. As I said, I just got it working the other night and was posting findings. I might have time to look at it over the weekend and learn what particle_count does but only time will tell. But it's functioning with optimization to come.

Share this post


Link to post
Share on other sites
Would it not be better just to exit the draw_particle_buffer() function if particle_count is less than 1? In any case, is someone committing the fix?

I pushed a commit that does just this (in eye_candy.cpp). Hopefully it pushed correctly. Xcode was giving me grief about the push, so I did it from the command line. Also tried to update some project files.

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.

×