OSX 10.4 problems

xeno74 · Post by **xeno74** » Sat Apr 09, 2011 7:46 am

I have problems with Quake map and STK 0.7.1 rc 1 on Mac OS X 10.4.11 Tiger PowerPC:

Everything is upside down

Is that a BIG_ENDIAN problem?

http://pastebin.com/XwXNdLp4

xeno74 · Post by **xeno74** » Sat Apr 09, 2011 11:50 am

xeno74 wrote:I have problems with Quake map and STK 0.7.1 rc 1 on Mac OS X 10.4.11 Tiger PowerPC:

Everything is upside down

Is that a BIG_ENDIAN problem?

http://pastebin.com/XwXNdLp4

Hi

there is a graphic card driver error in 10.4.11. I made a DMG for Mac OS X 10.3.9 Panther and higher and STK runs nice on 10.3.9 and 10.4.0.

hybrid · Post by **hybrid** » Sat Apr 09, 2011 10:02 pm

The upside down is not a big endian problem, but could be a problem with RTT and OpenGL. At least that's where such problems are usually found.Does this always happen? It would be important to get the exact render setup of this screen.
The quake map is the incomplete render in the first picture? Don't know how this could happen, the rendering ssems to be completely broken. But the pattern is pretty strange for typical desktop rendering schemes.
The third problem is unclear. Does the app crash or what's the symptom?

xeno74 · Post by **xeno74** » Thu Apr 21, 2011 8:10 am

STK 0.7.1 with Irrlicht 1.8 Alpha doesn't work on Mac OS X 10.4.11. It works perfect on 10.3.9, 10.4.0, 10.5.8, and 10.6.7. The Problem isn't STK 0.7.1. Irrlicht 1.8 isn't compatible with few graphics cards driver. I've build a last STK Revision 8150 with Irrlicht 1.7.2 and added the eMule and Beastie kart. It's called TenFourSTK -> TenFour like 10.4 Tiger.

Download: TenFourSTK-0.7.1-osx-ppc.dmg.zip

Screenshot TenFourSTK/Irrlicht 1.7.2 on Mac OS X Tiger 10.4.11:

STK 0.7.1/Irrlicht 1.8 Alpha Universal on 10.4.11 Tiger with ATi and Nvidia graphics card:

There is on Linux a lot of problems with Irrlicht 1.8 and open source graphic cards driver.

And Irrlicht 1.8 doesn't work with software 3D driver on openSUSE. STK 0.7 with Irrlicht 1.7.2 works perfect with software GL and open source graphic cards driver

hybrid · Post by **hybrid** » Thu Apr 21, 2011 8:43 am

I've split these reports from the original thread, as it seems to be a longer task. I cannot do any detailed debugging under OSX. And since no one else in the dev team is actively working on the OSX version, I suggest to install gDebugger on your system. This will allow to find any problems with OpenGL usage and setup with the app being run.
The problems are not explainable, though. Getting only a fraction of the whole screen rendered is pretty strange. It looks like the buffer swap is only updating a small rectangle. But we're not working with partial updates. The only place where such masks are set up are for stencil shadows (via stencil buffer) and with some 2d methods with scissors. These are fully disabled afterwards again, but might of course lead to trouble in case of broken drivers. However, we're usually not working around broken drivers, but simply fix bugs in OpenGL usage on our side.
This also holds for the problems with the Linux drivers. Unless this is due to a properly unsupported extension which we do not check for, we just have to keep it as is until the driver gets fixed.

xeno74 · Post by **xeno74** » Thu Apr 21, 2011 9:53 am

hybrid wrote:I've split these reports from the original thread, as it seems to be a longer task. I cannot do any detailed debugging under OSX. And since no one else in the dev team is actively working on the OSX version, I suggest to install gDebugger on your system. This will allow to find any problems with OpenGL usage and setup with the app being run.
The problems are not explainable, though. Getting only a fraction of the whole screen rendered is pretty strange. It looks like the buffer swap is only updating a small rectangle. But we're not working with partial updates. The only place where such masks are set up are for stencil shadows (via stencil buffer) and with some 2d methods with scissors. These are fully disabled afterwards again, but might of course lead to trouble in case of broken drivers. However, we're usually not working around broken drivers, but simply fix bugs in OpenGL usage on our side.
This also holds for the problems with the Linux drivers. Unless this is due to a properly unsupported extension which we do not check for, we just have to keep it as is until the driver gets fixed.

gDebugger doesn't work on OS X 10.4.11 Tiger PowerPC

See also in the thread:
http://community.games4mac.de/index.php?showtopic=21400

and:

http://forum.freegamedev.net/viewtopic. ... 147#p13145

hybrid · Post by **hybrid** » Thu Apr 21, 2011 11:02 am

Maybe we should first check which examples from the original Irrlicht SDK do or do not work. I can definitely say much more about the changes and requirements for the render calls in those examples. Next thing would be to identify the offending render calls somehow. Did you run debug versions to issue opengl error messages where available?

xeno74 · Post by **xeno74** » Thu Apr 21, 2011 6:32 pm

hybrid wrote:Maybe we should first check which examples from the original Irrlicht SDK do or do not work. I can definitely say much more about the changes and requirements for the render calls in those examples. Next thing would be to identify the offending render calls somehow. Did you run debug versions to issue opengl error messages where available?

STK 0.7.1 with debug:

./supertuxkart --version

Code: Select all

==============================
SuperTuxKart, svn.
SuperTuxKart, SVN revision number '8403'.
Irrlicht version 1.8.0 (1.8.0-alpha)
==============================

./gdb supertuxkart

Code: Select all

GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...
warning: Unable to read symbols for "@executable_path/../Frameworks/SDL.framework/Versions/A/SDL" (file not found).

warning: Unable to read symbols for "@executable_path/../Frameworks/Vorbis.framework/Versions/A/Vorbis" (file not found).

warning: Unable to read symbols for "@executable_path/../Frameworks/Ogg.framework/Versions/A/Ogg" (file not found).

warning: Unable to read symbols for "@executable_path/../Frameworks/libintl.framework/Versions/8/libintl" (file not found).
Reading symbols for shared libraries ............. done

run

Code: Select all

Starting program: /Users/christian/Desktop/supertuxkart-svn/src/supertuxkart
Reading symbols for shared libraries .........................warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/oalDevice.o" - no debug information available for "/Developer/libs/openal/OpenAL-MacOSX/oalDevice.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/oalImp.o" - no debug information available for "/Developer/libs/openal/OpenAL-MacOSX/oalImp.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/oalContext.o" - no debug information available for "/Developer/libs/openal/OpenAL-MacOSX/oalContext.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/oalOSX.o" - no debug information available for "/Developer/libs/openal/OpenAL-MacOSX/oalOSX.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/CAStreamBasicDescription.o" - no debug information available for "/Developer/Examples/CoreAudio/PublicUtility/CAStreamBasicDescription.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/CAMutex.o" - no debug information available for "/Developer/Examples/CoreAudio/PublicUtility/CAMutex.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/CAHostTimeBase.o" - no debug information available for "/Developer/Examples/CoreAudio/PublicUtility/CAHostTimeBase.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/CAGuard.o" - no debug information available for "/Developer/Examples/CoreAudio/PublicUtility/CAGuard.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/CADebugger.o" - no debug information available for "/Developer/Examples/CoreAudio/PublicUtility/CADebugger.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/CADebugMacros.o" - no debug information available for "/Developer/Examples/CoreAudio/PublicUtility/CADebugMacros.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/oalSource.o" - no debug information available for "/Developer/libs/openal/OpenAL-MacOSX/oalSource.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/oalBuffer.o" - no debug information available for "/Developer/libs/openal/OpenAL-MacOSX/oalBuffer.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/oalCaptureDevice.o" - no debug information available for "/Developer/libs/openal/OpenAL-MacOSX/oalCaptureDevice.cpp".

warning: Could not find object file "/Developer/libs/openal/OpenAL-MacOSX/build/OpenAL.build/Deployment/OpenAL.build/Objects-normal/ppc/CABufferList.o" - no debug information available for "/Developer/Examples/CoreAudio/PublicUtility/CABufferList.cpp".

........................................................+....+ done
Irrlicht Engine version 1.8.0-alpha
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC
[FileManager] checking whether we are using an app bundle... no
[FileManager] Data files will be fetched from: '..'
[IrrDriver] Creating NULL device
Irrlicht Engine version 1.8.0-alpha
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC
[IrrDriver] Trying OpenGL rendering.
[IrrDriver] Trying to create device with 32 bits
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
startMusic : m_normal_filename=<../data//music/MayDayMayhem.ogg>, gain=0.7
WARNING: Music not playing when it should be. Source state: 4116
[Irrlicht Error] FBO format unsupported
[Irrlicht Error] FBO error
[QuadGraph::makeMiniMap] WARNING: RTT does not appear to work,mini-map will not be available
startMusic : m_normal_filename=<../data/music///TheDeadRocks-GreenSecretFromAmazonia.ogg>, gain=0.7
[addons] Timeout waiting for joining. Cancelling.
[addons] Cancelled network thread. Return code: 0

Program exited normally.

With latest Irrlicht svn debug version:

bt

Code: Select all

#0  0x90047dac in kill ()
#1  0x9012d7b4 in abort ()
#2  0x94ca80b0 in __eprintf ()
#3  0x00241a68 in irr::video::checkFBOStatus (Driver=0xf069600) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../COpenGLTexture.cpp:888
#4  0x00241bb0 in irr::video::COpenGLFBODepthTexture::attach (this=0x16365f00, renderTex=0x16388b10) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../COpenGLTexture.cpp:807
#5  0x001f0250 in irr::video::COpenGLDriver::addRenderTargetTexture (this=0xf069600, size=@0xbfffe740, name=@0xbfffe52c, format=ECF_A8R8G8B8) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../COpenGLDriver.cpp:3805
#6  0x0003cde8 in IrrDriver::RTTProvider::RTTProvider (this=0xbfffe60c, dimension=@0xbfffe740, name=@0xbfffe73c) at graphics/irr_driver.cpp:1141
#7  0x0015c0dc in QuadGraph::makeMiniMap (this=0x16387fe0, dimension=@0xbfffe740, name=@0xbfffe73c, fill_color=@0xbfffe738) at tracks/quad_graph.cpp:627
#8  0x00160a34 in Track::loadQuadGraph (this=0x15a02e50, mode_id=0) at tracks/track.cpp:320
#9  0x00167104 in Track::loadTrackModel (this=0x15a02e50, parent=0x163841c0, mode_id=0) at tracks/track.cpp:954
#10 0x000e66f8 in World::init (this=0x163841c0) at modes/world.cpp:136
#11 0x000e809c in WorldWithRank::init (this=0x163841c0) at modes/world_with_rank.cpp:25
#12 0x000df37c in LinearWorld::init (this=0x163841c0) at modes/linear_world.cpp:52
#13 0x00102904 in RaceManager::startNextRace (this=0x15a08470) at race/race_manager.cpp:296
#14 0x0010380c in RaceManager::startNew (this=0x15a08470) at race/race_manager.cpp:239
#15 0x00103934 in RaceManager::startSingleRace (this=0x15a08470, trackIdent=@0xbfffefac, num_laps=1) at race/race_manager.cpp:562
#16 0x001154d0 in TrackInfoDialog::processEvent (this=0x163842e0, eventSource=@0x16385984) at states_screens/dialogs/track_info_dialog.cpp:299
#17 0x000607cc in GUIEngine::EventHandler::onWidgetActivated (this=0xeac9a60, w=0xf656000, playerID=0) at guiengine/event_handler.cpp:558
#18 0x00060b6c in GUIEngine::EventHandler::onGUIEvent (this=0xeac9a60, event=@0xbffff3f8) at guiengine/event_handler.cpp:622
#19 0x00060fec in GUIEngine::EventHandler::OnEvent (this=0xeac9a60, event=@0xbffff3f8) at guiengine/event_handler.cpp:120
#20 0x00208b78 in irr::gui::CGUIEnvironment::OnEvent (this=0xea736a0, event=@0xbffff3f8) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../CGUIEnvironment.cpp:393
#21 0x005ad77c in irr::gui::IGUIElement::OnEvent (this=0x16384a40, event=@0xbffff3f8) at /usr/local/include/irrlicht/IGUIElement.h:524
#22 0x002c84e0 in irr::gui::CGUIModalScreen::OnEvent (this=0x16384a40, event=@0xbffff3f8) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../CGUIModalScreen.cpp:134
#23 0x005ad77c in irr::gui::IGUIElement::OnEvent (this=0x16384490, event=@0xbffff3f8) at /usr/local/include/irrlicht/IGUIElement.h:524
#24 0x00291934 in irr::gui::CGUIWindow::OnEvent (this=0x16384490, event=@0xbffff3f8) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../CGUIWindow.cpp:217
#25 0x0028eee8 in irr::gui::CGUIButton::OnEvent (this=0x163859c0, event=@0xbffff64c) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../CGUIButton.cpp:204
#26 0x0020caec in irr::gui::CGUIEnvironment::postEventFromUser (this=0xea736a0, event=@0xbffff64c) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../CGUIEnvironment.cpp:565
#27 0x001d04e8 in irr::CIrrDeviceStub::postEventFromUser (this=0xea3e8d0, event=@0xbffff64c) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../CIrrDeviceStub.cpp:214
#28 0x001a10dc in irr::CIrrDeviceMacOSX::postMouseEvent (this=0xea3e8d0, event=0x16366590, ievent=@0xbffff64c) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../MacOSX/CIrrDeviceMacOSX.mm:999
#29 0x001a355c in irr::CIrrDeviceMacOSX::run (this=0xea3e8d0) at /Users/christian/Desktop/irrlicht-svn/source/Irrlicht/MacOSX/../MacOSX/CIrrDeviceMacOSX.mm:784
#30 0x00041184 in IrrDriver::update (this=0xea33540, dt=0.0390000008) at graphics/irr_driver.cpp:1002
#31 0x0000ade0 in MainLoop::run (this=0x1636f360) at main_loop.cpp:144
#32 0x0000a32c in main (argc=1, argv=0xbffff9bc) at main.cpp:1022

hybrid · Post by **hybrid** » Fri Apr 22, 2011 9:17 am

Ok, that's definitely a bug in Irrlicht. I'll check where this could happen exactly and why.
One thing that I also realized just now is that we don't use the dynamic extension mechanism of OpenGL under OSX. This will definitely lead to strange situations and maybe illegal function calls due to not properly checking all conditions for direct OpenGL method usage. Another thing, due to this lack of support, is, that one has to compile Irrlicht under the same system setup where it shall be used. The problem is, that the headers basically defines which extensions are available and which not. If the target system supports less extensions, calls could be incomplete or simply raising undefined behavior. This also holds for Solaris systems, although the extension mechanism would work there. It's just commented out, because the old solaris/sparc systems that I used did not support GLX. You could check IrrCompileConfig and remove the 'undef IRR_USE_OPENGL_EXTENSION_POINTER_' or very similar compiler define. This might solve some problems under Solaris. We'd need a dynamic check for existence of glx.h in order to automate this setting (say, via configure).

xeno74 · Post by **xeno74** » Fri Apr 22, 2011 12:37 pm

hybrid wrote:Ok, that's definitely a bug in Irrlicht. I'll check where this could happen exactly and why.
One thing that I also realized just now is that we don't use the dynamic extension mechanism of OpenGL under OSX. This will definitely lead to strange situations and maybe illegal function calls due to not properly checking all conditions for direct OpenGL method usage. Another thing, due to this lack of support, is, that one has to compile Irrlicht under the same system setup where it shall be used. The problem is, that the headers basically defines which extensions are available and which not. If the target system supports less extensions, calls could be incomplete or simply raising undefined behavior. This also holds for Solaris systems, although the extension mechanism would work there. It's just commented out, because the old solaris/sparc systems that I used did not support GLX. You could check IrrCompileConfig and remove the 'undef IRR_USE_OPENGL_EXTENSION_POINTER_' or very similar compiler define. This might solve some problems under Solaris. We'd need a dynamic check for existence of glx.h in order to automate this setting (say, via configure).

Could you tell me about when the problem is resolved?

Kannst du mir Bescheid geben, wenn das Problem gelöst ist?

Thank you very much indeed

Vielen Dank für die viele Mühe

hybrid · Post by **hybrid** » Fri Apr 22, 2011 1:10 pm

Ok, what seemed like an unintentional crash was a DEBUG_BREAK_IF(true) in the FBO setup. I guess we should introduce a function name to show up in the stack trace for such occasions, makes it easier to read the trace. Anyway, the FBO error which shows up in the console out becomes an abort() in debug mode. This leads to the immediate termination of Irrlicht. In release mode this would only lead to an unsuccesful RTT generation, which is much better IMHO. I'll remove the BREAK there.
The question is a) why the depth renderbuffer is unsupported, and b) what would be the actual problem later on. I guess that the broken RTT is later on messing with the whole rendering.
You could also try to disable FBO support (driver->disableFeature(EVDF_FRAMEBUFFER_OBJECT)) to further test other ways of rendering this scene.

xeno74 · Post by **xeno74** » Fri Apr 22, 2011 1:57 pm

hybrid wrote:Ok, what seemed like an unintentional crash was a DEBUG_BREAK_IF(true) in the FBO setup. I guess we should introduce a function name to show up in the stack trace for such occasions, makes it easier to read the trace. Anyway, the FBO error which shows up in the console out becomes an abort() in debug mode. This leads to the immediate termination of Irrlicht. In release mode this would only lead to an unsuccesful RTT generation, which is much better IMHO. I'll remove the BREAK there.
The question is a) why the depth renderbuffer is unsupported, and b) what would be the actual problem later on. I guess that the broken RTT is later on messing with the whole rendering.
You could also try to disable FBO support (driver->disableFeature(EVDF_FRAMEBUFFER_OBJECT)) to further test other ways of rendering this scene.

Thank you for your help

I'm only a packager and ported STK to other plattforms. Only Auria and Joerg to be able edit the STK source code and disable FBO support. I will tell Auria and Joerg about this problems.

Danke für deine Hilfe

Ich bin nur ein Paket-Ersteller und Portierer. Nur Auria und Joerg können den Source-Code von STK editieren und den FBO-Support deaktivieren.

hybrid · Post by **hybrid** » Fri Apr 22, 2011 9:47 pm

Well, I guess you need to recompile Irrlicht for each release anyway. So you can easily add that one line directly after device creation and check the output. The debug_break has been removed in SVN.

BTW: I'm fluent in English and this is an English forum. So there's no need to translate all postings.

xeno74 · Post by **xeno74** » Sat Apr 23, 2011 10:00 am

hybrid wrote:Well, I guess you need to recompile Irrlicht for each release anyway. So you can easily add that one line directly after device creation and check the output. The debug_break has been removed in SVN.

BTW: I'm fluent in English and this is an English forum. So there's no need to translate all postings.

It works with disabled FBO on Mac OS X 10.4.11 !!!!!!!!!!!!!!!!!!!!!!!!!!

It's amazing

Thank you very much

We've disabled FBO in STK:

Code: Select all

Index: src/graphics/irr_driver.cpp
===================================================================
--- src/graphics/irr_driver.cpp   (revision 8405)
+++ src/graphics/irr_driver.cpp   (working copy)
@@ -213,6 +213,7 @@
     }
     
     m_device->setResizable(false);
+    m_device->getVideoDriver()->disableFeature(EVDF_FRAMEBUFFER_OBJECT);
     
     // Stores the new file system pointer.
     file_manager->setDevice(m_device);

hybrid · Post by **hybrid** » Sat Apr 23, 2011 10:58 am

In general, this is not a good idea. So I wouldn't recomment to do this always. Maybe there's a way to get the OS version and only disable FBOs on PPC OSX in version 10.4.x

Irrlicht Engine

OSX 10.4 problems

Supports Irrlicht SVN (1.8) PPC Macs?

Re: Supports Irrlicht SVN (1.8) PPC Macs?

Problems with 10.4.11 and OSS linux graphics driver