Rendering Loop - Sixth 3D

The render thread runs continuously in a dedicated daemon thread:

while (renderThreadRunning) {
    ensureThatViewIsUpToDate();  // Render one frame
    maintainTargetFps();         // Sleep if needed
}

The thread is a daemon, so it automatically stops when the JVM exits. You can stop it explicitly with ViewPanel.stop().

The engine supports two modes:

• Target FPS mode: Set with setFrameRate(int). The thread sleeps between frames to maintain the target rate. If rendering takes longer than the frame interval, the engine catches up naturally without sleeping.
• Unlimited mode: Set setFrameRate(0) or negative. No sleeping — renders as fast as possible. Useful for benchmarking.

Before each frame, the engine notifies all registered FrameListeners:

viewPanel.addFrameListener((panel, deltaMs) -> {
    // Update animations, physics, game logic
    shape.rotate(0.01);
    return true;  // true = force repaint
});

Frame listeners can trigger repaints by returning true. Built-in listeners include:

• Camera — handles keyboard/mouse navigation
• InputManager — processes input events

The pixel buffer is filled with the background color (default: black).

Arrays.fill(pixels, 0, width * height, backgroundColorRgb);

This is a simple Arrays.fill operation — very fast, single-threaded.

All shapes are transformed from world space to screen space:

1. Build camera-relative transform (inverse of camera position/rotation)
2. For each shape:
   • Apply camera transform
   • Project 3D → 2D (perspective projection)
   • Calculate onScreenZ for depth sorting
   • Queue for rendering

This is single-threaded but very fast — just math, no pixel operations.

Shapes are sorted by onScreenZ (depth) in descending order:

Collections.sort(queuedShapes, (a, b) -> Double.compare(b.onScreenZ, a.onScreenZ));

Back-to-front sorting is essential for correct transparency and occlusion. Shapes further from the camera are painted first.

The screen is divided into 8 horizontal segments, each rendered by a separate thread:

Each thread:

• Gets a SegmentRenderingContext with Y-bounds (minY, maxY)
• Iterates all shapes and paints pixels within its Y-range
• Clips triangles/lines at segment boundaries
• Detects mouse hits (before clipping)

A CountDownLatch waits for all 8 threads to complete before proceeding.

Why 8 segments? This matches the typical core count of modern CPUs. The fixed thread pool (Executors.newFixedThreadPool(8)) avoids the overhead of creating threads per frame.

During painting, each segment tracks which shape is under the mouse cursor. Since all segments paint the same shapes (just different Y-ranges), they should all report the same hit. Phase 5 takes the first non-null result:

for (SegmentRenderingContext ctx : segmentContexts) {
    if (ctx.getSegmentMouseHit() != null) {
        renderingContext.setCurrentObjectUnderMouseCursor(ctx.getSegmentMouseHit());
        break;
    }
}

The rendered BufferedImage is copied to the screen using BufferStrategy for tear-free page-flipping:

do {
    Graphics2D g = bufferStrategy.getDrawGraphics();
    g.drawImage(renderingContext.bufferedImage, 0, 0, null);
    g.dispose();
} while (bufferStrategy.contentsRestored());

bufferStrategy.show();
Toolkit.getDefaultToolkit().sync();

The do-while loop handles the case where the OS recreates the back buffer (common during window resizing). Since our offscreen BufferedImage still has the correct pixels, we only need to re-blit, not re-render.