Platform Define

For the Wii.cmake toolchain file we get __wii__ and HW_RVL (for revolution) defined for the Wii. For the Gamecube file we get __gamecube__ and HW_DOL (for dolphin)

Big Endian

Tracy has no support for big endian devices like the Wii so I had to implement support myself. This meant I had to gain an understanding of how Tracy sends and receives data in order to come up with the best solution for endian conversions.

Ideally we can have all data sent across the network in big endian, so our Wii doesn’t have to do any conversions at runtime.

The Initial Handshake

The handshake is the first exchange of information that occurs when connecting to a client. The server (the PC running the profiler GUI) will send something known as a shibboleth which is just an identification string known at compile-time and the protocol version which is a 32-bit unsigned integer.

If shibboleth or protocol version doesn’t match on the client, the connection will be rejected. Otherwise the client will send a WelcomeMessage which contains a bunch of data about the client like cpuid, sampling period, timer multiplier, program name, and pid.

struct WelcomeMessage
{
    double timerMul;
    int64_t initBegin;
    int64_t initEnd;
    uint64_t resolution;
    uint64_t epoch;
    uint64_t exectime;
    uint64_t pid;
    int64_t samplingPeriod;
    uint8_t flags;
    uint8_t cpuArch;
    char cpuManufacturer[12];
    uint32_t cpuId;
    char programName[WelcomeMessageProgramNameSize];
    char hostInfo[WelcomeMessageHostInfoSize];
}

So we need a clever way to byteswap the protocol version and the elements within WelcomeMessage if we want to send them across the network in big endian. I imagine we’re going to have to do this A LOT. So we must make it as easy as possible to convert structs and primitives.

Byteorder conversion functions

Let’s first make a new compile-time definition: TRACY_BIGENDIAN. When defined, all data sent through the network must be in big endian byteorder. If not defined, then all data will be sent in little endian byteorder. So theoretically we could have TRACY_BIGENDIAN not defined and big endian devices would know to convert to little endian.

Also, if the system’s native byteorder is the same as the network’s byteorder, then all the endian conversion code should be no-ops. Switching byteorder from little endian to big endian and vice versa is the exact same operation which is handy.

We can start with a function that will return the byteorder we are using for the network.

constexpr std::endian network_byteorder()
{
#if TRACY_BIGENDIAN
    return std::endian::big;
#else
    return std::endian::little;
#endif
}

We can use this to check at compile-time if the host’s byteorder is the same as the network’s:

if constexpr( std::endian::native == network_byteorder() )

Big shoutout to C++20 for adding std::endian!

Let’s start by handling our integer types:

template<typename T>
    requires std::is_integral_v<T>
constexpr T convert_endian( T value ) noexcept
{
    if constexpr( std::endian::native == network_byteorder() || sizeof( T ) == 1 )
    {
        return value;
    }
    else if constexpr( sizeof( T ) == 2 )
    {
        return static_cast<T>( __builtin_bswap16( static_cast<uint16_t>( value ) ) );
    }
    else if constexpr( sizeof( T ) == 4 )
    {
        return static_cast<T>( __builtin_bswap32( static_cast<uint32_t>( value ) ) );
    }
    else if constexpr( sizeof( T ) == 8 )
    {
        return static_cast<T>( __builtin_bswap64( static_cast<uint64_t>( value ) ) );
    }
}

There are various enums throughout the codebase, so we can handle those now too:

template<typename T>
    requires std::is_enum_v<T>
constexpr T convert_endian( T value ) noexcept
{
    return static_cast<T>( convert_endian( static_cast<std::underlying_type_t<T>>( value ) ) );
}

Next up is floats and doubles. Here I’ve made the assumption that whatever CPU is running this conversion code is IEE-754 compliant. This means that binary 32-bit and binary 64-bit formats don’t have padding bits. So I can treat a floating point type’s bytes the same as an integer type’s when swapping.

Instead of doing a memcpy into a uint type or a reinterpret_cast, we can use C++20′s std::bit_cast!

template<typename T>
    requires std::is_floating_point_v<T>
constexpr T convert_endian( T value ) noexcept
{
    if constexpr( std::endian::native == network_byteorder() )
    {
        return value;
    }
    else if constexpr( sizeof( T ) == sizeof( float ) )
    {
        static_assert( sizeof( float ) == sizeof( uint32_t ), "float must be 4 bytes" );
        uint32_t tmp = std::bit_cast<uint32_t>( value );
        tmp = convert_endian( tmp );
        return std::bit_cast<float>( tmp );
    }
    else if constexpr( sizeof( T ) == sizeof( double ) )
    {
        static_assert( sizeof( double ) == sizeof( uint64_t ), "double must be 8 bytes" );
        uint64_t tmp = std::bit_cast<uint64_t>( value );
        tmp = convert_endian( tmp );
        return std::bit_cast<double>( tmp );
    }
}

Lastly, we need a cunning way to convert structs. There’s no generic one size fits all solution here for structs that aren’t trivial and have some padding. so structs will have to implement a method called convert_endian() which will byteswap every element of the struct.

template<typename T>
concept StructWithConvertEndianMethod = requires( T value ) {{ value.convert_endian()}; };

template<StructWithConvertEndianMethod T>
constexpr void convert_endian( T& value )
{
    if constexpr( std::endian::native == network_byteorder() )
    {
        return;
    }
    else
    {
        value.convert_endian();
    }
}

So that WelcomeMessage struct mentioned earlier will have a convert_endian() method like so:

void convert_endian()
{
    timerMul = ::convert_endian( timerMul );
    initBegin = ::convert_endian( initBegin );
    initEnd = ::convert_endian( initEnd );
    resolution = ::convert_endian( resolution );
    epoch = ::convert_endian( epoch );
    exectime = ::convert_endian( exectime );
    pid = ::convert_endian( pid );
    samplingPeriod = ::convert_endian( samplingPeriod );
    flags = ::convert_endian( flags );
    cpuArch = ::convert_endian( cpuArch );
    cpuId = ::convert_endian( cpuId );
}

Now we have all the tools needed to effortlessly byteswap all the things! We don’t even have to think about checking host byteorder since that’s figured out for us too at compile-time and convert_endian() will vanish to a no-op if needed!

Converting the byteorder of the protocol version and welcome message were no problem, and we’ve successfully gotten past the handshake!

Sending and Receiving Queue Items

You ready for the struct to end all structs? In some ways this could be seen as a blessing though. After the handshake tracy sends everything else as compressed lz4 and this is done in one place generalized with this QueueItem struct.

So we can just create one big fat convert_endian() method for QueueItem to do the endian conversion before sending it to be compressed and sent.

struct QueueItem
{
    QueueHeader hdr;
    union
    {
        QueueThreadContext threadCtx;
        QueueZoneBegin zoneBegin;
        QueueZoneBeginLean zoneBeginLean;
        QueueZoneBeginThread zoneBeginThread;
        QueueZoneEnd zoneEnd;
        QueueZoneEndThread zoneEndThread;
        QueueZoneValidation zoneValidation;
        QueueZoneValidationThread zoneValidationThread;
        QueueZoneColor zoneColor;
        QueueZoneColorThread zoneColorThread;
        QueueZoneValue zoneValue;
        QueueZoneValueThread zoneValueThread;
        QueueStringTransfer stringTransfer;
        QueueFrameMark frameMark;
        QueueFrameVsync frameVsync;
        QueueFrameImage frameImage;
        QueueFrameImageFat frameImageFat;
        QueueSourceLocation srcloc;
        QueueZoneTextFat zoneTextFat;
        QueueZoneTextFatThread zoneTextFatThread;
        QueueLockAnnounce lockAnnounce;
        QueueLockTerminate lockTerminate;
        QueueLockWait lockWait;
        QueueLockObtain lockObtain;
        QueueLockRelease lockRelease;
        QueueLockReleaseShared lockReleaseShared;
        QueueLockMark lockMark;
        QueueLockName lockName;
        QueueLockNameFat lockNameFat;
        QueuePlotDataInt plotDataInt;
        QueuePlotDataFloat plotDataFloat;
        QueuePlotDataDouble plotDataDouble;
        QueueMessage message;
        QueueMessageColor messageColor;
        QueueMessageLiteral messageLiteral;
        QueueMessageLiteralThread messageLiteralThread;
        QueueMessageColorLiteral messageColorLiteral;
        QueueMessageColorLiteralThread messageColorLiteralThread;
        QueueMessageFat messageFat;
        QueueMessageFatThread messageFatThread;
        QueueMessageColorFat messageColorFat;
        QueueMessageColorFatThread messageColorFatThread;
        QueueGpuNewContext gpuNewContext;
        QueueGpuZoneBegin gpuZoneBegin;
        QueueGpuZoneBeginLean gpuZoneBeginLean;
        QueueGpuZoneEnd gpuZoneEnd;
        QueueGpuTime gpuTime;
        QueueGpuCalibration gpuCalibration;
        QueueGpuTimeSync gpuTimeSync;
        QueueGpuContextName gpuContextName;
        QueueGpuContextNameFat gpuContextNameFat;
        QueueGpuAnnotationName gpuAnnotationName;
        QueueGpuAnnotationNameFat gpuAnnotationNameFat;
        QueueMemAlloc memAlloc;
        QueueMemFree memFree;
        QueueMemDiscard memDiscard;
        QueueMemNamePayload memName;
        QueueThreadGroupHint threadGroupHint;
        QueueCallstackFat callstackFat;
        QueueCallstackFatThread callstackFatThread;
        QueueCallstackAllocFat callstackAllocFat;
        QueueCallstackAllocFatThread callstackAllocFatThread;
        QueueCallstackSample callstackSample;
        QueueCallstackSampleFat callstackSampleFat;
        QueueCallstackFrameSize callstackFrameSize;
        QueueCallstackFrameSizeFat callstackFrameSizeFat;
        QueueCallstackFrame callstackFrame;
        QueueSymbolInformation symbolInformation;
        QueueSymbolInformationFat symbolInformationFat;
        QueueCrashReport crashReport;
        QueueCrashReportThread crashReportThread;
        QueueSysTime sysTime;
        QueueSysPower sysPower;
        QueueContextSwitch contextSwitch;
        QueueThreadWakeup threadWakeup;
        QueueTidToPid tidToPid;
        QueueHwSample hwSample;
        QueuePlotConfig plotConfig;
        QueueParamSetup paramSetup;
        QueueCpuTopology cpuTopology;
        QueueExternalNameMetadata externalNameMetadata;
        QueueSymbolCodeMetadata symbolCodeMetadata;
        QueueSourceCodeMetadata sourceCodeMetadata;
        QueueSourceCodeNotAvailable sourceCodeNotAvailable;
        QueueFiberEnter fiberEnter;
        QueueFiberLeave fiberLeave;
        QueueGpuZoneAnnotation zoneAnnotation;
    };
};

Only gotcha was this variant which stores its size value in a non standard 6 byte manner

struct QueueMemAlloc
{
    int64_t time;
    uint32_t thread;
    uint64_t ptr;
    char size[6];
};

since this only happens once I just explicitly converted it in place instead of bothering with a new convert_endian implementation.

And it only grows larger as more features are added to Tracy. So we write a python script which parses the C++ header and generates the convert_endian() method. That way, we can just run the script whenever we upgrade Tracy and the new gigantic method will be regenerated.

This approach worked well and we were able to see profiling data from the Wii on Tracy’s UI! As for performance, our Wii was able to hit a consistent  62 FPS with a few zones.

Threading

libogc has a very straightforward threading implementation under ogc/lwp.h functions are prefixed with LWP_ We can create, join, get self, sleep, signal, set priority and more.

class Thread
{
public:
    Thread( void ( *func )( void* ptr ), void* ptr )
        : m_func( func )
        , m_ptr( ptr )
    {
        LWP_CreateThread( &m_thread, Launch, this, nullptr, 0, 64 );
    }

    ~Thread()
    {
        LWP_JoinThread( m_thread, nullptr );
    }

    [[nodiscard]] lwp_t Handle() const { return m_thread; }

private:
    static void* Launch( void* ptr )
    {
        ( (Thread*)ptr )->m_func( ( (Thread*)ptr )->m_ptr );
        return nullptr;
    }

    void ( *m_func )( void* ptr );
    void* m_ptr;
    lwp_t m_thread;
};

The implementation is pretty much identical to Tracy’s pthread implementation:

class Thread
{
public:
    Thread( void(*func)( void* ptr ), void* ptr )
        : m_func( func )
        , m_ptr( ptr )
    {
        pthread_create( &m_thread, nullptr, Launch, this );
    }

    ~Thread()
    {
        pthread_join( m_thread, nullptr );
    }

    pthread_t Handle() const { return m_thread; }

private:
    static void* Launch( void* ptr ) { ((Thread*)ptr)->m_func( ((Thread*)ptr)->m_ptr ); return nullptr; }
    void(*m_func)( void* ptr );
    void* m_ptr;
    pthread_t m_thread;
};

Also had to do a similar sort of thing for TracyMutex

class TracyMutex
{
    mutex_t m_mutex;

public:
    TracyMutex() { LWP_MutexInit( &m_mutex, false ); }
    ~TracyMutex() { LWP_MutexDestroy( m_mutex ); }
    void lock() { LWP_MutexLock( m_mutex ); }
    void unlock() { LWP_MutexUnlock( m_mutex ); }
    bool try_lock() { return LWP_MutexTryLock( m_mutex ) == 0; }
};

Networking

The Wii appears to have equivalent functions for most of the POSIX socket API used by Tracy. However the addrinfo struct doesn’t exist, and so neither does getaddrinfo() and freeaddrinfo(). What even is addrinfo? Here’s the description for getaddrinfo() in the man-pages:

> Given node and service, which identify an Internet host and a service, getaddrinfo() returns one or more addrinfo structures, each of which contains an Internet address that can be specified in a call to bind(2) or connect(2). The getaddrinfo() function combines the functionality provided by the gethostbyname(3) and getservbyname(3) functions into a single interface, but unlike the latter functions, getaddrinfo() is reentrant and allows programs to eliminate IPv4-versus-IPv6 dependencies.

So basically it’s a protocol-agnostic way of representing an address. The Wii does have a net_gethostbyname() function so maybe we just need to learn more about that. Maybe it’ll do everything we need without the additional features of addrinfo.

> The gethostbyname(), gethostbyaddr(), herror(), and hstrerror() functions are obsolete. Applications should use getaddrinfo(3), getnameinfo(3), and gai_strerror(3) instead.

So it’s obsolete. Wonder why? My guess is probably because it’s pre-IPv6?

> The gethostbyname() function returns a structure of type hostent for the given host name. Here name is either a hostname or an IPv4 address in standard dot notation.

Yup this is IPv4 only. And that makes sense because the Wii doesn’t support IPv6, so there’s no need solve IPv6 problems on it.

UDP Broadcast

The Wii’s socket API would not allow me to open up a UDP socket. Although it’s a nice-to-have and not a requirement, it prevents me from making the Wii advertise itself to tracy servers.

Timing

Libogc has a very convenient macro called ticks_to_nanosecs which converts the Wii’s CPU ticks to nanoseconds for us! We can get CPU ticks with gettime()

#define ticks_to_nanosecs(ticks) ((((u64)(ticks)*8000)/(u64)(TB_TIMER_CLOCK/125)))

64-bit Atomics

Tracy makes use of 64-bit atomics, and the Wii toolchain doesn’t have an implementation for 64-bit atomics in the standard library. Fortunately we are super lucky that the Wii only has a single core CPU. This means that the only way to achieve concurrency is to use an interrupt handler. So we can simply emulate atomic operations by disabling interrupts temporarily.

uint64_t __atomic_load_8( const volatile void* ptr, int )
{
    uint32_t level = IRQ_Disable();
    uint64_t val = *(const volatile uint64_t*)ptr;
    IRQ_Restore( level );
    return val;
}

void __atomic_store_8( volatile void* ptr, uint64_t val, int )
{
    uint32_t level = IRQ_Disable();
    *(volatile uint64_t*)ptr = val;
    IRQ_Restore( level );
}

uint64_t __atomic_fetch_add_8( volatile void* ptr, uint64_t val, int )
{
    uint32_t level = IRQ_Disable();
    uint64_t old = *(volatile uint64_t*)ptr;
    *(volatile uint64_t*)ptr = old + val;
    IRQ_Restore( level );
    return old;
}

The compiler only asked for these three implementations. So reading the value, assigning the value, and adding to the value.

Memory Reductions

Here’s a snippet from the profiler constructor. The Wii has 88MB of total system memory and these queues are too large, causing the Wii program to crash. Fortunately I haven’t noticed any issues severely downsizing them!

    , m_serialQueue( 1024*1024 )
    , m_serialDequeue( 1024*1024 )
#ifndef TRACY_NO_FRAME_IMAGE
    , m_fiQueue( 16 )
    , m_fiDequeue( 16 )
#endif
    , m_symbolQueue( 8*1024 )
    , m_frameCount( 0 )
    , m_isConnected( false )
#ifdef TRACY_ON_DEMAND
    , m_connectionId( 0 )
    , m_symbolsBusy( false )
    , m_deferredQueue( 64*1024 )
#endif

Here is the function that handles incoming crash reports. Slices in rust are awesome and you can see heavy use of them here as we parse out the bytes from the request.

We also send a discord webhook notification to our server!

async fn handle_crash_report(
    State(path): State<PathBuf>,
    Query(_params): Query<CrashReportParams>,
    _headers: HeaderMap,
    body: Bytes,
) -> impl IntoResponse {
    let content = match decompress_data(&body) {
        Ok(content) => content,
        Err(e) => {
            error!("Failed to decompress request body with zlib: {e}");
            return StatusCode::BAD_REQUEST;
        }
    };

    let mut bytes_read = 0;
    if &content[0..3] != b"CR1" {
        error!("Malformed crash report file header! {:?}", &content[0..3]);
        return StatusCode::BAD_REQUEST;
    }
    bytes_read += 3;

    let crash_id = match read_string(&content[bytes_read..], &mut bytes_read) {
        Ok(crash_id_str) => crash_id_str,
        Err(e) => {
            error!("{}", e);
            return StatusCode::BAD_REQUEST;
        }
    };
    info!("Received Crash Report: {}", crash_id);

    bytes_read += advance_to_next_item(&content[bytes_read..]);
    let _crash_filename = match read_string(&content[bytes_read..], &mut bytes_read) {
        Ok(crash_filename_str) => crash_filename_str,
        Err(e) => {
            error!("{}", e);
            return StatusCode::BAD_REQUEST;
        }
    };

    bytes_read += advance_to_next_item(&content[bytes_read..]);
    let file_size = u32::from_le_bytes(content[bytes_read..bytes_read + 4].try_into().unwrap());
    bytes_read += 4;
    if file_size as usize != content.len() {
        error!("File size specified in file is different from size of data extracted!");
        return StatusCode::BAD_REQUEST;
    }

    let number_of_files = content[bytes_read];
    bytes_read += 1;

    bytes_read += advance_to_next_item(&content[bytes_read..]);
    let files = match extract_files(&content[bytes_read..], &mut bytes_read, number_of_files) {
        Ok(files) => files,
        Err(e) => {
            error!("{}", e);
            return StatusCode::BAD_REQUEST;
        }
    };

    let crash_context_file = match files
        .iter()
        .find(|file| file.name == "CrashContext.runtime-xml")
    {
        Some(crash_context_file) => crash_context_file,
        None => {
            error!("CrashContext.runtime-xml not found!");
            return StatusCode::BAD_REQUEST;
        }
    };

    let crash_context_xml = str::from_utf8(crash_context_file.contents).unwrap();
    let crash_overview = CrashOverview::parse(crash_context_xml, &files);
    info!("{}", crash_overview.error);

    let timestamp = Utc::now().format("%Y-%m-%d_%H%M%S").to_string();
    let path = Path::new(&path).join(&timestamp).join("CrashData.zlib");
    if let Some(parent) = path.parent() {
        fs::create_dir_all(parent).unwrap();
    }
    let mut file = fs::File::create(&path).unwrap();
    file.write_all(&body as &[u8]).unwrap();

    let mut json_file =
        fs::File::create(&path.parent().unwrap().join("CrashOverview.json")).unwrap();
    let json_content = serde_json::to_string_pretty(&crash_overview).unwrap();
    json_file.write_all(&json_content.as_bytes()).unwrap();

    let url = match std::env::var("CRASH_REPORT_DISCORD") {
        Ok(url) => url,
        Err(_) => return StatusCode::OK,
    };
    let client = WebhookClient::new(&url);
    let base_url = match std::env::var("CRASH_REPORT_BASE_URL") {
        Ok(url) => url,
        Err(_) => return StatusCode::OK,
    };
    client
        .send(|message| {
            message
                .username("Crash Report")
                .embed(|embed| {
                    embed
                        .title("Crash!")
                        .description(&format!("{}#{}", base_url, timestamp))
                        .field(
                            "User Description",
                            &format!("{}", crash_overview.user_description),
                            false,
                        )
                        .field("Error", &format!("{}", crash_overview.error), false)
                })
        })
        .await
        .unwrap();

    StatusCode::OK
}

Generating HTML for the UI

I shamelessly used an LLM to generate the CSS and add the modal that pops up when you click on a crash. But using askama to generate html from rust was so easy.

To list out the crash reports in HTML I just had to do this:

<h1>Crash Reports</h1>

{% if crashes.is_empty() %}
    <div class="no-crashes">No Crashes Found</div>
{% else %}
    <div class="summary">
        Total Crashes: <strong>{{ crashes.len() }}</strong>
    </div>

    <div class="search-container">
        <input id="search" class="search-input" type="text" placeholder="Search by timestamp, error, or user description..." oninput="filterCrashes()">
    </div>

    <div class="crash-list">
        {% for crash in crashes %}
            <div class="crash-row"
                 data-timestamp="{{ crash.timestamp | lower }}"
                 data-error="{{ crash.overview.error | lower }}"
                 data-user-description="{{ crash.overview.user_description | lower }}"
                 onclick="openModal('{{ crash.timestamp }}')">
                <div class="timestamp">{{ crash.timestamp }}</div>
                <div class="error-preview">{{ crash.overview.error }}</div>
            </div>

The stuff inside {% %} is for askama which generates the HTML on the fly with the .render() method at the end of the following snippet:

#[derive(Template)]
#[template(path = "crash_list.html")]
struct CrashListTemplate {
    crashes: Vec<Crash>,
}

async fn handle_list(State(path): State<PathBuf>) -> impl IntoResponse {
    let mut crashes = Vec::new();

    for entry in fs::read_dir(&path).unwrap() {
        let entry = entry.unwrap();
        let path = entry.path();
        let timestamp = path
            .file_name()
            .unwrap()
            .to_os_string()
            .to_str()
            .unwrap()
            .to_string();
        let json_file = fs::read(path.join("CrashOverview.json")).unwrap();
        let json_str = str::from_utf8(&json_file).unwrap();
        let overview = serde_json::from_str::<CrashOverview>(json_str).unwrap();
        crashes.push(Crash {
            timestamp,
            overview,
        });
    }

    let crash_template = CrashListTemplate { crashes };
    (StatusCode::OK, Html(crash_template.render().unwrap())).into_response()
}

With a bit of CSS magic we can get a site that looks like this

The code is not open source yet. Still need to decide if I release it through 777 studios or just personally. Feel free to leave a comment if you want the code open sourced and I’ll do my best to expedite it!

So instead of going in guns blazing and rushing to get Unreal Engine 5 compiling, I needed to take a step back and think about my paper.

The proposal

I had to submit a formal three page proposal, which was graded by my supervisor. This was the first time I had to really think about the meaning behind my project. What actual research will I be contributing to the academic world? Sadly that can’t just be a yes or no answer. A question like “Can I get Unreal Engine 5 on the Wii?” is not good enough. Even after writing the proposal, I still have no idea what my research question will be.

The proposal is obviously very subject to change, it was just a formal deadline I had to meet. But it is going in a direction which could turn into some good academic research. As suggested in the paper, I could focus on graphics. The Wii doesn’t have programmable shaders, it’s on a fixed-function pipeline. As far as I understand, Unreal’s material system generates HLSL code under the hood. So, not only will I have the challenge of wrapping a legacy graphics API into a modern graphics wrapper, but I’ll also have to come up with fixed-function techniques to use in the absense of shaders.

My personal aim is to get the game I’ve been working on with 777 Studios up and running on the Wii with motion controls. But my project may have to dive deep on graphics research to fulfill academic expectations and deadlines.

Another vertical to explore is asset cooking. The Wii’s byte order is big endian which is different from any platform supported by Unreal Engine. We also need to heavily optimize assets for the Wii’s architecture and very limited system memory.

Honors Project Proposal (PDF)

What would a minimum viable product look like?

What if it’s just not feasible to get Unreal Engine 5 on the Wii? It’s too early to know for sure. If my research question is something to do with fixed-function techniques without shaders, I’d be able to pivot pretty easily. I could at least port a modern graphics wrapper such as webGPU to the Wii instead and go all in on fixed-function vs programmable pipelines.

But there’s also so much more to the Wii than graphics! It has a sick controller with IR and motion sensors that I also want to spend time playing with, but I don’t know how I can scope a research question that broadly encompasses the Wii.

The next submission is a couple weeks away. It’s a feasibility demo where I must provide a research question, gantt chart, risk analysis, code, structured diagram, and a literature review in a  20 minute presentation/discussion.

Ethical concerns

I am no lawyer, but I think this project is legal in the UK. I don’t expect this will be high on Nintendo’s hitlist anyway since it doesn’t aid piracy in any way.

The only potential line I may have crossed is CDPA 1988, s.296ZA-296ZB which is prohibition of circumvention. It’s not 100% clear to me, but I might not have been allowed to circumvent the Wii’s security measures to install the homebrew channel and run my own code on the Wii. I think I’m good though because I’m not doing it for the purpose of obtaining access to copyrighted or protected work, and I’m also not distributing any code or information on how to circumvent the Wii’s security.

I also just don’t have to mention it in my project at all. I should just say I ran my code on the Wii without going into depth on how I loaded it on there.

Reverse Engineering the Crash Report File

I sent two different crashes to my server. One included the game’s logfile and one did not. With the power of xxd and git diffs maybe we can notice some patterns.

--- no logfile
+++ with logfile

 00000000: 4352 3104 0100 0055 4543 432d 5769 6e64  CR1....UECC-Wind
-00000010: 6f77 732d 3142 3033 4437 3236 3435 4336  ows-1B03D72645C6
-00000020: 3245 4333 3841 4246 3646 4133 3043 3733  2EC38ABF6FA30C73
-00000030: 3741 3430 5f30 3030 3000 0000 0000 0000  7A40_0000.......
+00000010: 6f77 732d 3843 3133 4541 3934 3444 3442  ows-8C13EA944D4B
+00000020: 3835 3739 3534 3439 3843 4245 4138 4333  857954498CBEA8C3
+00000030: 4232 3246 5f30 3030 3000 0000 0000 0000  B22F_0000.......
 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................

The header remains the same. We can see it starts with CR1 followed by a few mysterious bytes: 04 01 00 00

Originally I thought the byte after CR1 was the number of files since there are 4 files (including the log). But the diff don’t lie, that byte is 04 even with 3 files. After those mysterious bytes we get the crash GUID which has obviously changed between crashes.

 000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000100: 0000 0000 0000 0000 0000 0004 0100 0055  ...............U
-00000110: 4543 432d 5769 6e64 6f77 732d 3142 3033  ECC-Windows-1B03
-00000120: 4437 3236 3435 4336 3245 4333 3841 4246  D72645C62EC38ABF
-00000130: 3646 4133 3043 3733 3741 3430 5f30 3030  6FA30C737A40_000
+00000110: 4543 432d 5769 6e64 6f77 732d 3843 3133  ECC-Windows-8C13
+00000120: 4541 3934 3444 3442 3835 3739 3534 3439  EA944D4B85795449
+00000130: 3843 4245 4138 4333 4232 3246 5f30 3030  8CBEA8C3B22F_000
 00000140: 302e 7565 6372 6173 6800 0000 0000 0000  0.uecrash.......
 00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Then there’s a bunch of padding until we hit the same mysterious bytes 04 01 00 00 right before hitting what must be the name of the file that was sent to us with the file extension .uecrash

So maybe 04 01 00 00 is some kind of delmiter to mark the start of some data?

 000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000200: 0000 0000 0000 0000 0000 0000 0000 0000  ................
-00000210: 0000 0009 180d 0003 0000 0000 0000 0004  ................
+00000210: 0000 00b8 f90d 0004 0000 0000 0000 0004  ................
 00000220: 0100 0043 7261 7368 436f 6e74 6578 742e  ...CrashContext.
 00000230: 7275 6e74 696d 652d 786d 6c00 0000 0000  runtime-xml.....
 00000240: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Many zeroes later we get to something interesting! A subtle difference right before this filename? Maybe we have some sort of file index since you can see no log has a 3 and with log has a 4. But what about the bytes that come before?

if we skip right to the end of each hexdump we can see which address each byte ends on.

-000d1800: 0000 0000 0000 0000 00                   .........
+000df9b0: 0000 0000 1900 0000                      ........

Windows is little endian so if we read the bytes in the diff backwards:

-09 180d 00 ==> 000d1809
+b8 f90d 00 ==> 000df9b8

We seem to get the address of one byte more than the final byte in the entire dump. So this marks the end of the entire file and has nothing to do with CrashContext.runtime-xml

After what I’m calling for now the file index, we get a bit of padding, 04 01 00 00, then the filename.

 000002f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000300: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000310: 0000 0000 0000 0000 0000 0000 0000 0000  ................
-00000320: 0000 0000 0000 00f8 a700 003c 3f78 6d6c  ...........<?xml
+00000320: 0000 0000 0000 0007 9e00 003c 3f78 6d6c  ...........<?xml
 00000330: 2076 6572 7369 6f6e 3d22 312e 3022 2065   version="1.0" e
 00000340: 6e63 6f64 696e 673d 2255 5446 2d38 223f  ncoding="UTF-8"?
 00000350: 3e0d 0a3c 4647 656e 6572 6963 4372 6173  >..<FGenericCras

Many zeroes later we get to a difference just before the file’s content. This could be a 4-bit unsigned integer for file size. Reading as little endian we get:

no log: 0xa7f8 = 43,000 bytes

with log: 0x9e07 = 40,455 bytes

it’s a reasonable assumption although I wonder what the 3kb of extra stuff in the no log version is.

We can prove this theory by checking our calculator. The xml starts at 0x032B so if we add our sizes we should get taken to the end of the content.

for no log: 0x032B + 0xa7f8 = 0xab23

0000ab10: 6572 6963 4372 6173 6843 6f6e 7465 7874  ericCrashContext
0000ab20: 3e0d 0a01 0000 0004 0100 0043 7261 7368  >..........Crash
0000ab30: 5265 706f 7274 436c 6965 6e74 2e69 6e69  ReportClient.ini

for with log: 0x032B + 0x9e07 = 0xa132

0000a120: 7269 6343 7261 7368 436f 6e74 6578 743e  ricCrashContext>
0000a130: 0d0a 0100 0000 0401 0000 4372 6173 6852  ..........CrashR
0000a140: 6570 6f72 7443 6c69 656e 742e 696e 6900  eportClient.ini.

So yup that’s definitely file size!

Since the xml was quite different, the git diff is no longer useful. Anyways we’ve seen enough.

In both cases, after the content is finished, we go right back to hitting 04 01 00 00 and starting the name of the next file. So that “file index” I mentioned earlier is just a count for how many files there are since it only appears once.

To sum it all up

Unreal’s crash report file is as follows:

• 3 byte header “CR1”
• Crash GUID
• Crash report filename
• Total bytes in crash report file (4 bytes)
• Total files included in crash report (1 byte)
• File name
• File content

all strings after the CR1 header begin with 04 01 00 00 The remainder of the file is just filename + file content for every file included.

Episode 3: Making my own crash report server

It’d be really sick if instead, whenever the game crashes, callstacks and crash dumps are automatically collected and sent out.

Unreal’s Crash Reporter

Unreal has some docs on Crash Reporting. There’s a crash reporter client available in the engine, but no server. Instead the docs recommend external services which cost money.

At a glance, all of these services look great, but we’re skint students. We have time, but we don’t have money. The server shouldn’t have to do much anyways. We just want whatever data comes out of the client’s http requests, this shouldn’t require a fancy UI platform thing with glorified marketing pages.

Since Unreal’s source is available, we can observe and tweak the crash reporter client as needed. We can also observe the http requests sent out from the client to see what we get out the box.

Setup the Crash Report Client

To configure the crash report client I added the following to my project’s Config/DefaultEngine.ini:

[CrashReportClient]
bAgreeToCrashUpload=false
bSendUnattendedBugReports=false
CompanyName="Triple 7 Studios"
DataRouterUrl="http://localhost:8080"
UserCommentSizeLimit=4000
bAllowToBeContacted=true
bSendLogFile=true

Then to package the crash report client with the game we have to add the following to Config/DefaultGame.ini:

[/Script/UnrealEd.ProjectPackagingSettings]
IncludeCrashReporter=True

Now let’s write a crash that we can easily reproduce. I bound the following code to the ‘C’ key:

int* p = nullptr;
*p = 42;

Mistakes were made

Do not use the project launcher to test this out! It doesn’t package the crash reporter binaries! Instead use the package project button hidden away here:

What happens out of the box?

Now instead of crashing with an ominous fatal error box, we get this:

I’ve got a source engine build here. The development engine build I’m planning to make available to the team (via my cool binary delta patcher, stay tuned) won’t have symbols, so it’ll be interesting to see how the callstack log changes.

I’ve spun up an http server which will echo all http requests. Let’s see what happens when we click “Send and close”:

Received request:
==================
POST /?AppID=CrashReporter&AppVersion=5.6.1-0%2BUE5&AppEnvironment=Release&UploadType=crashreports&UserID=fb1395264275145b52c8cca3e0fd2fcd%7C%7C6536aa78-2595-4e2a-b190-86ad21120ab8 HTTP/1.1
Host: localhost:8080
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: application/octet-stream
User-Agent: CrashReportClient/UE5-CL-0 (http-eventloop) Windows/10.0.26100.1.256.64bit
Content-Length: 80199

We’ve received one single request! I’ve omitted the data here since it’s binary. Looks like all the data is sent in a gzip format. So let’s see if we can extract it!

Nope! The data doesn’t have a gzip header. So I fed the first few bytes to chatgpt and it correctly identified it as a zlib header. So despite the Accept-Encoding saying gzip, it’s actually compressed using zlib!

What I get out of zlib appears to be a proprietary unreal format which stiches together all the files. From nosing around in neovim I’ve found the following embedded in this proprietary file:

• CrashContext.runtime-xml

  • Error message (in our case EXCEPTION_ACCESS_VIOLATION)
  • IsAssert, IsStall, IsEnsure
  • Callstacks of every thread
  • Hardware info
  • Engine version
  • Build Configuration

• CrashReportClient.ini

  • All the settings used for the crash report client

• GoodTiming.log

  • Since I had bSendLogFile set to true in the crash report client settings. We got the entire log!

• UEMinidump.dmp

  • A crash dump we can open in visual studio. Will have to try this out to see what we can get out of it!
  • Fingers crossed this’ll save us a load of headache!

Episode 2: Reverse Engineering the Crash Report File

The Toolchain

I followed devkitpro’s installation guide so I now have everything available through pacman. Installing the Wii stuff was super easy on Arch! I now have the PowerPC toolchain (including a gcc/g++ compiler), a bunch of wii examples, cmake files, and several tools!

CMake Wii Hello World

To get my feet a little wet I’ll grab the cmake example to see if I can get cmake working. Although Unreal uses it’s own custom build system, understanding how CMake is setup will probably help us understand what’s required when building Wii applications.

The example does not work out of the box with the ol’ reliable: cmake -S . -B build

CMake Error at CMakeLists.txt:17 (ogc_create_dol):
  Unknown CMake command "ogc_create_dol".

So let’s read the CMakeLists.txt:

cmake_minimum_required(VERSION 3.13)

project(application LANGUAGES C VERSION 1.0.0)

add_executable(${PROJECT_NAME})

target_sources(${PROJECT_NAME} PRIVATE
  source/main.c
)

target_compile_options(${PROJECT_NAME} PRIVATE -Wall)

target_include_directories(${PROJECT_NAME} PRIVATE
  include
)

ogc_create_dol(${PROJECT_NAME})

I have two questions:

1. How do we know to use the PowerPC compiler?
2. wtf is ogc_create_dol and where do I find it?

Question 1: How do we know to use the PowerPC compiler?

Let’s read up on cross compiling with CMake. Looks like we need to make a toolchain file which sets all the necessary variables such as which compiler to use, system name, etc. We can then specify this file by setting CMAKE_TOOLCHAIN_FILE. Chances are this toolchain file already exists in $DEVKITPRO/cmake:

Catnip/                 dkp-catnip-utils.cmake     dkp-initialize-path.cmake   ogc-common.cmake
catnip-main.cmake       dkp-custom-target.cmake    dkp-linker-utils.cmake      Platform/
devkitPPC.cmake         dkp-embedded-binary.cmake  dkp-rule-overrides.cmake    Wii.cmake
dkp-asset-folder.cmake  dkp-impl-helpers.cmake*    dkp-toolchain-common.cmake

$DEVKITPRO/cmake/devkitPPC.cmake

include(${CMAKE_CURRENT_LIST_DIR}/dkp-initialize-path.cmake)
include(dkp-toolchain-common)

set (DKP_BIN2S_ALIGNMENT 32)

__dkp_toolchain(devkitPPC ppc powerpc-eabi)

set(DKP_INSTALL_PREFIX_INIT ${DEVKITPRO}/portlibs/ppc)

This looks like it could be it!

$DEVKITPRO/cmake/Wii.cmake

cmake_minimum_required(VERSION 3.13)

if(NOT CMAKE_SYSTEM_NAME)
    set(CMAKE_SYSTEM_NAME NintendoWii)
endif()

include(${CMAKE_CURRENT_LIST_DIR}/ogc-common.cmake)

CMAKE_SYSTEM_NAME is also something set in a toolchain file…

$DEVKITPRO/cmake/ogc-common.cmake

cmake_minimum_required(VERSION 3.13)

if("${CMAKE_SYSTEM_NAME}" STREQUAL "NintendoWii")
    set(OGC_CONSOLE wii)
    set(OGC_SUBDIR wii)
    set(OGC_MACHINE rvl)
elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "NintendoGameCube")
    set(OGC_CONSOLE gamecube)
    set(OGC_SUBDIR cube)
    set(OGC_MACHINE ogc)
else()
    message(FATAL_ERROR "Unsupported libogc platform")
endif()

# Import devkitPPC toolchain
include(${CMAKE_CURRENT_LIST_DIR}/devkitPPC.cmake)

set(OGC_ROOT ${DEVKITPRO}/libogc)
set(DKP_INSTALL_PREFIX_INIT ${DEVKITPRO}/portlibs/${OGC_CONSOLE})

__dkp_platform_prefix(
    ${DEVKITPRO}/portlibs/${OGC_CONSOLE}
    ${DEVKITPRO}/portlibs/ppc
    ${OGC_ROOT}
)

find_program(PKG_CONFIG_EXECUTABLE NAMES powerpc-eabi-pkg-config HINTS "${DEVKITPRO}/portlibs/${OGC_CONSOLE}/bin")
if (NOT PKG_CONFIG_EXECUTABLE)
    message(FATAL_ERROR "Could not find powerpc-eabi-pkg-config: try installing ${OGC_CONSOLE}-pkg-config")
endif()

find_program(ELF2DOL_EXE NAMES elf2dol HINTS "${DEVKITPRO}/tools/bin")
find_program(GCDSPTOOL_EXE NAMES gcdsptool HINTS "${DEVKITPRO}/tools/bin")
find_program(GXTEXCONV_EXE NAMES gxtexconv HINTS "${DEVKITPRO}/tools/bin")

Ahhhhh of course. The Wii and the Gamecube are both PowerPC devices which devkitpro supports! So let’s see what happens when I set CMAKE_TOOLCHAIN_FILE to $DEVKITPRO/cmake/Wii.cmake

sam@rustbucket ~/s/application> cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=$DEVKITPRO/cmake/Wii.cmake
-- The C compiler identification is GNU 15.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done (0.1s)
-- Generating done (0.0s)
-- Build files have been written to: /home/sam/src/application/build
sam@rustbucket ~/s/application> cmake --build build
[ 50%] Building C object CMakeFiles/application.dir/source/main.o
[100%] Linking C executable application.elf
Converting application to .dol format
[100%] Built target application

That’s done it! We have a build!

Question 2: wtf is ogc_create_dol and where do I find it?

Well fortunately the second half of this question has already been answered. It’s included in the OGC cmake files which our Wii.cmake toolchain file includes for us.

But what does it do? The build seems to link to a .elf file and then right at the end that gets converted to a .dol file.

What are these filetypes?

ELF

From wiki.osdev.org:

ELF (Executable and Linkable Format) was designed by Unix System Laboratories while working with Sun Microsystems on SVR4 (UNIX System V Release 4.0). Consequently, ELF first appeared in Solaris 2.0 (aka SunOS 5.0), which is based on SVR4. The format is specified in the System V ABI.

A very versatile file format, it was later picked up by many other operating systems for use as both executable files and as shared library files. It does distinguish between TEXT, DATA and BSS.

Today, ELF is considered the standard format on Unix-alike systems. While it has some drawbacks (e.g., using up one of the scarce general purpose registers of the IA-32 when using position-independent code), it is well supported and documented.

From wiibrew.org:

This format is supported by many Wii homebrew loading techniques, particularly the Homebrew Channel, although most methods also support Nintendo’s .dol format, and some methods only support one or the other.

DOL

From wiibrew.org:

The Dol file format is the main executable file format for both the GameCube and the Wii. The name presumably refers to “Dolphin”, which was the GameCube’s codename. It is a simple file format consisting of a header and up to 7 loadable code sections (Text0..Text6) and up to 11 data sections (Data0..Data10). All values in the header are unsigned big-endian 32-bit values.

Additional Observations

The .ELF file is significantly larger than the .DOL file (1.6Mib vs 325KiB). So .DOL really is simple! Both seem to run fine on Dolphin

I have to write a dissertation for my final year of Computer Games Technology at Abertay University. I left my internship at Rare wanting more experience grappling with low level code. It’s common for AAA game server infrastructure to run several virtual machines which each will run a few instances of the game server. There’s a signaficant chunk of data that gets copied to memory each time a new server process is executed. Can we share non-trivial amounts of memory between seperate running processes on Windows and Linux? And if so, can we take advantage of this by integrating this tech into an Unreal Engine server?

Why Unreal Engine?

Designing my own game engine from the ground up around shared memory architecture would be too easy to spend an entire year on. Retrofitting this new tech into an existing established game engine is much more challenging, and could prove useful since Unreal Engine has loads of users and is the industry standard game engine.

Feasibility

This idea only works if we can share large non-trivial amounts of memory between processes, so let’s figure out if we can do that.

Windows

We could try creating a page file backed section object and see what happens. All virtual memory in Windows is backed by a file just in case we run out of physical memory. Unfortunately, this is a part of the Windows driver development kit, and I don’t want to make a driver, I just want a userspace program. Fortunately there’s another established API known as File Mapping. If we pass an INVALID_HANDLE_VALUE for hFile in CreateFileMapping, the mapping object will access memory backed by the system paging file. Here’s a quick and dirty example of this API in action. I have to run this in administrator mode in order to make use of the global namespace. There might be a way around that, but running servers in admin mode is not a deal breaker either.

#include <stdio.h>
#include <Windows.h>

#define BUFFER_SIZE 500

int main(int argc, char** argv)
{
  HANDLE hMappingObject = CreateFileMappingW(
    INVALID_HANDLE_VALUE,
    NULL,
    PAGE_READWRITE,
    0,
    BUFFER_SIZE,
    L"Global\\UnrealServerMappingMem");

  char* pBuf = (char*)MapViewOfFile(
    hMappingObject,
    FILE_MAP_ALL_ACCESS,
    0,
    0,
    BUFFER_SIZE);

  memcpy(pBuf, argv[1], strlen(argv[1]));

  printf("Copied %s to shared memory\n", argv[1]);
  printf("Press enter key to read and exit...");
  getchar();

  printf("Shared Memory Contents: %s\n", pBuf);

  UnmapViewOfFile(pBuf);
  CloseHandle(hMappingObject);

  return 0;
}

I made a reciprocal program that grabs the mapping object with OpenFileMappingW, reads the buffer, then after user input will write something new to it. This seems to work fine for 500 bytes. But what about 500 megabytes? Or 5 gigabytes? The answer is yes!

So we know it’s possible to share large blocks of memory between processes on Windows. What about Linux?

Linux

It’s very similar to how Windows goes about it. First create a shared memory object with shm_open, truncate it to the size of the buffer, then map it to virtual memory with mmap. God bless the man pages.

#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

#define BUFFER_SIZE 500
#define SHM_NAME "/UnrealServerMappingMem"

int main(int argc, char** argv)
{
    int shm_fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666);

    ftruncate(shm_fd, BUFFER_SIZE);

    char* pBuf = (char*)mmap(NULL, BUFFER_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0);

    memcpy(pBuf, argv[1], strlen(argv[1]));

    printf("Copied %s to shared memory\n", argv[1]);
    printf("Press enter key to read and exit...");
    getchar();

    printf("Shared Memory Contents: %s\n", pBuf);

    munmap(pBuf, BUFFER_SIZE);
    close(shm_fd);
    shm_unlink(SHM_NAME);

    return 0;
}

Trying buffer sizes of 500 megabytes and 5 gigabytes worked just the same as 500 bytes!

So it’s totally possible!

Both operating systems can provide what we need to share large amounts of memory between processes! The hard part is going to be bringing this architecture into Unreal Engine. That’s where the academic year of exploration would go. Can we get Unreal servers to operate in a shared memory architecture? What would the developer experience be like? How would a gamedev using my artefact articulate what should be shared and what should not?

I have to write a dissertation for my final year of Computer Games Technology at Abertay University. I left my internship at Rare wanting more experience grappling with low level code. I’ve also been working on a game in Unreal Engine 5 with my team at 777 studios. So how cool would it be to get our awesome game working on Wii hardware? And as an extra bonus, what if we could control the player’s sword with the Wiimote’s motion sensors? This is quite an ambitious undertaking, but I think it’d make a very interesting read whether it goes well or not. And if it does go very well, there’ll be a pretty awesome demo for the digital grad show!

Setting Expectations

My goal would be to bring gameplay from a UE5 project to Wii hardware. I don’t want to do a dissertation on graphics, so all I want is to chuck 3D stuff on the screen. Any extra graphics features like lighting, anti aliasing, VFX, etc. are stretch goals (after adding motion controls). Same with audio. Nothing crazy to begin with but we can go for some stretch goals later on. I’m not porting the visual fidelity of UE5 to the Wii, I just want to be able to take any existing UE5 project and see a beautifully scuffed looking version of it playable on the Wii with minimal engine modifications. I’m not bothered about additional engine modules and plugins, but if I have to heavily change the engine’s code in such a way that it could become difficult to take in engine upgrades, other people might be less inclined to mess with this project.

Where do I start?

A Hello world on the Wii

I’ve never done any programming for the Wii, so I’d like to get the toolchain setup and see some code running within Dolphin Emulator. I came across devkitPro which includes a toolchain for Wii/GC’s PowerPC architecture, and a series of examples including a hello triangle and audio! DevkitPro needs a posix style environment so it installed MSYS onto my Windows installation. In the future I’ll likely be developing on Arch because having this weird fake linux thing on the horrible experience that is Windows is gonna be frustrating. But all I had to do was fire up MSYS and run make on a few examples and load them into Dolphin! All worked out the box!

This is just the beginning

So it looks easy to iterate code on the Wii thanks to Dolphin. I can quickly compile and run which is real nice and it looks like Dolphin does come with some debugging capabilities too! I’m glad that we’re starting with a pleasant base though because what is to come will be challenging and hopefully an academic year’s worth of exploration!

There’s still plenty to sink my teeth into

• Compiling Unreal Engine 5.6 using devkitPro’s PowerPC g++ compiler

  • Maybe start with clang on x64 then slowly shift to GCC on x64 since clang and gcc should be compatible for linking. Then move onto PowerPC’s gcc.
  • Hopefully now that Unreal is on C++20 which has permissive- enabled on MSVC, there shouldn’t be too much weirdness unless devkitPro does very weird non conformant things
• Cooking uassets for the Wii
• Implementing the Wii’s platform classes

• A simple rendering backend for the Wii

  • There’s an SDL and SDL2 implementation for the Wii! Hopefully this is all we’ll need for a primitive renderer

This list is already easier said than done, but there’s also going to be unforseen issues. Especially since UE5 is targeting latest gen consoles and modern PCs. We might have to rework core engine technologies such as asset streaming. Hopefully these modifications are feasible enough and aren’t too intrusive in order to keep the codebase maintainable for all other platforms. And if the modifications are intrusive, can we justify choosing them on other platforms too?