2018-12-31 19:41:13 +00:00
|
|
|
|
; superimpose & master library module
|
|
|
|
|
;
|
|
|
|
|
; Description:
|
|
|
|
|
; パターンの表示(16x16限定, 4色以内, 画面上下連続)
|
|
|
|
|
;
|
|
|
|
|
; Functions/Procedures:
|
[Maintenance] [th04/th05] Improve the z_super_roll_put*() naming convention
So, master.lib has:
• super_put_tiny() for tiny-format 16×n sprites
• super_roll_put_tiny() for vertically wrapped tiny-format 16×16
sprites
• super_put_tiny_small() for tiny-format 8×n sprites
• yet *no* super_roll_put_tiny_small() function
And now we have ZUN adding micro-optimized versions of:
1) vertically-wrapped tiny-format 16×16, clearly based on master.lib's
super_roll_put_tiny(), RE'd in 35f9bd7
2) vertically-wrapped tiny-format 32×32
3) vertically-wrapped non-tiny monochrome 16×16 (TH05 only)
Conclusion: Even though 1) does duplicate a master.lib function, trying
to continue following master.lib's inconsistent naming convention only
leads to more confusion here. master.lib also already designates the _8
suffix to mean "x will be byte-aligned, ⌊x/8⌋*8"…
So let's:
• spell out both coordinates of the sprite size directly in the
function
• keep the z_ prefix to encode ZUN's optimized calling convention
(left/top coordinates in registers, ES already set to the beginning
of a VRAM plane, GRCG already on) for all of these, not just 1).
• and prefix the actual functions with _raw, since C land will want
to handle the coordinate parameter registers in a macro.
Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-06 21:45:59 +00:00
|
|
|
|
; void z_super_roll_put_tiny_16x16( int left<ax>, int top<dx>, int num ) ;
|
2018-12-31 19:41:13 +00:00
|
|
|
|
;
|
|
|
|
|
; Parameters:
|
|
|
|
|
; x,y 描画する座標
|
|
|
|
|
; num パターン番号
|
|
|
|
|
;
|
|
|
|
|
; Returns:
|
|
|
|
|
; none
|
|
|
|
|
;
|
|
|
|
|
; Binding Target:
|
|
|
|
|
; Microsoft-C / Turbo-C / Turbo Pascal
|
|
|
|
|
;
|
|
|
|
|
; Running Target:
|
|
|
|
|
; PC-9801
|
|
|
|
|
;
|
|
|
|
|
; Requiring Resources:
|
|
|
|
|
; CPU: V30
|
|
|
|
|
; GRCG
|
|
|
|
|
;
|
|
|
|
|
; Notes:
|
|
|
|
|
; Micro-optimized version of the original master.lib function, used for
|
|
|
|
|
; drawing all sorts of 16×16 sprites in TH04 and TH05. Changes compared to
|
[Maintenance] [th04/th05] Improve the z_super_roll_put*() naming convention
So, master.lib has:
• super_put_tiny() for tiny-format 16×n sprites
• super_roll_put_tiny() for vertically wrapped tiny-format 16×16
sprites
• super_put_tiny_small() for tiny-format 8×n sprites
• yet *no* super_roll_put_tiny_small() function
And now we have ZUN adding micro-optimized versions of:
1) vertically-wrapped tiny-format 16×16, clearly based on master.lib's
super_roll_put_tiny(), RE'd in 35f9bd7
2) vertically-wrapped tiny-format 32×32
3) vertically-wrapped non-tiny monochrome 16×16 (TH05 only)
Conclusion: Even though 1) does duplicate a master.lib function, trying
to continue following master.lib's inconsistent naming convention only
leads to more confusion here. master.lib also already designates the _8
suffix to mean "x will be byte-aligned, ⌊x/8⌋*8"…
So let's:
• spell out both coordinates of the sprite size directly in the
function
• keep the z_ prefix to encode ZUN's optimized calling convention
(left/top coordinates in registers, ES already set to the beginning
of a VRAM plane, GRCG already on) for all of these, not just 1).
• and prefix the actual functions with _raw, since C land will want
to handle the coordinate parameter registers in a macro.
Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-06 21:45:59 +00:00
|
|
|
|
; the original:
|
2018-12-31 19:41:13 +00:00
|
|
|
|
; • Procedure distance is NEAR rather than FAR.
|
|
|
|
|
; • X and Y coordinates are passed in AX and DX, respectively, rather than
|
|
|
|
|
; on the stack.
|
|
|
|
|
; • Therefore, I removed the WIDE_RANGE branch, as it wouldn't have worked
|
|
|
|
|
; with the changed register contents anyway.
|
|
|
|
|
; • A small attempt to optimize the EVEN_COLOR_LOOP by jumping over the
|
|
|
|
|
; blitting write of the third byte if it is blank.
|
|
|
|
|
;
|
|
|
|
|
; Compiler/Assembler:
|
|
|
|
|
; TASM 3.0
|
|
|
|
|
; OPTASM 1.6
|
|
|
|
|
;
|
|
|
|
|
; Author:
|
|
|
|
|
; 恋塚(恋塚昭彦)
|
|
|
|
|
; ZUN
|
|
|
|
|
;
|
|
|
|
|
; Revision History:
|
|
|
|
|
; 93/ 9/19 Initial: superrpt.asm / master.lib 0.21
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
PATTERN_HEIGHT equ 16
|
|
|
|
|
SCREEN_HEIGHT equ 400
|
|
|
|
|
SCREEN_XBYTES equ 80
|
|
|
|
|
GC_MODEREG equ 07ch
|
|
|
|
|
GC_TILEREG equ 07eh
|
|
|
|
|
GC_RMW equ 0c0h ; 書き込みビットが立っているドットにタイルレジスタから書く
|
|
|
|
|
|
|
|
|
|
MRETURN macro
|
|
|
|
|
pop DI
|
|
|
|
|
pop SI
|
|
|
|
|
pop DS
|
|
|
|
|
ret 2 ; ZUN change, since only one parameter is passed via the stack
|
|
|
|
|
EVEN
|
|
|
|
|
endm
|
|
|
|
|
|
[Maintenance] [th04/th05] Improve the z_super_roll_put*() naming convention
So, master.lib has:
• super_put_tiny() for tiny-format 16×n sprites
• super_roll_put_tiny() for vertically wrapped tiny-format 16×16
sprites
• super_put_tiny_small() for tiny-format 8×n sprites
• yet *no* super_roll_put_tiny_small() function
And now we have ZUN adding micro-optimized versions of:
1) vertically-wrapped tiny-format 16×16, clearly based on master.lib's
super_roll_put_tiny(), RE'd in 35f9bd7
2) vertically-wrapped tiny-format 32×32
3) vertically-wrapped non-tiny monochrome 16×16 (TH05 only)
Conclusion: Even though 1) does duplicate a master.lib function, trying
to continue following master.lib's inconsistent naming convention only
leads to more confusion here. master.lib also already designates the _8
suffix to mean "x will be byte-aligned, ⌊x/8⌋*8"…
So let's:
• spell out both coordinates of the sprite size directly in the
function
• keep the z_ prefix to encode ZUN's optimized calling convention
(left/top coordinates in registers, ES already set to the beginning
of a VRAM plane, GRCG already on) for all of these, not just 1).
• and prefix the actual functions with _raw, since C land will want
to handle the coordinate parameter registers in a macro.
Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-06 21:45:59 +00:00
|
|
|
|
public Z_SUPER_ROLL_PUT_TINY_16x16_RAW
|
|
|
|
|
Z_SUPER_ROLL_PUT_TINY_16x16_RAW proc near ; z_super_roll_put_tiny_16x16_raw() {
|
2018-12-31 19:41:13 +00:00
|
|
|
|
even
|
|
|
|
|
mov BX,SP
|
|
|
|
|
push DS
|
|
|
|
|
push SI
|
|
|
|
|
push DI
|
|
|
|
|
|
|
|
|
|
@@num = 2
|
|
|
|
|
|
|
|
|
|
mov BX,SS:[BX+@@num]
|
|
|
|
|
shl BX,1
|
|
|
|
|
mov DS,super_patdata[BX]
|
|
|
|
|
|
|
|
|
|
; SCREEN_XBYTES = 80 を想定
|
|
|
|
|
mov BX,DX ; ZUN change, DI → DX
|
|
|
|
|
shl BX,2
|
|
|
|
|
add BX,DX ; ZUN change, DI → DX
|
|
|
|
|
shl BX,4
|
|
|
|
|
mov CX,AX ; ZUN change
|
|
|
|
|
and CX,7 ; CL = x & 7
|
|
|
|
|
shr AX,3
|
|
|
|
|
add BX,AX ; BX = draw start offset
|
|
|
|
|
|
|
|
|
|
xor SI,SI
|
|
|
|
|
|
|
|
|
|
lodsw
|
|
|
|
|
cmp AL,80h
|
|
|
|
|
jnz short @@RETURN ; 1色もないとき(おいおい)
|
|
|
|
|
|
|
|
|
|
mov DL,0ffh ; DL = ワード境界マスク
|
|
|
|
|
shr DL,CL
|
|
|
|
|
|
|
|
|
|
test BL,1 ; ZUN change, BX → BL
|
|
|
|
|
jnz short @@ODD_COLOR_LOOP
|
|
|
|
|
EVEN
|
|
|
|
|
; 偶数アドレス
|
|
|
|
|
@@EVEN_COLOR_LOOP:
|
|
|
|
|
; 色の指定あるね
|
|
|
|
|
REPT 4
|
|
|
|
|
shr AH,1
|
|
|
|
|
sbb AL,AL
|
|
|
|
|
out GC_TILEREG,AL
|
|
|
|
|
ENDM
|
|
|
|
|
|
|
|
|
|
mov CH,PATTERN_HEIGHT
|
|
|
|
|
mov DI,BX
|
|
|
|
|
cmp DI,(SCREEN_HEIGHT-PATTERN_HEIGHT+1)*SCREEN_XBYTES
|
|
|
|
|
jb short @@EVEN_YLOOP2
|
|
|
|
|
|
|
|
|
|
EVEN
|
|
|
|
|
@@EVEN_YLOOP1:
|
|
|
|
|
lodsw
|
|
|
|
|
ror AX,CL
|
|
|
|
|
mov DH,AL
|
|
|
|
|
and AL,DL
|
|
|
|
|
mov ES:[DI],AX
|
|
|
|
|
xor AL,DH
|
|
|
|
|
jz @@EVEN_YLOOP1_SKIP_BLANK_3RD
|
|
|
|
|
mov ES:[DI+2],AL
|
|
|
|
|
|
|
|
|
|
@@EVEN_YLOOP1_SKIP_BLANK_3RD:
|
|
|
|
|
add DI,SCREEN_XBYTES
|
|
|
|
|
dec CH
|
|
|
|
|
cmp DI,SCREEN_HEIGHT*SCREEN_XBYTES
|
|
|
|
|
jb short @@EVEN_YLOOP1
|
|
|
|
|
|
|
|
|
|
sub DI,SCREEN_HEIGHT*SCREEN_XBYTES
|
|
|
|
|
|
|
|
|
|
EVEN
|
|
|
|
|
@@EVEN_YLOOP2:
|
|
|
|
|
lodsw
|
|
|
|
|
ror AX,CL
|
|
|
|
|
mov DH,AL
|
|
|
|
|
and AL,DL
|
|
|
|
|
mov ES:[DI],AX
|
|
|
|
|
xor AL,DH
|
|
|
|
|
jz @@EVEN_YLOOP2_SKIP_BLANK_3RD
|
|
|
|
|
mov ES:[DI+2],AL
|
|
|
|
|
|
|
|
|
|
@@EVEN_YLOOP2_SKIP_BLANK_3RD:
|
|
|
|
|
add DI,SCREEN_XBYTES
|
|
|
|
|
|
|
|
|
|
dec CH
|
|
|
|
|
jnz short @@EVEN_YLOOP2
|
|
|
|
|
|
|
|
|
|
@@EVEN_YLOOP_END:
|
|
|
|
|
lodsw
|
|
|
|
|
cmp AL,80h
|
|
|
|
|
je short @@EVEN_COLOR_LOOP
|
|
|
|
|
|
|
|
|
|
@@RETURN:
|
|
|
|
|
MRETURN
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EVEN
|
|
|
|
|
; 奇数アドレス
|
|
|
|
|
@@ODD_COLOR_LOOP:
|
|
|
|
|
; 色の指定あるね
|
|
|
|
|
REPT 4
|
|
|
|
|
shr AH,1
|
|
|
|
|
sbb AL,AL
|
|
|
|
|
out GC_TILEREG,AL
|
|
|
|
|
ENDM
|
|
|
|
|
|
|
|
|
|
mov CH,PATTERN_HEIGHT
|
|
|
|
|
mov DI,BX
|
|
|
|
|
cmp DI,(SCREEN_HEIGHT-PATTERN_HEIGHT+1)*SCREEN_XBYTES
|
|
|
|
|
jb short @@ODD_YLOOP2
|
|
|
|
|
|
|
|
|
|
EVEN
|
|
|
|
|
@@ODD_YLOOP1:
|
|
|
|
|
lodsw
|
|
|
|
|
ror AX,CL
|
|
|
|
|
mov DH,AL
|
|
|
|
|
and AL,DL
|
|
|
|
|
mov ES:[DI],AL
|
|
|
|
|
xor AL,DH
|
|
|
|
|
xchg AH,AL
|
|
|
|
|
mov ES:[DI+1],AX
|
|
|
|
|
add DI,SCREEN_XBYTES
|
|
|
|
|
|
|
|
|
|
dec CH
|
|
|
|
|
cmp DI,SCREEN_HEIGHT*SCREEN_XBYTES
|
|
|
|
|
jb short @@ODD_YLOOP1
|
|
|
|
|
|
|
|
|
|
sub DI,SCREEN_HEIGHT*SCREEN_XBYTES
|
|
|
|
|
|
|
|
|
|
EVEN
|
|
|
|
|
@@ODD_YLOOP2:
|
|
|
|
|
lodsw
|
|
|
|
|
ror AX,CL
|
|
|
|
|
mov DH,AL
|
|
|
|
|
and AL,DL
|
|
|
|
|
mov ES:[DI],AL
|
|
|
|
|
xor AL,DH
|
|
|
|
|
xchg AH,AL
|
|
|
|
|
mov ES:[DI+1],AX
|
|
|
|
|
add DI,SCREEN_XBYTES
|
|
|
|
|
|
|
|
|
|
dec CH
|
|
|
|
|
jnz short @@ODD_YLOOP2
|
|
|
|
|
|
|
|
|
|
@@ODD_YLOOP_END:
|
|
|
|
|
lodsw
|
|
|
|
|
cmp AL,80h
|
|
|
|
|
je short @@ODD_COLOR_LOOP
|
|
|
|
|
|
|
|
|
|
MRETURN
|
[Maintenance] [th04/th05] Improve the z_super_roll_put*() naming convention
So, master.lib has:
• super_put_tiny() for tiny-format 16×n sprites
• super_roll_put_tiny() for vertically wrapped tiny-format 16×16
sprites
• super_put_tiny_small() for tiny-format 8×n sprites
• yet *no* super_roll_put_tiny_small() function
And now we have ZUN adding micro-optimized versions of:
1) vertically-wrapped tiny-format 16×16, clearly based on master.lib's
super_roll_put_tiny(), RE'd in 35f9bd7
2) vertically-wrapped tiny-format 32×32
3) vertically-wrapped non-tiny monochrome 16×16 (TH05 only)
Conclusion: Even though 1) does duplicate a master.lib function, trying
to continue following master.lib's inconsistent naming convention only
leads to more confusion here. master.lib also already designates the _8
suffix to mean "x will be byte-aligned, ⌊x/8⌋*8"…
So let's:
• spell out both coordinates of the sprite size directly in the
function
• keep the z_ prefix to encode ZUN's optimized calling convention
(left/top coordinates in registers, ES already set to the beginning
of a VRAM plane, GRCG already on) for all of these, not just 1).
• and prefix the actual functions with _raw, since C land will want
to handle the coordinate parameter registers in a macro.
Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-06 21:45:59 +00:00
|
|
|
|
Z_SUPER_ROLL_PUT_TINY_16x16_RAW endp ; }
|