How N2I Works
A technical overview of Nothing2Install's graphics command streaming technology and how it differs from video-based cloud gaming.
The Problem with Video-Based Streaming
Most cloud gaming platforms — GeForce NOW, Xbox Cloud Gaming, and similar services — work by running the game on a powerful server and encoding the screen output as a video stream, which is then sent to the player's device. The player's GPU is idle; it only decodes and displays the incoming video.
This approach has significant drawbacks:
- GPU costs in the cloud — every concurrent player requires a dedicated GPU server, which is expensive to operate and hard to scale.
- Video compression artifacts — the game image is encoded as video (H.264/H.265), introducing blur, blocking, and color degradation, especially in scenes with fast motion or fine text.
- Latency — encoding, transmitting, and decoding a video frame adds tens of milliseconds on top of network latency.
- High bandwidth — streaming video at playable quality requires a continuous 10–30 Mbps connection.
The N2I Approach: Graphics Command Streaming
N2I does not stream video. Instead, it captures the graphics commands that the Android app sends to the GPU — draw calls, shader instructions, texture uploads — and transmits those commands to the player's device. The player's own GPU executes the commands and renders the final image locally.
Traditional video streaming:
Cloud GPU renders frame → encode to video → transmit → decode → display
N2I graphics command streaming:
Cloud CPU runs app logic → capture GPU commands → transmit → player GPU renders → display
This changes the economics and quality of streaming fundamentally:
| Video streaming | N2I graphics command streaming | |
|---|---|---|
| Cloud GPU required | Yes — one per concurrent player | No — CPU only |
| Image quality | Compressed video, artifacts | Native GPU rendering, lossless |
| Bandwidth | 10–30 Mbps continuous | Much lower, highly compressible |
| Render latency | Encode + decode overhead | Render happens locally, no overhead |
| Scalability cost | GPU instances | CPU instances |
Session Lifecycle
Here is what happens when a player launches a game through N2I:
- Routing — The player's request is directed by GeoIP to the nearest N2I server (available in the US, Europe, Asia, and the Middle East).
- Session allocation — N2I starts an Android container running your APK and allocates a session for the player, including their saved user data.
- Streaming — The app runs in the cloud. Graphics commands are captured and transmitted to the player's browser in real time. The player's GPU renders every frame locally.
- Input — Touch, keyboard, and gamepad inputs from the player are sent back to the cloud over the same connection.
- Session end — When the player exits or the session times out, their state is saved and the cloud container is released.
From the player's perspective, the experience is indistinguishable from running the app natively — because the rendering actually is native, on their own hardware.
Infrastructure
N2I manages all server infrastructure. Your APK runs inside a managed Android environment in the cloud. You do not provision, scale, or maintain any servers.
Multi-region deployments are handled automatically. GeoIP routing selects the lowest-latency server for each player without any configuration on your side.
What You Need to Provide
- Your Android APK — N2I runs your existing APK. No special SDK, no separate build target.
- A client integration — An iframe or WebView in your website or native app that loads the N2I session URL (see Frontend Integration).
Minor APK modifications may be needed to support alternative payment providers or to enable specific communication features. N2I provides plugins and documentation for these cases.