Blanking the display for one (or more) scanlines only

[BigEvilCorporation]

Hi!

I'm trying to achieve a "letterbox" style mode for cutscenes, creating black bars at the top and bottom of the screen. Modifying the tiles isn't a viable option without some considerable changes to my codebase, and it would use too many sprites.

I've tried blanking the display by modifying VDP reg 2 during HINT, which seems to give the desired effect for sprites but not for scroll planes.

Has anyone experimented with changing VDP regs inside HINT, and could share their findings?

[Sik]

VDP reg 2 ($82xx) is the scroll A plane address...

As far as I'm aware you just have to toggle the display bit in reg 1 ($8134 disables display while keeping vblank IRQ and DMA turned on, $8174 turns it back on). That should affect everything, just beware that if you do it mid-scanline that it will blank the line halfway (with a granurality of 16 pixels - note to emulator authors: do it too early and Overdrive glitches).

If you only got it to work for sprites then you did something really wrong =P

[BigEvilCorporation]

If you only got it to work for sprites then you did something really wrong =P

Damn. Well, my code is simple enough:

Code: Select all

HBlankInterrupt:
	move.l d0, -(sp)

	move.w (hline_counter), d0
	andi.w #0x1, d0
	cmp.w  #0x1, d0
	beq    @ScreenOff
	
	move.w #0x8174, vdp_control
	
	bra     @EndLetterbox
	
	@ScreenOff:
	
	move.w #0x8134, vdp_control
	
	@EndLetterbox:
	
	move.l (sp)+, d0
	
	addi.w #0x1, hline_counter
	rte

Which produces:



but the original scene looks like:

[Sik]

You aren't trying to write to the scroll planes while the hblanks are happening, right? Because setting a register will unset the current address.

By the way, you can remove the CMP, it's redundant. In fact, it the subroutine is in RAM (convenient when you can have multiple hblank subroutines in the program) you probably could do this (where HBlank points to the subroutine address in RAM):

Code: Select all

    move.w  #$8134, ($C00004)
    bchg.b  #6, (HBlank+3)
    rte

EDIT: but wait, is the scanlines effect the one you're trying to do? =/

[BigEvilCorporation]

You aren't trying to write to the scroll planes while the hblanks are happening, right? Because setting a register will unset the current address.

No, I keep the update and render code mutually exclusive, and there is nothing else in my hblank routine.

By the way, you can remove the CMP, it's redundant.

Yep, something I learned recently and need to go back over the whole codebase optimising it all! Self-modifying code isn't something I've started learning yet, maybe later.

EDIT: but wait, is the scanlines effect the one you're trying to do? =/

No, this is just a test. Eventually I want to blank the first and last 16 scanlines (maybe animating from 0 to 16).

[powerofrecall]

I was thinking you could probably achieve the effect using h-ints to copy palettes at the appropriate times. You start with an all black palette, then when you hit the right scanline, switch to your color palette. Then when you hit the scanline you want on the bottom, switch back to all-black. You'd likely get the ugly CRAM dots here (but maybe it wouldn't be as obvious? They would be black perhaps??). This way you wouldn't even need to worry about masking sprites or constraining them to the viewport.

If there's a hole in this idea I'm curious.

[TmEE co.(TM)]

It is easier to turn off rendering than to start messing with CRAM in the HBL handler, 1 write vs bazillion

[tryphon]

Code: Select all

    move.w  #$8134, ($C00004)
    bchg.b  #6, (HBlank+3)
    rte

VERY
CLEVER !!!!!

just that