Why write out Documents/ogre.cfg? (and others)

Discussion of issues specific to mobile platforms such as iOS, Android, Symbian and Meego.
Post Reply
cadabra
Gnoblar
Posts: 22
Joined: Thu Sep 23, 2010 8:32 am
Location: sfbay
x 3

Why write out Documents/ogre.cfg? (and others)

Post by cadabra »

I'm on the 1.7.1 branch, with a project based on the Xcode template. I've spent some time confused about why a newly created RenderWindow was always using 768x1024, even though I had removed the line from ogre.cfg, I was switching between the iPhone and iPad simulators, and UIScreen was reporting the correct values. I built a Debug Ogre and stepped through it, only to realize that the first time I had launched the template it had squirreled away my ogre.cfg into my.app/../Documents/ogre.cfg and was restoring it from showConfigDialog() instead of using the UIScreen dimensions. Why does Ogre-iOS store the configuration in the first place? There's no user interaction during showConfigDialog(). Is there a purpose to this that I'm not aware of (I'm new to Ogre)? Can I safely remove the call to showConfigDialog() on iOS or otherwise prevent this behavior?

Would it make sense to remove the Video Mode line from the default template in the future so that it'll work on both iPhone and iPad?

Other notes:

- The template should use (!NSClassFromString(@"CADisplayLink")) to check if CADisplayLink is supported instead of checking the system version.
- I tried downloading the binary Ogre iPhone SDK, but it wouldn't run in the latest simulator (4.1). Was Ogre built with the 3.0 SDK? In iOS 3.2, Apple changed the simulator ABI and broke a lot of static libraries. In general, Apple recommends that people always build with the latest SDK, but set their deployment target to the lowest version they want to support.
- The CMake configuration should use "$(ARCHS_STANDARD_32_BIT)" instead of "armv6;armv7;" for CMAKE_OSX_ARCHITECTURES. During build, this turns into "armv6 armv7" for the device, and "i386" for the simulator. This in turn requires an edit to the generated Xcode project:

Code: Select all

sed -i '~' -e 's/ARCHS = $(ARCHS_STANDARD_32_BIT);/ARCHS = "$(ARCHS_STANDARD_32_BIT)";/g' OGRE.xcodeproj/project.pbxproj
- I had a really hard time building the SDK with make_iphone.sh. I think trying to coerce CMake to play the EFFECTIVE_PLATFORM_NAME game when it doesn't really support it is making things unnecessarily complicated. Instead I removed all notions of EFFECTIVE_PLATFORM_NAME from the CMake conf, and ended up generating two projects (one for iphoneos, one for iphonesimulator) and then merging them together. Here's the script, if it might be useful to anyone else. Note that xcodebuild -sdk doesn't have to specify the exact iOS version, just -sdk iphoneos is fine.

Code: Select all

#!/usr/bin/env ruby
require 'FileUtils'
include FileUtils

platforms = %w(iphoneos iphonesimulator)
configurations = %w(Debug Release)

SDKBUILDDIR=`pwd`.strip

def platform_build_dir(platform)
  "#{SDKBUILDDIR}/build/#{platform}"
end

def platform_root_dir(platform)
  `xcodebuild -version -sdk #{platform} PlatformPath`.strip
end

def check_exit(unused)
  raise "error: child process exited with #{$?}." if $? != 0
end

should_clean = ARGV[0] == "clean"

platform_root = platform_root_dir "iphoneos"
puts "Using platform_root: \"#{platform_root}\". Use xcode-select to switch."

lipo = "#{platform_root}/Developer/usr/bin/lipo"

ogre_version = nil

platforms.each do |platform|
  b = platform_build_dir platform
  rm_rf [b] if should_clean
  mkdir_p b
  cd b do
    puts "Building platform #{platform} in #{`pwd`.strip}"
    check_exit(system("cmake -DOGRE_BUILD_PLATFORM_IPHONE:BOOL=TRUE -DOGRE_INSTALL_DEPENDENCIES:BOOL=TRUE -G Xcode ../../../.."))
    check_exit(system("sed -i '~' -e 's/ARCHS = $(ARCHS_STANDARD_32_BIT);/ARCHS = \"$(ARCHS_STANDARD_32_BIT)\";/g' OGRE.xcodeproj/project.pbxproj"))
    ogre_version=`cat version.txt`
    configurations.each do |configuration|
      check_exit(system("xcodebuild -project OGRE.xcodeproj -target install -parallelizeTargets -configuration #{configuration} -sdk #{platform}"))
    end
  end
end

combined_build_dir = platform_build_dir "combined"
mkdir_p combined_build_dir

# Combine device and simulator binaries for convenient linking from Xcode
configurations.each do |configuration|
  libnames = platforms.map{|p| "#{platform_build_dir p}/lib/#{configuration}/*.a" }.
    map{|p| Dir.glob p }.flatten.map{|p| File.basename p }
  dst_dir = "#{combined_build_dir}/lib/#{configuration}"
  rm_rf [dst_dir] if should_clean
  mkdir_p dst_dir
  libnames.each do |libname|
      next if libname =~ /^Sample_/
    paths = platforms.map{|p| "#{platform_build_dir p}/lib/#{configuration}/#{libname}" }
    paths_args = paths.map{|p| "\"#{p}\"" }.join ' '
    check_exit(system("\"#{lipo}\" -create -output \"#{dst_dir}/#{libname}\" #{paths_args}"))
  end
end

# Bring over libraries of dependencies
configurations.each do |configuration|
  dst_dir = "#{combined_build_dir}/lib/#{configuration}"
  check_exit(system("cp \"../../iPhoneDependencies/lib/#{configuration}/\"* \"#{dst_dir}/\""))
end

# Copy header files
rm_rf ["#{combined_build_dir}/include"] if should_clean
cp_r "#{platform_build_dir 'iphoneos'}/sdk/include", "#{combined_build_dir}"
This produces ./build/combined which contains include, lib/Debug, lib/Release. lib/Debug isn't terribly useful for iterative development, but helpful if you need to step inside Ogre or any of the other dependencies for some reason.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: Why write out Documents/ogre.cfg? (and others)

Post by masterfalcon »

The configuration is stored for the same reason that it is on the desktop, so that configuration only takes place once. So the developer could set something non-standard but only have do to it on the first launch and not have to worry about it changing on other launches. Granted, it is of less value than when there is a config dialog, but not completely useless.

The latest Ogre SDK was built before 4.0 came out which is why it is built against the 3.0 SDK. I agree that it would be nice to use the symbol ARCHS_STANDARD_32_BIT. I'm not sure if this is the case still, but at the time that I added "armv6;armv7;", it was to workaround an issue with CMake. "armv6;armv7;" is what is actually written into the Xcode project file anyways, so doing it this way, while not ideal, is still correct.

make_iphone.sh hasn't been tested since the 1.7.1 release and may not be compatible with current versions of CMake. The purpose of the script is to create the prebuilt SDKs.

Of course patches are always welcome.
cadabra
Gnoblar
Posts: 22
Joined: Thu Sep 23, 2010 8:32 am
Location: sfbay
x 3

Re: Why write out Documents/ogre.cfg? (and others)

Post by cadabra »

Thanks for the reply!

I see. Is there a performance aspect as well -- does fresh configuration delay app loading significantly? The iPhone Simulator uses the same application data for both the iPhone and iPad simulators, which means that the stored ogre.cfg will consistently misconfigure one of the simulators. Currently, I'm deleting Documents/ogre.cfg before initializing Ogre. What would be a reasonable long-term solution for this? Would it make sense for Ogre to ignore the Video Mode argument on iOS? Currently it just ends up creating windows that are only partially visible. I also saw you mention Content Scaling in a separate thread. Setting this in ogre.cfg I think would cause similar issues for universal apps.
The latest Ogre SDK was built before 4.0 came out which is why it is built against the 3.0 SDK.
This would mean that no-one's been able to use that SDK on the simulator since iOS 3.2. Am I the only seeing that or is it working for everyone else? Is everyone just developing on the device instead? That would also explain why no-one's hitting the Documents/ogre.cfg behavior.
"armv6;armv7;" is what is actually written into the Xcode project file anyways, so doing it this way, while not ideal, is still correct.
Using ARCHS_STANDARD_32_BIT writes ARCHS_STANDARD_32_BIT to the project file, and it's resolved to the appropriate setting at build time instead. (-- it's resolved by the Xcode build system. ARCHS_STANDARD_32_BIT is an Xcode builtin). The issue I saw when trying to build with "armv6;armv7;" was that the iphonesimulator build tried to use "armv6;armv7;" as well, instead of i386. I had to pass ARCHS=i386 to xcodebuild as a work-around. ARCHS_STANDARD_32_BIT worked for me using CMake 2.8.2.

Thanks! Like I said, I'm new to Ogre, so I just wanted to bounce my notes off somebody before preparing patches.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: Why write out Documents/ogre.cfg? (and others)

Post by masterfalcon »

The only time that that becomes an issue with during development. In the real world, app data is not shared between devices and is backed up separately. Content scaling gets ignored if it is not supported by either the device or OS and again, the setting won't carry over from device to device so it shouldn't be an issue either.
This would mean that no-one's been able to use that SDK on the simulator since iOS 3.2. Am I the only seeing that or is it working for everyone else? Is everyone just developing on the device instead? That would also explain why no-one's hitting the Documents/ogre.cfg behavior.
Using the prebuilt SDK, yes. Otherwise, building the SDK is pretty trivial and will be switched to using 4.0 on the next update.

I'll have to revisit the ARCHs issue again. It's been difficult because CMake's Xcode generator has been shifty recently. A moving target is tough to hit.
Post Reply