ByteMap plugin

[jkhendrickson]

Greetings!

First let me say, I’m loving Solar2d! Thanks!

I’m trying to debug an app that I’m building on a MacBook Pro running Sequoia 15.2, using Solar2d 2025.3717, and XCode 16.2.

When I run my app in the Solar2d simulator it works great.
When I run my app stand-alone on my iPad it works great.
When I run my app in the XCode simulator (Open in Xcode iOS simulator for iOS 17.2) I get the error in the attached screenshot.

Any help? Thanks again!

Code I’m running…
local byteMap = require(“plugin.Bytemap”)
… later…
bitmap = byteMap.loadTexture{filename = options.image, is_non_external = true}
local w, h = bitmap.width, bitmap.height
– print("Image height " … h … ", width " … w)
bits = bitmap:GetBytes{format = “rgb”}

[StarCrunch]

@vlads said there’s not really support for the ARM64 simulator right now, but from the sounds of it, just hasn’t gotten any attention.

On that note, @Siu (who has a library built on top of the plugin), was tinkering with the code recently and sent me along a modified build script. Maybe this is what is missing, and I just overlooked the signifcance at the time. I’ll see if I can report back with more info.

[jkhendrickson]

THANK YOU for the feedback!
FYI I’m a seasoned C / C++ dev and used to write plugins for Xojo. I’d be happy to help with this.

[StarCrunch]

Ah, fair enough. Then here’s the current iOS build script. And Siu’s modded one:

#!/bin/bash

path=`dirname $0`

OUTPUT_DIR=$1
TARGET_NAME=plugin_Bytemap
OUTPUT_SUFFIX=a
CONFIG=Release

# 
# Checks exit value for error
# 
checkError() {
    if [ $? -ne 0 ]
    then
        echo "Exiting due to errors (above)"
        exit -1
    fi
}

# 
# Canonicalize relative paths to absolute paths
# 
pushd $path > /dev/null
dir=`pwd`
path=$dir
popd > /dev/null

if [ -z "$OUTPUT_DIR" ]
then
    OUTPUT_DIR=.
fi

pushd $OUTPUT_DIR > /dev/null
dir=`pwd`
OUTPUT_DIR=$dir
popd > /dev/null

echo "OUTPUT_DIR: $OUTPUT_DIR"

# Clean
xcodebuild -project "$path/Plugin.xcodeproj" -configuration $CONFIG clean
checkError

# Build for iOS devices
xcodebuild -project "$path/Plugin.xcodeproj" -configuration $CONFIG -sdk iphoneos
checkError

# Build for iOS Simulator
xcodebuild -project "$path/Plugin.xcodeproj" -configuration $CONFIG -sdk iphonesimulator
checkError

# Extract arm64 slice from Simulator build (if present)
SIMULATOR_ARCHIVE="$path/build/$CONFIG-iphonesimulator/lib$TARGET_NAME.$OUTPUT_SUFFIX"
DEVICE_ARCHIVE="$path/build/$CONFIG-iphoneos/lib$TARGET_NAME.$OUTPUT_SUFFIX"

# Create a temporary simulator archive without arm64
TEMP_SIM_ARCHIVE="$SIMULATOR_ARCHIVE-temp"
lipo -remove arm64 "$SIMULATOR_ARCHIVE" -output "$TEMP_SIM_ARCHIVE"
checkError

# Create the universal binary
lipo -create "$DEVICE_ARCHIVE" "$TEMP_SIM_ARCHIVE" -output "$OUTPUT_DIR/lib$TARGET_NAME.$OUTPUT_SUFFIX"
checkError

# Clean up temporary file
rm "$TEMP_SIM_ARCHIVE"

echo "Universal binary created at: $OUTPUT_DIR/lib$TARGET_NAME.$OUTPUT_SUFFIX"

Oh, and plugin source is in the shared folder.

---

On Discord he told me: “I couldn’t get to the bottom of it; since I have an intel based mac I’m not sure it can compile the plugin correctly. I got the conflict resolved but don’t recall whether plugin was still not being included in the iOS Simulator build, or it just wasn’t working for me.”

---

Build notes:

The Apple builds are looking for /Applications/Native (somewhere in Xcode project build settings), a symbolic link pointing to a directory of the same name in Solar. This is relevant since multiple versions might be installed, but at the moment anything even remotely recent will do.

If you look at the mac build script there’s some stuff for moving the built file into a test location, that you can probably crib from if it’s useful.

There are a couple ByteReader.* files from a submodule. If you’re not using any of that (niche) functionality, you might be able to just comment out those bits.

[StarCrunch]

Also, if you do like working on the plumbing bits, I could definitely use some assistance on something later. (I have some ramblings about it in the Discord server, on the #dev channel.) A few minor engine tweaks (WIP branch, so far just Windows), I hope, and then tying some tools together.

[clang]

The core needs to solve the universal linking issue before the plugin can follow up to fully support the emulator.

The catch is that Solar2D’s current (3717) linking approach has some plugins that use lipo to merge archives of different ABI’s, or Architecture, one arm64 and one x86_64, where arm64 refers specifically to the iPhone, not the iPhone Simulator on Apple Silicon. x86_64 refers to the Intel iPhone Simulator.
For example, Bytemap Release v8’s iphone and iphone-sim archive files are binary same. lipo found that there are arm64 and armv7 archives, without x86_64 it cannot support intel emulators, and of course, because the arm64 here is an iphone and not an iphone sim, it cannot support Apple Silicon emulators. As for deprecated armv7, it should be that the plugin template used has not been updated.

I have tried using lipo, which is unable to merge an archive with different platforms but the same ABI, such as iPhone arm64 and iPhone Simulator arm64. I partially used the xcframework for internal linking on the OpenSSL v3 plug-in here, file is too much need to manually load the diff ios/lib/libcrypto.xcframework/Info.plist.

My little idea is that you need to start with libplayer.a on Apple targets and change the way that archive links projects to Apple’s universal xcframework, which contains all the support files for different Platforms and ABIs. Xcode can only link a xcframework to compile the binaries for different platforms and ABIs, otherwise you need to change the link option separately, which is what Solar2D does now.

After the above core is changed to the universal architecture, it is also necessary to change the template of the plug-in so that all plug-ins or libraries linked to the main program are developed and linked using this method in order to make the final binary support emulator.