stdout on Mac

[shonen]

I tried to follow the instructions in the FAQ to get stdout to show on a Mac, which is essentially just to navigate to /Applications/T-Engine.app/Contents/MacOS/ and run ./T-Engine

I get some output, however the game doesn't quite launch. A white box pops up where the game ought to go, and i get this from stdout:

Code: Select all

WillzMac:MacOS$ pwd
/Applications/T-Engine.app/Contents/MacOS

WillzMac:MacOS$ ./T-Engine
[CPU] Detected 2 CPUs
OpenAL device available: Built-in Output (default Built-in Output)
Available video driver: cocoa
Available video driver: x11
Available video driver: dummy
Booting T-Engine from: /Applications/T-Engine.app/Contents/MacOS/./
SelfExe gave us app directory of:	/Applications/T-Engine.app/Contents/MacOS//Resources/
Creating particles thread 0
[DO RESIZE] Requested: 800x600 (0)
[DO RESIZE] Got: 800x600 (0)
OpenGL max texture size: 8192
OpenGL max texture size: 8192
Running lua loader code...
[EVENT HANDLER]: Got a SHOW/FOCUS_GAINED event, restoring full FPS.
[EVENT HANDLER]: Got a SHOW/FOCUS_GAINED event, restoring full FPS.

I'm running Snow Leopard on an Intel Mac circa 2008, am I missing something?

Thanks,

shonen

[madmonk]

Hi

I'm not a MAC expert (or even a beginner) since I don't have a MAC. I do run under Linux, though...

If you install GDB, then run Tome and then post the output here, I'll see if I can get some help for you.

The Linux instructions are here:

http://te4.org/wiki/tome4-running-tome-gdb

Sorry to not be more helpful...

[UPDATE] and this:

http://forums.te4.org/viewtopic.php?f=42&t=22300&p=88029&hilit=stdout+mac#p88029

[snoop]

Yes, running in the terminal under gdb should work, but is there some reason you don't want to use the regular method for running on the Mac and just put the T-Engine.app in your applications folder?

[shonen]

I'm not a MAC expert (or even a beginner) since I don't have a MAC. I do run under Linux, though...

If you install GDB, then run Tome and then post the output here, I'll see if I can get some help for you.

Ok, this is odd, it runs just fine from gdb, no output other than a lot of "loading symbols" lines.

Sorry to not be more helpful...

I appreciate the response. You've been the most helpful to date.

[UPDATE] and this:

http://forums.te4.org/viewtopic.php?f=4 ... mac#p88029

... yes, this is essentially what's in the FAQ. Either something has changed, or I have some odd configuration detail that's screwing up the works. Maybe it's time to upgrade to Lion or Mountain Lion now that all my Diablo II time has been reallocated to TOME.

shonen

[shonen]

Yes, running in the terminal under gdb should work, but is there some reason you don't want to use the regular method for running on the Mac and just put the T-Engine.app in your applications folder?

That works fine of course, I just want to be able to see stdout to view messages. Not critical by any means, just want a better understanding of what's going on, especially when I run into problems.

[shonen]

Oh, scratch that, after a more careful read, I see that I can also attach to the running process.

Here's the stack backtrace:

Code: Select all

#0  0x00007fff87585aaa in CFBasicHashApply ()
#1  0x00007fff8759155f in CFSetApplyFunction ()
#2  0x00007fff875a7fe7 in __CFRunLoopDoSources0 ()
#3  0x00007fff875a65c9 in __CFRunLoopRun ()
#4  0x00007fff875a5d8f in CFRunLoopRunSpecific ()
#5  0x00007fff8773b7ee in RunCurrentEventLoopInMode ()
#6  0x00007fff8773b5f3 in ReceiveNextEventCommon ()
#7  0x00007fff8773b4ac in BlockUntilNextEventMatchingListInMode ()
#8  0x00007fff892d0eb2 in _DPSNextEvent ()
#9  0x00007fff892d0801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#10 0x000000000006821e in Cocoa_PumpEvents ()
#11 0x000000000004eca0 in SDL_PumpEvents ()
#12 0x000000000004ed13 in SDL_WaitEventTimeout ()
#13 0x000000000004ecda in SDL_PollEvent ()
#14 0x0000000100042a90 in tengine_main ()

and some thread info:

Code: Select all

(gdb) info threads 
  6 "particles"                     0x00007fff873d1a6a in __semwait_signal ()
  5 "SDLTimer"                      0x00007fff873d1a6a in __semwait_signal ()
  4                                 0x00007fff87396dda in semaphore_timedwait_signal_trap ()
  3                                 0x00007fff87396d7a in mach_msg_trap ()
  2 "com.apple.libdispatch-manager" 0x00007fff873afc0a in kevent ()
* 1 "com.apple.main-thread"         0x00007fff8759155f in CFSetApplyFunction ()

(gdb) info thread 1
Thread 1 has current state "WAITING"
	Mach port #0x903 (gdb port #0x3a07)
	frame 0: 0x00007fff8759155f in CFSetApplyFunction ()
	pthread ID: 0x7fff70cadcc0
	system-wide unique thread id: 0x93839
	dispatch queue name: "com.apple.main-thread"
	dispatch queue flags: 0x0
	total user time: 660998376
	total system time: 923904448
	scaled cpu usage percentage: 0
	scheduling policy in effect: 0x1
	run state: 0x3 (WAITING)
	flags: 0x0
	number of seconds that thread has slept: 0
	current priority: 46
	max priority: 63
	suspend count: 0.

... looks like it's waiting for something, right around where it would be setting up the initial window size, but I can't quite tell what. Is that helpful? Hopefully not TMI.

shonen

[snoop]

I've got pretty much the same setup as you do, and last time I tried I was able to run in xterm under gdb and see the game log/output barfing out in the xterm window just fine. Now you're saying you can run under gdb, but don't get any output?

If you start the game the easy way, the output should end up in a log file that you can read in the console. Can you see the output there? Not a solution, but at least you'll know the output is going somewhere...

This seems unlikely, but try xterm instead of the terminal app... sometimes it works better for these sort of things.

[shonen]

OK, I took another look at this and I do get the logging in gdb. I probably had the output redirected to the wrong place. Not quite as simple as it looks in the FAQ, but close enough.

Thanks for all the help.

Shonen