Fullscreen 60 FPS capacity
16.5987 ms p95
The 30-second 1920×1080 run stays inside the 16.6667 ms frame budget while the player travels 70.575 cells.
Novalirium Development Preview
Desuper is getting seriously fast.
Desuper is a 2D runtime built around smooth gameplay, scalable worlds and deterministic simulation. The latest measurements show how the engine behaves under mixed loads containing world geometry, AI, scripts, collision queries, physical projectiles and rendering work.
Complete-frame Heavy: 60 FPS percentile passedSDL3 / Direct3D 12 activePersistent GPU sessionMatched 150K p95: 16.0018 ms
A playable high-resolution route passes the strict 60 FPS pacing gate
Nightglass is a connected top-down qualification project built through the same Desuper project model used by the editor and exported runtime. Its measured route combines a cell-accurate city, directional actors, enemies, projectiles, combat effects, a mission, linked locations, staged loading and GPU presentation.
Strict pacing
1.66% late
Only 26 of 1,566 measured frames cross the target. This is below Desuper's strict 2% limit.
Efficient drawing
5.5305 ms p95
The rendering lane retains ample room inside the 60 FPS frame while the connected encounter remains active.
Stable GPU session
1 / 0
One renderer creation and zero device recoveries during the measured route.
What changed: production floor artwork now remains in independently streamable 1024px sources and is scaled to its 2048px destination by the persistent GPU. Nearby immutable sources are prepared during loading instead of appearing as first-use gameplay uploads. Exported atlas pages fell from 26 to 3, peak GPU texture residency fell from 150.238 to 87.062 MiB, and the worst measured frame fell from 110.848 to 48.193 ms.
| Same authored floor | Frame p95 | Late frames | GPU texture peak | Process peak | Maximum frame |
|---|---|---|---|---|---|
| 25-source production layout | 16.5987 ms | 1.66% | 87.062 MiB | 574.414 MiB | 48.193 ms |
| Single 5120px boundary | 16.6002 ms | 2.41% | 454.217 MiB | 2,059.172 MiB | 904.639 ms |
Why the comparison is fair: an automated pixel audit confirms that all 25 production chunks are exact RGBA crops of the single 5120×5120 master—zero differing pixels and zero channel delta. The boundary is intentionally retained to reveal the memory and first-use cost of one oversized source; it is not the recommended production layout. Wider NVIDIA, AMD and Intel qualification is still required before these results can become a universal hardware claim.
A large project should not make the Studio fight its creator
Real editor project
100,000 objects
A canonical 634×632-cell project is opened, panned, zoomed, searched, selected, edited, saved and reopened through the actual Level Design workspace.
Inspector save
96.2% faster
The identical route falls from 8.63 seconds to 0.331 seconds by updating only changed data instead of rebuilding the world.
Offscreen selection
89.3% faster
Selection falls from 2.82 seconds to 0.300 seconds while keeping the object fully editable.
Memory after open
33.3% lower
Working set falls from 556.2 to 371.0 MiB on the measured Windows reference system.
Why it improves: unchanged floors, backgrounds and decorations remain prepared in local quadrants; only visible regions receive detailed work. Dense distant regions use a compact overview, selected objects stay exact, and ordinary edits update a small dirty subset. The next graphics gate brings the same persistent-scene contract to the Jozyte/SDL3 GPU viewport while retaining a safe reference fallback.
Latest measured milestone
Latest Heavy frame p95
16.5315 ms
Measured through the complete SDL3/Direct3D 12 gameplay frame at 1920×1080.
Heavy frames over budget
3 / 673
Only 0.45% crossed the exact 16.6667 ms frame budget in the latest run.
Latest 150K frame p95
16.0018 ms
The extreme matched route now passes the 60 FPS percentile capacity gate.
90-second memory growth
0.82 MiB
Bounded growth during the retained mixed-runtime memory window.
What “Heavy” means: 44,233 runtime objects per level, 64 active AI agents across eight encounter districts, 128 concurrent scripts, collision and visibility queries, combat activity, real player movement and a populated City → Desert route.
Honest latest check: the earlier visible spike was traced to an unnecessary static-world chunk rebuild—not repeated NVIDIA initialization. The final matched run created one renderer, recovered it zero times and rebuilt zero static chunk pages during gameplay. Its 16.0018 ms p95 is green; strict pacing remains just outside the ≤2% target at 2.58% late frames.
Runtime engineering foundations
01
Spatial broad phase
Grid-based candidate queries keep movement, collision, visibility and projectile tests away from full-world scans while exact collision remains authoritative.
02
Bounded AI scheduling
Perception and decisions use deterministic think budgets while movement and critical combat state remain responsive every frame.
03
Viewport culling and visual chunks
Only relevant candidates enter the draw route. Safe static layers are reused as bounded world chunks while dynamic artwork retains exact ordered rendering.
04
Prepared level data
Versioned precomputed data and reusable indexes move expensive setup into controlled loading phases instead of active gameplay frames.
05
Obstacle-interval route testing
Long AI routes retain exact collision checks but skip empty pixel ranges, keeping enemies practical across complete worlds instead of one small arena.
What the engine actually handled
Mixed runtime workload
The latest Heavy run contains 44,233 objects per level, 64 active AI agents, 128 concurrent scripts and eight encounter districts spread across the world.
Frame distribution
16.7179 ms mean, 16.5458 ms p95 and 16.5488 ms p99. One separately reported 366.8879 ms frame contains the cold level transition and remains an open loading/lifecycle target.
Subsystem p95
Update: 3.6545 ms
Rendering: 10.7923 ms
AI: 2.2988 ms
Combat and projectiles: 1.4694 ms
Runtime techniques
High-precision pacing, spatial broad phases, deterministic AI budgets, viewport culling, bounded visual chunks, pooled projectiles and indexed script-event dispatch.
150K engineering tier: the final 20-second complete-frame test uses true 1920×1080 fullscreen, 150,024 objects, 256 active AI agents, 1,024 dormant agents, 512 scripts and 61.131 cells of real movement. It reaches 16.0018 ms frame p95, 19.0190 ms p99 and a 21.5998 ms maximum. The p95 capacity gate passes; the stricter late-frame target remains open.
Measured capacity matrix
| Test tier | Measured workload | Frame evidence | Meaning |
|---|---|---|---|
| Complete-frame SDL3 Heavy | 1920×1080 · 44,233 objects · 64 active AI · 128 scripts · 206 projectiles p95 | 16.5315 ms frame p95 · 16.5348 ms p99 · 10.4878 ms draw · 1.8288 ms AI | Gameplay pass |
| Matched complete-frame SDL3 150K | 1920×1080 · 150,024 objects · 256 active + 1,024 dormant AI · 512 scripts · 61.131 cells travelled | 16.0018 ms frame p95 · 19.0190 ms p99 · 21.5998 ms max · 2.58% late | P95 capacity pass |
| Cold world transition | Populated City → Desert level switch | 352.6939 ms · explicitly retained lifecycle outlier | Open loading gate |
| 150K headless | 150,000 objects · 256 active AI · 1,024 dormant AI · 512 scripts · 956 projectiles max | 20.2159 ms frame p95 · 13.0607 ms update · 7.2875 ms draw | Capacity diagnostic |
| 150K fullscreen distributed | 1920×1080 · 150,024 objects · 8 districts · real player/camera movement | 32.8852 ms frame p95 · 23.2996 ms draw · 7.8200 ms AI | Fullscreen diagnostic |
| 10K world breaker | 311,257 objects · 1,000 active AI · 10,000 dormant AI · 5,000 scripts · 10,000 × 10,000 cells | 88.0248 ms frame p95 · world remained operational | Survivability ceiling |
The tiers have different acceptance purposes. A diagnostic or breaker result is never relabeled as a playable 60 FPS result.
Why the Heavy test resembles a real demanding game
Two actual worlds
The player moves through a populated 320×320 city and desert. Each level contains 44,233 stored objects and uses a different visual theme instead of repeating one empty laboratory scene.
Encounters across the map
Eight enemy groups are placed along the route and in surrounding districts. Patrol and pursuing enemies are therefore encountered throughout the world—not only at one hand-picked benchmark location.
Real movement
The runtime player travels 118.714 measured cells around a 96-cell planned route while the fullscreen camera crosses world-chunk boundaries.
Concurrent game systems
AI, pathfinding, collision, visibility, 128 scripts, 16 spawners, hazards, combat zones and hundreds of physical projectiles run together.
Visible scene density
About 1,092 candidates are visible at p95. Safe static art is represented by 48 reusable chunk draws at p95, while enemies, projectiles and effects remain dynamic.
Honest loading evidence
Continuous Heavy gameplay is smooth, but the cold City → Desert switch still takes 352.6939 ms. It is reported openly as the next loading/lifecycle target.
About the 150K tier: real games normally stream, divide and deactivate distant content. The 150K test intentionally pushes 150,024 objects into one active world to expose scaling limits. It is useful engineering evidence, not a recommended level layout and not a claim that every object should appear on one screen.
The latest measured AI improvement
AI p95
98.36 → 2.30 ms
A 97.7% reduction on the same distributed Heavy world.
Update p95
100.05 → 3.65 ms
A 96.3% reduction while keeping exact collision and distributed enemies.
Frame p95
112.57 → 16.55 ms
An 85.3% reduction without reducing object, AI or script counts.
How it works
Long AI routes still use pixel-precise obstacle testing, but exact mask checks occur only inside intervals that can actually contain a blocker. Empty world space no longer consumes thousands of pixel checks per route.
Distributed Heavy: full data sheet
| Lane | Mean | p95 | p99 / maximum | Interpretation |
|---|---|---|---|---|
| Complete frame | 16.7179 ms | 16.5458 ms | 16.5488 / 366.8879 ms | The maximum contains the separately measured cold level switch. |
| Gameplay update | 2.7638 ms | 3.6545 ms | 4.4401 / 9.9438 ms | Simulation remains well below its 10 ms p95 contract. |
| Drawing | 6.0705 ms | 10.7923 ms | 11.6907 / 22.4493 ms | Largest normal Heavy lane; still below the 12.5 ms p95 draw gate. |
| Enemy AI | 1.4796 ms | 2.2988 ms | 3.1061 / 9.2336 ms | Includes perception, patrol/pursuit, route tests, bounded A* and motion. |
| Combat/projectiles | 1.1180 ms | 1.4694 ms | 1.5479 / 1.7251 ms | Physical projectile and effect processing remains bounded. |
| DesuperCode | 0.0905 ms | 0.1348 ms | 0.1535 / 0.1669 ms | 128 concurrent script runtimes and timers. |
| Presentation | 0.6743 ms | 0.7726 ms | 0.8253 / 0.9083 ms | Display submission remains stable. |
| Frame wait | 7.0033 ms | 8.4056 ms | 8.8012 / 9.6392 ms | Positive wait time shows remaining headroom in most Heavy frames. |
| Workload counter | Mean | p95 | Maximum |
|---|---|---|---|
| Visible candidates | 1,061.278 | 1,092 | 1,093 |
| Static visual chunk draws | 42.158 | 48 | 48 |
| Static sources represented by chunks | 1,087.240 | 1,233 | 1,241 |
| Physical projectiles | 197.770 | 272 | 278 |
| Weapon effects | 66.203 | 78 | 89 |
| AI think updates per frame | 8.029 | 12 | 22 |
| AI direct-route checks per frame | 3.876 | 9 | 14 |
| A* nodes expanded per frame | 48.499 | 345 | 1,013 |
150K breaker: full data sheet
| Lane | Mean | p95 | p99 / maximum | What it reveals |
|---|---|---|---|---|
| Complete frame | 27.8262 ms | 32.8852 ms | 35.6172 / 359.3175 ms | About 36 FPS by mean frame time; not a 60 FPS pass. |
| Gameplay update | 8.8207 ms | 10.3603 ms | 11.5273 / 14.1626 ms | Much lower than the earlier 67.1127 ms p95, but just above the strict update budget. |
| Drawing | 18.3513 ms | 23.2996 ms | 25.3536 / 349.0150 ms | The largest current 150K lane and the next render-backend target. |
| Enemy AI | 6.1956 ms | 7.8200 ms | 8.7113 / 12.6383 ms | 256 active agents distributed across eight districts. |
| Combat/projectiles | 2.1707 ms | 2.8490 ms | 3.0681 / 3.5835 ms | Hundreds of physical projectiles remain active. |
| DesuperCode | 0.3730 ms | 0.4717 ms | 0.5542 / 0.7514 ms | 512 script runtimes and timers. |
Visible work
2,319 candidates p95, 48 chunk draws p95 and 2,438 static chunk sources p95.
AI work
73 think updates, 44 direct routes and 751 expanded A* nodes at p95; 1,698 nodes maximum.
Combat load
413 physical projectiles p95 and 426 maximum, plus 156 weapon effects p95.
Startup
5,560.2921 ms total: 275.5559 ms prepared decode, 18.2389 ms navigation cells and 1,464.2102 ms first-level index construction.
How to interpret these figures
p95
Ninety-five percent of recorded samples complete at or below this duration. It reflects sustained smoothness better than one peak FPS number.
p99
Ninety-nine percent complete at or below this duration. It makes less frequent hitches visible.
Maximum
The single slowest sample is retained. A loading transition can create a high maximum even when normal gameplay p95 is stable.
Why mean can exceed p95
A very small number of extremely slow lifecycle frames can pull the arithmetic mean upward while leaving the 95th percentile near the normal gameplay cluster.
Subsystem percentiles
AI, drawing and combat p95 values must not be added together: their slowest five-percent windows may occur on different frames.
Hardware boundary
These figures describe one unclassified Windows system. They are development evidence, not final minimum or recommended specifications.
Why the extreme tests are valid engineering
Different tests answer different questions
Heavy asks whether a demanding, realistically structured 2D world can remain smooth. The 150K tier asks where scaling pressure appears. The 10K-world breaker asks whether the architecture remains bounded and operational far beyond a normal scene.
A stress test is not a design recommendation
Placing 150,000 objects in one active world is intentionally excessive. That does not invalidate the result; it isolates limits in rendering, AI scheduling, indexing and loading before a real project reaches them unexpectedly.
Matched tests prove real improvements
An optimization is compared against the same workload, movement route, resolution and system counts. Object counts cannot simply be removed to manufacture a faster result. Exact collision and safe rendering fallbacks must continue to pass.
Headroom protects ordinary games
If an engine remains stable well above a normal project's expected load, creators gain room for effects, AI spikes, busier encounters and lower-spec computers. The extreme tier is used to build that safety margin.
Failures are useful evidence
A non-pass identifies the next engineering target. The latest 150K result shows that drawing is now more expensive than AI, while the City → Desert test shows that cold index preparation—not continuous gameplay—is the transition bottleneck.
No universal engine ranking
These figures cannot fairly rank Desuper against another engine unless both use equivalent content, code, hardware, resolution and measurement rules. They describe Desuper's own verified development state.
| Evidence tier | Question it answers | What users should expect | What it does not claim |
|---|---|---|---|
| Distributed Heavy | Can a demanding authored top-down world sustain smooth fullscreen play? | Strong current evidence for large 2D levels with distributed enemies, scripts, combat and dense scenery on the measured PC. | Not a minimum-spec guarantee for every computer or every possible game combination. |
| 150K breaker | Which subsystem becomes the next bottleneck when one world is intentionally overloaded? | Stable operation at an extreme scale; current optimization priority is CPU-side drawing. | Not a recommended object count, level layout or 60 FPS promise. |
| 10K-world breaker | Do sparse indexing and bounded scheduling survive a huge addressable world? | Architectural survivability evidence and data for future streaming work. | Not playable-performance evidence at that complete active load. |
| Lifecycle tests | Do loading, transitions and window/device events remain controlled? | Transparent reporting of cold-transition and recovery costs. | A good gameplay p95 does not automatically mean every lifecycle gate has passed. |
Current expectation: on the measured Windows system, Desuper's runtime has strong evidence for smooth, demanding 2D top-down gameplay at the Heavy tier. Creators should still use sensible world partitioning, activation ranges and streaming. Final public minimum and recommended specifications require packaged-game tests on declared low-, reference- and high-tier computers.
How the measurements are checked
Tail latency, not marketing FPS
Reports retain mean, p95, p99, maximum frame time and exact deadline misses. This exposes isolated stalls that a single average-FPS number would conceal.
Subsystem timing
Event handling, update, drawing, presentation, AI, scripts, combat and frame waiting are measured separately so optimization targets come from evidence.
Deterministic comparisons
Before/after runs preserve workload sizes and gameplay semantics. Exact collision and ordered-render fallbacks remain authoritative when an optimized path is unsafe.
Regression coverage
The latest focused and combined routes pass 28/28 and 47/47, covering runtime behavior, visual-chunk correctness, profiler evidence, showcase launching and game export behavior.
Honest hardware boundary
Current capacity figures come from one unclassified Windows system. Tests on low-, reference- and high-tier hardware remain required before minimum specifications can be published.
Lifecycle evidence
Slow event batches now retain their responsible event names. The latest visible run recorded no event outlier, but resize, alt-tab, transitions and packaged builds still require a full matrix.
Optimization progression at 150K scale
| Measured lane | Initial retained direct route | Current optimized route | Reduction |
|---|---|---|---|
| Frame p95 | 67.6674 ms | 20.2159 ms | 70.1% |
| Mean frame | 42.9334 ms | 17.2466 ms | 59.8% |
| Update p95 | 52.8881 ms | 13.0607 ms | 75.3% |
| AI p95 | 27.2861 ms | 4.8405 ms | 82.3% |
| Combat/projectiles p95 | 28.7261 ms | 8.6850 ms | 69.8% |
| Draw p95 | 15.4349 ms | 7.2875 ms | 52.8% |
Why this historical comparison matters: these retained measurements show how successive repairs reduced the same 150K workload before the latest 16.0018 ms run. The gains came from reducing full-world scans, budgeting AI work, pooling temporary state, filtering invisible dynamic work and reusing safe static chunks. The older entries remain diagnostic evidence and are not the current headline result.
Reading the numbers correctly
Frame budget
At 60 FPS, the complete event, simulation, rendering and presentation path has approximately 16.6667 ms. At 120 FPS this falls to 8.3333 ms.
p95
The 95th-percentile frame is slower than 95% of measured frames. It is a more useful smoothness indicator than an average alone.
p99 and maximum
These expose rare tail stalls. A strong p95 can coexist with a visible isolated hitch, which is why Desuper retains all three values.
Deadline misses
The Heavy gate counts frames crossing the exact target budget. The latest run missed only 1 of 901 deadlines.
Pacing, loading and stability evidence
| Evidence window | Measured result | Interpretation |
|---|---|---|
| Static 60 FPS pacing | 7 exact misses across 1,802 frames | Precise fractional pacing verified |
| Static 120 FPS pacing | 13 exact misses across 3,602 frames | 8.3333 ms target pacing verified |
| Heavy startup | 1,441.2363 ms total · 25.0806 ms visible-chunk prewarm | Preparation remains outside active gameplay |
| Visible 150K startup | 4,744.3079 ms total · 28.5566 ms visible-chunk prewarm | Extreme workload loading evidence |
| Visible event handling | 0.0131 ms p95 · 0.4892 ms maximum · no ≥25 ms outlier | Clean repeat; lifecycle matrix still open |
| Mixed-runtime memory | 0.82 MiB retained growth over 90 seconds | Bounded evidence window; extended soak still required |
Loading duration and gameplay frame time are deliberately reported separately. A larger world may take longer to prepare without causing the same delay during every active frame.
What these results do—and do not—prove
Proven today
The engine can sustain the accepted Heavy synthetic workload at its 60 FPS gate, preserve exact fallbacks and survive substantially larger diagnostic worlds.
Not a universal guarantee
One computer cannot establish minimum specifications. GPU, driver, operating-system and background-load differences require a declared hardware matrix.
Diagnostics are not game targets
The 150K and 10K-world tiers intentionally exceed ordinary scenes. They identify scaling limits and optimization priorities rather than recommending those loads for every game.
No hidden downgrade
Optimized routes retain exact collision checks, stable draw order and safe fallbacks. A faster result is rejected if behavior or rendered pixels change incorrectly.
What changed technically
Bounded static chunks
Explicitly immutable world artwork is composed into reusable 256-pixel regions. The cache is bounded and old regions are evicted automatically.
Loading-owned preparation
The opening viewport is prepared during the loading phase instead of waiting for the first gameplay draw. Slow event batches now retain bounded diagnostic evidence rather than becoming unexplained frame spikes.
Correct z-order
Only complete safe layers can use chunks. Animated, moving, scaled, rotated or mixed layers continue through the exact ordered fallback.
State invalidation
Visibility and animation changes invalidate the appropriate cached generation. Loading a save clears retained visual chunks.
Measured result
Headless 150K draw p95 fell 45.3%; visible draw p95 fell 31.6%. Pixel-parity and 45 combined runtime/export/profiler checks pass.
Large-world breaker test
World scale
10,000 × 10,000
One hundred million addressable cells in a sparse, indexed world.
Runtime objects
311,257
250,000 distributed world objects, 50,000 dense objects, AI, spawners and the player state.
Live systems
16,000+
1,000 active AI, 10,000 dormant AI and 5,000 concurrent scripts, plus projectile and collision work.
Breaker frame p95
88.0248 ms
A diagnostic survivability ceiling—not a playable performance target or minimum-spec claim.
Measured optimization: viewport candidate p95 dropped from 12,338 to 2,338 after active render-grid filtering. AI decisions are capped at 256 scheduled updates per 60 FPS frame while movement remains live. The remaining large-world cost is concentrated in mass movement/collision, thousands of physical projectiles and CPU-side rendering.
Native-resolution moving-world result
Heavy 1080p gameplay
16.5320 ms
Frame p95 while the real player traverses two populated worlds with 44,233 objects per level, 64 active AI agents across eight districts and 128 scripts.
AI p95
2.2173 ms
Exact route checks focus on actual obstacle intervals; the latest Heavy non-regression remains inside its 60 FPS p95 gate without clustering enemies.
150K boundary
32.8852 ms
A deliberately extreme fullscreen engineering test. It is a scaling diagnostic, not an example of how a normal game developer should fill one visible scene.
Honest test rule
Heavy is the closer representation of a demanding real game. The 150K tier intentionally exceeds ordinary scene composition to reveal the next engine bottleneck.
Survivor-style horde test
Real wave pressure
1,000 enemies
One hundred enemies start active and 900 more arrive in six timed waves while the player moves through a populated 1024×1024-cell world.
Concurrent gameplay load
1,842 projectiles
The p95 workload also includes 568 visible candidates, 256 scripts, collisions, effects and 14,089 runtime objects at 1920×1080 fullscreen.
Wave activation
< 0.20 ms
Enemies are prepared in bounded pools, so a new wave does not decode assets or rebuild the complete world during active gameplay.
Current measured boundary
25.2299 ms p95
The extreme 1,000-enemy pressure point remains above the strict 16.6667 ms gate, but the measured optimization path raises mean throughput from 38.7 to approximately 48.9 FPS.
| 1080p horde metric | Initial route | Current route | Improvement |
|---|---|---|---|
| Frame p95 | 35.2225 ms | 25.2299 ms | 28.4% |
| Update p95 | 26.3716 ms | 18.5926 ms | 29.5% |
| AI p95 | 21.1580 ms | 13.5893 ms | 35.8% |
| Projectile p95 A/B | 5.9697 ms | 5.0301 ms | 15.7% |
Measured native pilots: compatible horde motion and physical-projectile motion/static collision now cross separate versioned native batches through persistent compact data. Deterministic parity and Python fallbacks remain mandatory. Heavy still passes at 16.5260 ms p95; the first SDL3 atlas proof also passes, and complete-frame activation now depends on migrating every remaining drawing route.
First hardware-renderer proof
Desuper now presents the complete gameplay frame through a persistent SDL3 3.4.16 / Direct3D 12 session on the reference Windows PC. The original atlas proof remains useful historical evidence; the latest Heavy and 150K results measure the complete frame.
Verified graphics path
Direct3D 12
SDL3 3.4.16 created a real GPU renderer on the reference Windows PC and presented through the existing game window.
Extreme atlas submission
150,000 sprites
Sixteen authored images were exported into one atlas page and submitted in their original alternating order.
GPU p95
7.0793 ms
The isolated 30-frame renderer lane used ten bounded draw calls and one resident texture upload.
Preparation improvement
11.75%
Native Runtime Core geometry reduced one-time batch preparation from 347.5170 to 306.6787 ms.
| Exported-atlas renderer lane | Software fallback | SDL3 GPU | Status |
|---|---|---|---|
| Mean | 467.3299 ms | 6.4755 ms | Measured |
| p95 | 475.3559 ms | 7.0793 ms | 98.51% lower in this isolated breaker |
| Submission count | 150,000 surface blits | 10 bounded draw calls | Stable atlas reuse |
| Correctness | Authoritative fallback | Pixel/order/alpha parity | Automated |
Important context: the isolated 150,000-sprite atlas test remains a renderer stress test, not complete-game FPS. The complete gameplay path now covers sprites, text, primitives, clipping and render targets, while the exact software command renderer remains available as fallback. GPU initialization and first-use preparation occur once during loading rather than repeatedly during play.
Direct3D 12 is verified on one unclassified Windows PC. Vulkan, multiple declared hardware tiers, native GPU timing markers and extended packaged lifecycle/soak evidence remain qualification gates.
The latest measured engine leap
Measured causes removed
After removing a whole-world identity reconstruction, lifecycle telemetry exposed a second issue: dynamic visibility changes invalidated unrelated static chunks. Both causes are now removed.
Jozyte foundation
Desuper's emerging rendering coordination layer keeps reusable world work resident, submits only relevant changes and avoids duplicated presentation. Its deeper architecture remains private while qualification continues.
60 FPS p95 gate passed
The identical 150K route now reaches 16.0018 ms frame p95. Maximum frame time fell from 69.3721 to 21.5998 ms, with workload and visual quality retained.
Large worlds now have bounded simulation regions
10,000×10,000 cells
100 million cells
The tested sparse world keeps creator-authored ownership without treating empty space as active gameplay work.
Authored AI population
2,560 enemies
The project contains 512 active and 2,048 dormant enemies. Sixty-four enemies in the current combat district remain resident and simulated.
Measured frame p95
15.3282 ms
The fullscreen hybrid route stays inside the 60 FPS p95 budget and records only 8 late frames out of 720.
Update p95
3.9963 ms
Full, reduced-rate and preload neighbourhoods keep distant world activity from consuming the local encounter budget.
What this proves: Desuper can preserve a very large authored world while concentrating simulation on the player's surroundings. It does not pretend that 512 enemies in one room are equivalent to 64 local enemies. Occlusion, HLOD, asynchronous asset streaming and wider hardware qualification remain active engineering work.
Less CPU work for the same 150K world
Combined update + draw
26.17% lower
The same 150,024-object engineering route now spends 10.0485 ms at the combined p95 boundary instead of 13.6102 ms.
Enemy AI
42.45% lower
AI/pathfinding p95 falls from 6.9094 to 3.9764 ms without removing any of the 256 active or 1,024 dormant enemies.
Stable frame budget
1 / 480 late
The accepted engineering run retains the complete object, script and projectile workload. A moving fullscreen confirmation is the next gate.
Why it matters: the improvement removes bookkeeping that produced no visible gameplay. It does not lower image quality, enemy count, script count or world size. The larger 311K pressure world now reaches gameplay instead of stalling during state activation, but at 44.7482 ms p95 it still needs further work and is not advertised as a playable target.
Green at 150K. Now pushing the 350K frontier.
The newest fullscreen route moves a real player through the world while AI, scripts, projectiles, effects, collisions and the complete render path remain active. The graph uses a 40 ms scale; the white markers show the full 120 FPS and 60 FPS frame budgets.
Moving 150K world
15.9689 ms
150,024 objects, 256 active AI, 1,024 dormant AI, 512 scripts, 422 projectiles p95 and 79.963 cells travelled.
350K before
37.5967 ms
The exact 350,032-object survivor boundary before the latest resident-selection repair.
350K after
29.9470 ms
20.35% lower frame p95 with no object, enemy or projectile reduction. It remains above the 60 FPS target.
350K AI improvement
37.81% lower
AI p95 falls from 15.6813 to 9.7527 ms; update p95 falls 29.15%.
120 FPS: 8.33 ms60 FPS: 16.67 ms
Moving 150K
15.97 ms
350K initial
37.60 ms
350K optimized
29.95 ms
Why the 350K result matters: this is a deliberately excessive engineering boundary, not a recommended scene layout. It shows that the engine remains measurable and improvable under 350,032 live world records, approximately 2,543 visible candidates p95 and 1,489 projectiles p95. The next work targets state synchronization, projectile processing and render preparation directly.
High-resolution artwork gets its own honest test
Real source sizes
2K + 4K
Two 4096×4096 and ten 2048×2048 original RGBA sources across two distinct worlds.
Decoded artwork
288 MiB
Visible background, albedo, decal and sheet content plus preloaded normal, emissive and mask data.
Matched draw cost
+0.8731 ms
Draw p95 rises from 35.0740 to 35.9471 ms. Frame p95 remains within run-to-run variation.
Memory impact
+222 MiB
Peak process working set increases from 1,171 to 1,394 MiB, confirming why explicit texture budgets matter.
Technical honesty: both matched 44,236-object routes are currently red because they share the same distributed-AI and render-preparation bottlenecks. The high-resolution files are not the dominant cause. Supplemental maps are decoded and preloaded, but Desuper does not yet claim shader-backed normal, emissive or mask material passes. Resolution-aware streaming, mip/LOD selection and bounded GPU residency are active development gates.
The latest refinement: less copying, bounded texture memory
Moving 150K remains green
15.9478 ms p95
The final fullscreen route retains 150,024 objects, 900 activated horde enemies, hundreds of projectiles and real player travel.
350K keeps improving
28.8728 ms p95
Down from 29.9470 ms after stationary actors stopped paying synchronization and partition bookkeeping costs. This frontier remains above the 60 FPS target.
Texture memory has a hard budget
128–1024 MiB
Runtime memory tiers now bound Desuper's decoded GPU texture residency. Current, peak and limit values are measured instead of guessed.
Real 2K/4K evidence
≈132.4 MB resident
The high-resolution route stays below its 512 MiB reference-tier GPU texture limit.
Why this matters: smoother games need predictable frame work and predictable memory use. Desuper avoids copying stationary horde state, skips unnecessary region updates, safely evicts GPU textures when a tier budget is reached and now keeps large production floor sources out of duplicate atlas ownership. Exact software fallback behaviour is retained. The next graphics work targets bordered UI masks, material passes, projected-size mip/LOD selection and wider hardware qualification.
Still under active development
These are controlled development measurements from one unclassified Windows computer. Heavy is the closest current approximation of a demanding real game world. The 150K and large-world breaker tiers deliberately exceed ordinary scene composition; they reveal scaling limits rather than recommending that developers place every world object in one viewport.
Distributed-world AI, texture-atlas metadata, loading-owned indexes, pooled survivor waves, persistent native batches, byte-bounded texture residency and complete-frame SDL3 presentation are implemented. Stable enemy state and region-aware selection remove measured CPU hot paths. The moving 150K route is green at the 60 FPS p95 boundary, and the connected Nightglass production route now also passes the strict pacing gate. The 350K frontier remains diagnostic. Production mip/LOD streaming, material shading, HLOD, occlusion and wider hardware qualification remain active engineering gates.