A long time ago, I was a MSX and MSX2 programmer

Enlighted (6067)

14-12-2012, 14:24

PingPong wrote:

Smooth Scrolling on msx1 have the usual colour clash problem if done horizontally

Yes, and it is very visible in the video... Actually it is much more visible than it would have to be as sometimes the 2 colors are selected totally wrong.

By MäSäXi

Paragon (1884)

14-12-2012, 15:22

Hello Frederic! Nice to see MSX2 did the same things I used to watch on my Amiga back then. On that Mobygames page, Unreal is mentioned there, but I cannot see you in Amiga credits. So did you participate in programming Amiga version? I liked that game a lot back then!

By ARTRAG

Enlighted (6935)

14-12-2012, 23:11

@hit9918
using 16 pointers per tile costs 2*16*256=8K of ram just to point to loose columns
using 16 pointers+one page selector is 3*16*256=12K of ram only to point to the data...
quite a lot of overhead to be stored in ram...

By frederic.markus

Expert (83)

15-12-2012, 03:21

I was production on Unreal, not code. I don't even know how my name got mention in the credits in Mobygames...

By MäSäXi

Paragon (1884)

15-12-2012, 05:54

Ok, thank you.

By PingPong

Enlighted (4137)

15-12-2012, 10:30

NYYRIKKI wrote:

PingPong wrote:

Smooth Scrolling on msx1 have the usual colour clash problem if done horizontally

Yes, and it is very visible in the video... Actually it is much more visible than it would have to be as sometimes the 2 colors are selected totally wrong.

But vertically, it's nice!

By ARTRAG

Enlighted (6935)

17-12-2012, 10:00

@hit9918
I'm testing your proposal, this is a quick and dirty implementation that plots a column of pixels at the right side of the screen using CPU and data stored in RAM. The used data are:
uchar level[WX][HY]; // level map
uchar tile[Ntile][256]; // array of tiles stores by columns
Is this your idea?

void new_line_rgt(char i)
{
	offs = i*16;
	addr = 240+i;
	p = &level[xw+15][yw+0];	

#asm
	global	_tile,_q
	global	_vdpsetvramwr

	ld	b,YSIZE/16 
2:	push	bc

  ; q = &tile[*p++][offs];
  
	ld	hl,(_p)
	ld	a,(hl)
	inc	hl
	ld	(_p),hl
	ld	de,(_offs)
	add	a,d
	ld	d,a
	ld	hl,_tile
	add	hl,de			; from here hl points the current tile column

	ld	bc,16*256+0x98
	
	ld	a,(_addr+1)
	ld d,a
	ld a,(_displaypage)
	rlc d
	rla
	rlc d
	rla
	ld	de,(_addr)	;	de restored	
	
	di
	out (0x99),a 		; set bits 15-17
	ld a,14+128	
	out (0x99),a
1:	ld a,e 				; set bits 0-7
	out (0x99),a
	ld a,d 				; set bits 8-14
	and	0x3f
	or 64 				; + write access
	out (0x99),a
	inc	d
	outi                
	jp	nz,1b
	
	ld	(_addr),de
	ei
	
	pop	bc
	djnz 2b
#endasm


}

By hit9918

Prophet (2932)

18-12-2012, 06:53

@ARTRAG,
You wrote about "columns", did you compress the level pic on a per-column basis?
I meant tiles and a nametable:

I vote for 8x8 pixel tiles and 16bit nametable.
Many games want the fine resolution of 8x8 pixel tiles.
The 16bit nametable can address more than 256 tiles, capable of big games.

The 16bit nametable consists of pointers directly to the pattern.
Get at pattern address without further calculation.

sketch:

;ix points to 16bit nametable
drawborder:
	;todo some vram setup beond 16k needed here. and make proper HL' for vram setup
	ld a,8		;8*8 lines a 256 byte = 16k
drawborder16k:
21	ld l,(ix)
21	ld h,(ix+1) ;hl points to start of tile pattern. at same time, hl is an unique 16bit tile ID.
17	add ix,de   ;go to next line in the 16bit nametable.

---- 8x this ---
5   exx
14  out (c),l	;c = 0x99
14  out (c),h	;set vram addr. got setwrite bit set
5   inc h	;one line down
5   exx
18  outi	;c = 0x98. tiles stored 90 degree rotated in RAM, to port 98.
--
61 x 8 = 488


------------
5	dec a
11	jp nz,drawborder16k
--
563 cycles per 8 lines,  0.3 rasterlines per line.
	
	;todo vram offset beyond 16k, and jump upwards to drawborder outer loop
	ret

49 rasterlines for 160 lines.
Interesting, this cpu borderdraw should take no more time than a nametable draw in screen 4.

With cpu and blitter parallel, I feel there is a problem in the last scroll step.
The column copy wants to copy the same column where you just draw the border?

Maybe draw 10% of the border (2 tiles), start blitter, then draw rest of the border.
The blitter columncopy, which takes in the order of a frame, wont overtake the cpu borderdraw whose speed is "many times per frame".
But right at start of blitter, it may copy some lines of the column before cpu gets into the tiles loop, that is why I thought pre-draw some border.

p.s.
With 16bit tile number = 16bit tile address one can do things like "at offset -1 of that address is a flag byte". The flag can contain collision bits for the tile.
Then a tile would take 8x8+1 = 65 bytes in memory.

given 16bit tile address in HL,
dec hl
bit n,(hl)
makes a check like e.g. "can I walk on this tile".

By ARTRAG

Enlighted (6935)

18-12-2012, 12:42

I like the 16 bit nametable, BTW I was already optimising my current solution with 16x16 tiles stored by columns and 8 bit nametable. This is how my code looks now:

void new_line_rgt(char i)
{
        offs = i*16;
        addr = 240+i;
        p = &level[xw+15][yw+0];        

#asm
        global  _tile,_q
        global  _vdpsetvramwr
        
        ld a,(_displaypage)
        add a,a
        add a,a ; R#14
    ex af,af'
        ld de,(_addr) 

        rept 2
        ld a,d
        and 0x3f
        or 64
        ld d,a
        di
        ex af,af'
        out (0x99),a   ; set bits 15-17
        ex af,af' 
        ld a,14+128 
        out (0x99),a
        call inner
        call inner
        call inner
        call inner
        ei
        ex af,af'
        inc a
        ex af,af'
        ld de,(_addr) 
        ld   hl,16*4
        add  hl,de
        ld (_addr),de
        endm

; LAST 3 LINES
        ld a,d
        and 0x3f
        or 64
        ld d,a
        di
        ex af,af'
        out (0x99),a   ; set bits 15-17
        ex af,af' 
        ld a,14+128 
        out (0x99),a
        call inner
        call inner
        call inner
        ei
        ret
inner:
        ld hl,(_p)      ; q = &tile[*p++][offs];
        ld a,(hl)
        inc hl
        ld (_p),hl
        ld bc,(_offs)
        add a,b
        ld b,a
        ld hl,_tile
        add hl,bc       ; from here hl points the current tile column
         
        ld c,0x98

        rept 16
        ld a,e     ; set bits 0-7
        out (0x99),a
        ld a,d     ; set bits 8-14
        out (0x99),a
        inc d
        outi               
        endm

        ret
#endasm

I agree that "edge effects" can occur when copying the last column.
I need to study a bit the whole behaviour of the code to tell you better how they appear.

Probably last column has to be considered apart...

By hit9918

Prophet (2932)

18-12-2012, 20:46

@ARTRAG, is existing tools the reason to go 16x16 ?
With 8x8 you could again have "gfx of multiple random games in one level"