Jump to content
Eternal Lands Official Forums
0ctane

Help me trace OSX build problem

Recommended Posts

First, let's keep this thread on topic and not have a bunch of "let me know when it is done" or "let me test it" replies. See this port interest thread for that.

 

I am building the CVS client on a OS X 10.3.9 machine (Dual G5) using a combination of frameworks and libraries from fink and darwinports. I am compiling from the command line since I have not figured out XCode yet. I have been able to compile the client, however, I get a Bus crash when executing it. The backtrace says that

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x9091acc8 in glViewport ()
(gdb) bt
#0  0x9091acc8 in glViewport ()
#1  0x0002ead0 in resize_root_window () at gl_init.c:774
#2  0x0002ead0 in resize_root_window () at gl_init.c:774
#3  0x0001e094 in change_projection_float (var=0xcfca4, value=0xbfffd780) at elconfig.c:439
#4  0x0001e6d8 in check_var (str=0x0, type=COMMAND_LINE_SHORT_VAR) at elconfig.c:700
#5  0x00020314 in read_el_ini () at elconfig.c:1106
...

By adding in a bunch of printf commands (yes, dirty) I have narrowed down the problem (and changed the line numbers in the bt).

 

So, when reading in the el.ini file, the program gets to #near_plane = 40.0. This gets parsed by:

our_vars.var[i]->func (our_vars.var[i]->var, &foo);

in check_var (el_config.c). I have verified that foo does get 40.000, and i is 57. From here we (not entirely sure how) move into change_projection_float. value and var are set to 0.000. Then we go into resize_root_window (gl_init.c). The window width and height get set to 640 and 480, respectively, and the program fails at

glViewport(0, 0, window_width, window_height);

So, why does it fail? Well, I threw in a glGetError() before calling glViewport as a test. This time I get the EXC_BAD_ACCESS memory problem with the glGetError command. As near as I can figure, OpenGL has not been initialized before these calls (glViewport or glGetError), resulting in the crash. Is there an initialization that I am missing? Do the variables look right?

 

I know that GLUT was used in an earlier release of ELC, and has since been removed. With the exception of Carbon programs, all of the OpenGL Mac examples that I have seen use GLUT. Even a SDL based OpenGL program (atlantis running under SDL).

 

Thoughts? Any other things to check?

Share this post


Link to post
Share on other sites

Thoughts? Any other things to check?

maybe a silly question, but have you looked through all the ifdef's for windows, mac, and *nix to see if there's an OpenGL call that you're missing out on getting? (no need tor ead all the code, just manually trace execution up to that point)

Share this post


Link to post
Share on other sites
maybe a silly question, but have you looked through all the ifdef's for windows, mac, and *nix to see if there's an OpenGL call that you're missing out on getting? (no need tor ead all the code, just manually trace execution up to that point)

Well, I have traced all the way back to init_stuff (which is called in main.c), and I did not see any special calls. Can anyone verify that foo and i are 40.000 and 57, respectively, after reading #near_place = 40.0?

 

init_video (in gl_init.c) calls glEnable. However, the first call to init_video is AFTER the el.ini parsing. Since el.ini is parsed before any glEnable call (and consequently glViewport is called before glEnable) I do not know why other clients do not have the same memory access problem. Thought we had to setup a display and context...

[edit] oops, glEnable is not what I was looking for specifically...

 

To help me out, can someone put printf("glGetError before glViewport is ", glGetError(), "\n"); right before the glViewport call in resize_root_window (gl_init.c) and tell the first thing it spits out?

 

[edit2] hold on ... nope, thought I found something, but was wrong....sigh

Edited by 0ctane

Share this post


Link to post
Share on other sites

To help me out, can someone put printf("glGetError before glViewport is ", glGetError(), "\n"); right before the glViewport call in resize_root_window (gl_init.c) and tell the first thing it spits out?

well, I would, but I don't have a call to glVieport there (okay, I have two, but both commented out)...

Edited by ttlanhil

Share this post


Link to post
Share on other sites
well, I would, but I don't have a call to glVieport there (okay, I have two, but both commented out)...

You dont have a glViewport call right before a glMatrixMode(GL_PROJECTION); call in gl_init.c?

Well, I found a crash log that says some more:

Host Name:	  nennar
Date/Time:	  2005-12-14 16:08:27 -0500
OS Version:	 10.3.9 (Build 7W98)
Report Version: 2

Command: el_osx.exe
Path:	./el_osx.exe
Version: ??? (???)
PID:	 20148
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:	  KERN_PROTECTION_FAILURE (0x0002) at 0x00000a40

Thread 0 Crashed:
0   libGL.dylib				 0x90912ffc glGetError + 0x28
1   el_osx.exe				  0x0002e84c resize_root_window + 0x74 (gl_init.c:776)
2   el_osx.exe				  0x0001dd38 change_projection_float + 0x50 (elconfig.c:440)
3   el_osx.exe				  0x0001e3f4 check_var + 0x3e8 (elconfig.c:712)
4   el_osx.exe				  0x00020094 read_el_ini + 0x70 (elconfig.c:1126)
5   el_osx.exe				  0x00034bfc read_config + 0xa8 (init.c:197)
6   el_osx.exe				  0x0003582c init_stuff + 0x40 (init.c:539)
7   el_osx.exe				  0x0003f828 SDL_main + 0x48 (main.c:229)
8   el_osx.exe				  0x0000350c -[SDLMain applicationDidFinishLaunching:] + 0x68 (crt.c:300)
...
28  dyld						0x8fe1a278 _dyld_start + 0x64

PPC Thread State:
 srr0: 0x90912ffc srr1: 0x0000d030				vrsave: 0x00000000
cr: 0x22002448  xer: 0x00000000   lr: 0x90912fdc  ctr: 0x90912fd4
r0: 0x0002e84c   r1: 0xbfffd4c0   r2: 0xa0912fdc   r3: 0x00000000
r4: 0x00000000   r5: 0x0000003b   r6: 0x0000000a   r7: 0x00000000
r8: 0x0000003b   r9: 0x00000001  r10: 0x000bc7ed  r11: 0x9092ab58
  r12: 0x90912fd4  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
  r16: 0x00000000  r17: 0xbfffe640  r18: 0x00000000  r19: 0x00000000
  r20: 0x06227c20  r21: 0x0d9a1072  r22: 0x0000000d  r23: 0x0620c194
  r24: 0x00000000  r25: 0x0620c180  r26: 0xa2e75180  r27: 0x00000002
  r28: 0x000cfc4c  r29: 0xa090f004  r30: 0xbfffd4c0  r31: 0x90912fdc

Binary Images Description:
0x1000 -	0xcefff el_osx.exe	  ./el_osx.exe
0x5218000 -  0x521dfff libvorbisfile.3.dylib   /opt/local/lib/libvorbisfile.3.dylib
0x522a000 -  0x522cfff libogg.0.dylib  /opt/local/lib/libogg.0.dylib
0x527a000 -  0x5290fff libvorbis.0.dylib	   /opt/local/lib/libvorbis.0.dylib
0x6008000 -  0x60b5fff libcal3d.11.dylib	   /usr/local/lib/libcal3d.11.dylib
0x30000000 - 0x3004bfff SDL 1.2.9	   /Library/Frameworks/SDL.framework/Versions/A/SDL
0x33000000 - 0x33001fff SDL_net 1.2.5   /Library/Frameworks/SDL_net.framework/Versions/A/SDL_net
0x806f3000 - 0x80714fff ??? OpenAL version 1.2.1 (1.0.1d1)	  /Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
...

Remember that I threw in the glError call infront of glViewport. But, looking back in the log, glViewport crashed with the same problem. Time for some more searching of Apple websites I guess.

Share this post


Link to post
Share on other sites

 

You dont have a glViewport call right before a glMatrixMode(GL_PROJECTION); call in gl_init.c?

 

void resize_root_window()
{
float window_ratio;
//float hud_x_adjust=0;
//float hud_y_adjust=0;

if (window_height==0)window_height=1;			// Prevent A Divide By Zero

//glViewport(0, hud_y, window_width-hud_x, window_height);	// Reset The Current Viewport
//glViewport(0, 0, window_width-hud_x, -(window_height-hud_y));	// Reset The Current Viewport

glMatrixMode(GL_PROJECTION);					// Select The Projection Matrix
glLoadIdentity();							// Reset The Projection Matrix

//window_ratio=(GLfloat)(window_width-hud_x)/(GLfloat)(window_height-hud_y);
window_ratio=(GLfloat)window_width/(GLfloat)window_height;

 

it's commented out. I checked vs CVS, and gl_init.c is one of the files that is clean in my tree.

so I'm guessing it's a change in your tree from CVS, and may well be the problem

Share this post


Link to post
Share on other sites
it's commented out. I checked vs CVS, and gl_init.c is one of the files that is clean in my tree.

so I'm guessing it's a change in your tree from CVS, and may well be the problem

Yeah, cvs changed a small bit. With the glViewport removed, it now just crashes on glMatrixMode.

You can try asking for more technical questions here: http://www.idevgames.com/

It's a Mac game development forum.

Yeah, I was trying to avoid joining yet another forum....guess i do not have much choice. :D

Share this post


Link to post
Share on other sites

2 el_osx.exe 0x0001dd38 change_projection_float + 0x50 (elconfig.c:440)

 

Add this to the beginning of change_projection_float and post the output:

printf("%p %p %g %g", var, value, var?*var:0.0f, value?*value:0.0f);

Share this post


Link to post
Share on other sites
Add this to the beginning of change_projection_float and post the output:

printf("%p %p %g %g", var, value, var?*var:0.0f, value?*value:0.0f);

Hmmm.... the backtrace reports the following:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x909156b4 in glMatrixMode ()
(gdb) bt
#0  0x909156b4 in glMatrixMode ()
#1  0x0002ebec in resize_root_window () at gl_init.c:773
#2  0x0002ebec in resize_root_window () at gl_init.c:773
#3  0x0001e084 in change_projection_float (var=0xceca4, value=0xbfffd780) at elconfig.c:438
#4  0x0001e6bc in check_var (str=0x1701 "%\213ð\004ÛÔÄ", type=INI_FILE_VAR) at elconfig.c:698
#5  0x000202e8 in read_el_ini () at elconfig.c:1101
#6  0x00034f2c in read_config () at init.c:192
...

I had to put a \n at the end of that command, but it returns 0xceca4 0xbfffd780 40 40.

I still have to ask, why is the video (and opengl) being initialized after reading the config?

check_gl_mode is called within init_video which is called after reading the config (and hence after this glMatrix call). Still, this problem is more likely just a MacOSX-X11 issue.

 

BTW, I broke down and posted over at iDevGames. I noticed that Corun (the porter of the old client) is still active on their forums...just not with this game.

 

[edit] why does reading the configuration file necessitate calling OpenGL?

Edited by 0ctane

Share this post


Link to post
Share on other sites

it looks like instead of say, dumping the data into some struct for the next drawing cycle, it just dumps the information straight into opengl.

Thats probably why its done straight from the init file, save time.

 

In which case the data isnt being Swap'ed.

Suprised on why i didnt see this issue on gentoo tho.

 

*edit,

After length discussion with Vegar, I was wrong all data sources there should be from same endian sources.

Edited by Zep

Share this post


Link to post
Share on other sites

Well, I got frustrated and commented out the resize_root_window in change_projection_float. And I added in two glutSwapBuffers() commands before the two SDL_GL_SwapBuffers() commands. Viola...I got a window to display. :( Well, it is just a white window with some red and brown solid bars, but it is a start. Well, i accidentally deleted my init.c file (and this little success was on the old cvs) I pulled down the latest CVS. Now I get:

init.c: In function `read_config':
init.c:169: error: `DIR' undeclared (first use in this function)
init.c:169: error: (Each undeclared identifier is reported only once
init.c:169: error: for each function it appears in.)
init.c:169: error: `d' undeclared (first use in this function)
make: *** [init.o] Error 1

This is probably something really silly I am doing wrong, but any assistance would be great.

 

[edit to add the below]

From the older cvs (about a week old now) I have the game showing the first progress bar in a window. I get past load_e3d_list and death in cal3d:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x05556b10 in CalCoreSkeleton::scale(float) ()
(gdb) bt
#0  0x05556b10 in CalCoreSkeleton::scale(float) ()
#1  0x00074824 in CalCoreSkeleton_Scale (self=0x0, factor=1) at cal3d_wrapper.cpp:12
#2  0x0000b350 in parse_actor_script (cfg=0x432890c) at actor_scripts.c:1866
#3  0x0000b3e4 in parse_actor_defs (node=0x0) at actor_scripts.c:1883
#4  0x0000b410 in parse_actor_defs (node=0x0) at actor_scripts.c:1889
#5  0x0000b4f4 in read_actor_defs (dir=0x80808080 <Address 0x80808080 out of bounds>, index=0x0) at actor_scripts.c:1918
#6  0x0000b584 in init_actor_defs () at actor_scripts.c:1939
#7  0x00035b30 in init_stuff () at init.c:614

Time for some more hacking....might be a version issue with Cal3d, or how I have it compiled. Still have not figured out that DIR problem from the latest CVS.

Edited by 0ctane

Share this post


Link to post
Share on other sites

Make sure you include dirent.h.

For instance you could try to move #include <dirent.h> out of the #ifdef block, something like this:

--- init.c	  14 Dec 2005 16:09:56 -0000	  1.205
+++ init.c	  19 Dec 2005 19:44:21 -0000
@@ -1,8 +1,8 @@
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/types.h>
+#include <dirent.h>
#ifdef __GNUC__
- #include <dirent.h>
 #include <unistd.h>
#endif
#include <string.h>

 

Edit: You can also try changing the path to sys/dirent.h

Edited by Vegar

Share this post


Link to post
Share on other sites

So, I have made much progress on the OS X port. A older screenshot is here. A working version is currently in testing by numerous individuals. Now I am trying to address some graphics problems.

 

That link shows some shadow problems I am trying to fix, but the problem I am trying to address right now has to do with isometric vs perspective viewing. Isometric looks fine, but textures in perspective view are messed up. The textures of vertical walls and floors will move/wave while walking and looking around. However, actor textures and textures for scene objects are all drawn correctly. Any ideas why this would be so? Where is the texture mapping code for the environment?

 

In order to get around a few game-stopping crashes, I had to define out or change the code to get rid of opengl calls (specifically glDeleteTextures) which were executed before a context was setup (from what I can tell). These opengl bypasses were created for the initialization of the game and to address a lit-object problem. (The perspective problem occured before the lit-object fixes).

 

All my changes are in CVS so you can just search for the #ifdef and #ifndef OSX.

 

[edit]BTW, texture problem occurs with and without USE_LISPSM and NEW_FRUSTRUM. PL titanium cave looks fine. Seems to only be true vertical and horizontal environment textures.

Edited by 0ctane

Share this post


Link to post
Share on other sites

Try to enable anisotropic filtering (in your OpenGL options), see if it helps.

Running glxinfo I see that GL_EXT_texture_filter_anisotropic is available. However, I am uncertain as to how I should enable this.

 

I do not think it is relevent, but on loading the program, I see the following:

GL_ARB_vertex_program extension found, NOT using it
GL_ARB_fragment_program extension found, NOT using it
Couldn't find the OpenGL Shading Language

It looks like the first two are not implemented yet in the code.

I have a ATI Radeon 9800, glx version 1.2, glu version 1.3

 

A picture is worth a thousand words so here is an example of the warping/tiling problem...

elglitch1nd.jpg

Edited by 0ctane

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.

×