Glitch in drawing of sparse console with variable size

[imoea]

The following changes the sparse console's size every tick. Is this just happening on my end or is the drawing glitchy?

bracket_terminal::add_wasm_support!();
use bracket_terminal::prelude::*;

struct State {
    n: i32,
}

impl GameState for State {
    fn tick(&mut self, ctx: &mut BTerm) {
        let mut draw_batch = DrawBatch::new();
        draw_batch.target(1);
        draw_batch.cls();
        self.n = (self.n + 1) % 80;
        draw_batch.draw_box(
            Rect::with_size(0, 0, self.n, 1),
            ColorPair::new(RGB::named(WHITE), RGB::named(BLACK)),
        );
        draw_batch.submit(0).expect("Batch error");
        render_draw_buffer(ctx).expect("Render error");
    }
}

fn main() -> BError {
    let context = BTermBuilder::simple80x50()
        .with_font("vga8x16.png", 8u32, 16u32)
        .with_sparse_console(80u32, 25u32, "vga8x16.png")
        .build()?;
    let gs = State { n: 0 };
    main_loop(context, gs)
}

Here's a screenshot of the glitch:

[jice-nospam]

I don't reproduce it using the same code. Are you running it with default features?

[imoea]

I've tried it with and without. The above was created and run from the bracket-lib/bracket-terminal/examples directory.

[jice-nospam]

yeah same thing. I put the code in bracket-lib/bracket-terminal/examples/test.rs and ran it with cargo run --example test. no glitch here

[imoea]

I am reproducing it on a different computer as well. Both are running Windows 10 with default features but one builds with x86_64-pc-windows-msvs and the other with x86_64-pc-windows-gnu.

[jice-nospam]

are you using bracket-lib from git or the latest crates.io release? I don't reproduce with the master branch from git :

bracket-lib = {git="https://github.com/thebracket/bracket-lib"}

[imoea]

I'm using the one from git.

[jice-nospam]

I reproduce it on another computer ! investigating... This might be dependant on the opengl version

[jice-nospam]

The problem occurs only when using DrawBatch, and the glitch appears only when current frame is different from the last one. This code not using batches works fine :

    fn tick(&mut self, ctx: &mut BTerm) {
        ctx.cls();
        self.n = (self.n + 1) % 80;
        ctx.draw_box(0, 0, self.n, 1, RGB::named(WHITE), RGB::named(BLACK));
    }

Also when pausing the animation with the batch version so that it changes only when you press a key :

        if ctx.key.is_some() {
            self.n = (self.n + 1) % 80;
        }

you can see that the rendering is ok for any value of n. But every time n changes, the next frame is broken.

[jice-nospam]

Found it !

draw_batch.target(1);

should be

draw_batch.target(0);

You have only one console and consoles id start with 0. On the other hand, Bterm accepting an invalid console id is probably a bug

[imoea]

That's not right.. I'm following directly from the bracket-lib/bracket-terminal/examples/sparse.rs example.
https://github.com/thebracket/bracket-lib/blob/19f065594b2328e8f31bb3f2e5156a14485abe3f/bracket-terminal/examples/sparse.rs#L18-L20
https://github.com/thebracket/bracket-lib/blob/19f065594b2328e8f31bb3f2e5156a14485abe3f/bracket-terminal/examples/sparse.rs#L41-L44
The terminal builder creates 2 consoles, a simple one (indexed 0) and a sparse one (indexed 1). draw_batch.target(0) draws on the simple console so you won't see the glitch since its size never changes (always 80x50). The glitch occurs when the sparse console changes size every draw draw_batch.target(1).

[jice-nospam]

Indeed.

What I don't get with sparse consoles is how to handle several operation on the same console cell. For example, draw_box first fills the area with white spaces, then draws the rectangle around the box. As far as I understand, this means there are two SparseTile with the same id in the tiles array and I don't understand how this is handled in the rendering backend.

[imoea]

Just thought I'd mention that I've reverted to the more stable crates.io version for development and this issue doesn't seem to be present in there.

[thebracket]

I ran the attached (original) code on my workstation, and it ran glitch-free on the latest HEAD/master. It ran ok in my Ubuntu VM, also. Scaling the window and messing with display scaling didn't seem to make it fail.

Overdraw:
Think of sparse tiles as draw calls (they are actually data in one big draw call) - so if you somehow get two identical indices for the same tile, they are rendered in draw call order. One will overwrite the other, or you'll get odd overlay effects. You can actually use that for some pretty funky stuff with alpha enabled... but it isn't really meant to happen.

Anyway, the overdraw is a feature on flexible consoles - and a bug on sparse consoles. I'll see about cleaning up the sparse console and adding index checking on the set target call.

[imoea]

The glitch seems to be gone now. Great!