Project overview
The goal is to preserve inFAMOUS 2's game logic and presentation while adapting its runtime, rendering, input and performance to iPhone hardware. The starting point is the original game's code and existing PS3 static-recompilation work, including the macOS recompilation project.
The game executes on the iPhone itself. It is not an emulator, a cloud-gaming service or a Remote Play client. A Mac is used for development and installation, but gameplay does not depend on streaming, remote rendering or a connected computer. Game data is stored and used locally on the phone.
The CPU code is statically recompiled for ARM64: translation happens before the native application runs, rather than through CPU JIT compilation during gameplay. Apple Metal handles rendering and selected compute workloads. Porting also requires adapting the surrounding platform services; compiling the CPU code alone does not provide an iOS runtime, graphics surface, input system or device lifecycle integration.
This page describes the prototype's verified progress and current limitations. The public project README is the source for its development status.
Current status
The project has progressed beyond an empty Metal view. The actual game boots and reaches controllable gameplay on a real iPhone 15 Pro. Menus, opening sequences, cinematics and the first playable scene render through Metal.
Audio output and physical controller input are working, including DualSense testing. This is an early prototype: reaching the first playable scene does not validate the full campaign, every controller action or long gameplay sessions. Touch controls are planned and are not implemented yet.
| Area | Current implementation |
|---|---|
| Application | Native iOS shell using UIKit, Objective-C++ and the existing C/C++ core. |
| Rendering | Metal rendering for menus, opening sequences, cinematics and the first playable scene. |
| Game data | Stored and accessed locally on the phone. |
| Audio and input | Audio output and physical controller input, including DualSense testing; broader control coverage remains unvalidated. |
| In-game settings | Selectable performance indicators, thermal and memory information, and CSV logging. |
| Runtime comparisons | Separate reference and experimental runtime paths for correctness checks and performance comparisons. |
Runtime and iOS integration
The existing macOS recompilation project provided the starting point. Work on iOS has included a dedicated iOS target, an on-screen Metal surface, iOS-specific dependencies and lifecycle handling. UIKit and Objective-C++ connect the application shell to the existing C/C++ core.
Controller and audio integration, together with a device-local game-data pipeline, make the application independent of the development computer during gameplay. The macOS target remains useful as a comparison platform when checking the iOS adaptation.
Memory mapping and host-thread stacks
Crash diagnosis also required adapting memory mapping and host-thread stack handling. These runtime changes helped the project move from boot experiments to real on-device gameplay. They are part of the platform adaptation, alongside the application target and rendering surface; they do not establish that every later game sequence is correct or stable.
Reference and experimental paths
The project keeps separate reference and experimental runtime paths. These make it possible to compare behavior and performance while testing changes. Correctness checks against original paths matter because a locally faster implementation is only useful if it preserves the expected output.
Metal lighting and SSAO
Lighting and screen-space ambient occlusion (SSAO) were identified as producers of results that the rendering path was waiting for. Their Metal paths have been integrated and tested on the phone.
SSAO is the screen-space occlusion pass used to estimate ambient shading around visible geometry. In this port, the question is not just how quickly a pass completes in isolation, but whether its results arrive soon enough to improve the frame that depends on them.
| Change | Comparison baseline | Observed result |
|---|---|---|
| Metal lighting | SPU lighting reference | About 25% higher FPS |
| Metal SSAO | SPU SSAO reference, with Metal lighting already enabled | About 27% higher FPS |
These are individual, short comparisons. The percentages are not additive and are not guarantees for the entire game. Broader visual-equivalence and stability testing is still needed.
Profiling and optimization experiments
The project records actual presentation timestamps, CPU samples, GPU command-buffer timings and synchronization events. Optimization decisions are checked against frame time as well as local function costs. This distinguishes a faster isolated operation from an improvement that reaches a displayed gameplay frame.
- Presentation timestamps
- Record when frames are actually presented, so measurements can be checked against visible frame delivery.
- CPU samples
- Help identify where CPU execution time is being spent.
- GPU command-buffer timings
- Record GPU execution timing for submitted work.
- Synchronization events
- Help trace waiting and dependencies between stages of the runtime and renderer.
Geometry, skinning and culling
ARM64 and Metal experiments have been developed for Edge geometry, skinning and culling, with output checks against the original paths. Skinning updates geometry for animation; culling identifies work that can be excluded from rendering. Some local work became faster, but a repeatable gameplay FPS improvement has not been demonstrated for these experiments.
Small GPU jobs can lose their benefit to submission and synchronization costs. Moving an operation to the GPU therefore does not automatically make the overall frame faster. Expensive candidates fall back to the CPU when those costs outweigh the benefit.
Current renderer optimization
The current focus is the serial renderer path. Work is targeting redundant RSX state processing, vertex preparation and copying, texture-change detection, and CPU/GPU scheduling.
- RSX state processing: reduce repeated legacy state work that does not need to be performed again.
- Vertex preparation and copying: reduce unnecessary preparation, data conversion and movement before rendering.
- Texture-change detection: examine the work involved in identifying texture changes.
- CPU/GPU scheduling: investigate submission order, waiting and synchronization costs across the frame.
A first change to reduce redundant legacy RSX state updates has been implemented, checked locally and installed on the phone. Its on-device performance comparison is pending. No gameplay speedup is claimed for that change before the comparison is completed.
Performance and current limitations
Recent stationary early-gameplay tests on iPhone 15 Pro were around 6 FPS under controlled thermal conditions. Lighter scenes can run faster, but gameplay performance remains well below a comfortable target.
Performance varies with the scene, device temperature and runtime settings. There is no sustained 30 FPS claim. The current device evidence also does not establish broad iPhone compatibility, and there is no public release date.
The performance HUD in the screenshot is a snapshot of a particular scene and thermal condition. It is not an A/B benchmark or a sustained-performance measurement; its instantaneous reading does not replace the controlled-test result above.
Validation boundaries
- The first controllable scene has been reached; the full campaign has not been validated.
- Physical controller input and DualSense have been tested, but not every controller action is confirmed.
- Long gameplay sessions and longer-term stability remain unvalidated.
- Touch controls are planned and are not implemented.
- Visual equivalence, save/load behavior and gameplay beyond the opening area need broader testing.
Next steps
Development log
Current development records from the public project README. Further verified milestones can be added as work progresses.
RSX state-processing change
Comparison pending
The first change to reduce redundant legacy RSX state updates is implemented, checked locally and installed on iPhone. Its on-device performance comparison is pending.
Metal lighting and SSAO
Integrated and tested
Both paths are integrated and tested on the phone. Separate short comparisons showed gains against the SPU references; broader visual-equivalence and stability testing remains necessary.
Standalone iOS application and first gameplay
Confirmed
The game boots and reaches the first controllable scene on iPhone 15 Pro, using local game data, audio output and physical controller input, including DualSense testing.
Repository and attribution
The implementation is closed source at this stage. GitHub is used as a public development showcase and progress tracker. No source code, game data, firmware or installable builds are published in the repository.
Milestones and development progress will be documented there. You can star the repository and follow updates; questions and feedback are welcome through GitHub Issues.
This iOS adaptation builds on existing PS3 static-recompilation and macOS porting work. Thanks to the developers and contributors whose foundational work made it possible.
inFAMOUS 2 is a Sucker Punch Productions / Sony Computer Entertainment title. This is an unofficial project, not affiliated with or endorsed by its creators. Game names, imagery and trademarks belong to their respective owners.