Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/th04/formats/z_super_roll_put_tiny.asm

399 lines
7.2 KiB
NASM
Raw Normal View History

[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
; superimpose & master library module
;
; Description:
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
; パターンの表示(16x16/32x32限定, 4色以内, 画面上下連続)
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
;
; Functions/Procedures:
[Maintenance] Declare distinct types for screen, VRAM, and TRAM coordinates Whew, time to look at every `int` variable we ever declared! The best moment to do this would have been a year ago, but well, better late than never. No need to communicate that in comments anymore. These shouldn't be used for widths, heights, or sprite-space coordinates. Maybe we'll cover that another time, this commit is already large enough. Part of P0111, funded by [Anonymous] and Blue Bolt.
2020-08-20 19:59:45 +00:00
; void z_super_roll_put_tiny_32x32(
; screen_x_t left<ax>, vram_y_t top<dx>, int num
; );
; void z_super_roll_put_tiny_16x16(
; screen_x_t left<ax>, vram_y_t top<dx>, int num
; );
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
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:
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
; z_super_roll_put_tiny_16x16() is a micro-optimized version of master.lib's
; original super_roll_put_tiny(), used for drawing all sorts of 16×16
; sprites in TH04 and TH05. Changes compared to the original:
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
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.
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
; ZUN then adapted this modified function for 32×32 pixel sprites.
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
;
; Compiler/Assembler:
; TASM 3.0
; OPTASM 1.6
;
; Author:
; 恋塚(恋塚昭彦)
; ZUN
;
; Revision History:
; 93/ 9/19 Initial: superrpt.asm / master.lib 0.21
;
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
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
ret_bx ; ZUN change
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
EVEN
endm
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
srpt32x32_vram_topleft dw 0
public Z_SUPER_ROLL_PUT_TINY_32X32_RAW
z_super_roll_put_tiny_32x32_raw proc near
; Parameters
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
arg_bx near, @patnum:word
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
@@left equ ax
@@top equ dx
; Locals
@@PATTERN_HEIGHT = 32
@@first_mask equ dl
@@rows_left equ ch
push ds
push si
push di
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
mov bx, @patnum
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
shl bx, 1
mov ds, super_patdata[bx]
mov bx, @@top
shl bx, 2
add bx, @@top
shl bx, 4
mov cx, @@left
and cx, 7 ; CL = x & 7
shr @@left, 3
add bx, @@left
mov cs:srpt32x32_vram_topleft, bx
xor si, si
lodsw
cmp al, 80h ; is this tiny sprite data?
jnz short @@RETURN
mov @@first_mask, 0FFh
shr @@first_mask, cl
test bl, 1
jnz short @@ODD_COLOR_LOOP
@@EVEN_COLOR_LOOP:
[Maintenance] [th04/th05] Declare GRCG register setting functions in C land Part of P0089, funded by [Anonymous] and Blue Bolt.
2020-04-26 14:26:40 +00:00
call @@grcg_setcolor
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
mov @@rows_left, @@PATTERN_HEIGHT
mov di, cs:srpt32x32_vram_topleft
cmp di, (RES_Y - @@PATTERN_HEIGHT + 1) * ROW_SIZE
jb short @@EVEN_YLOOP2
@@EVEN_YLOOP1:
call put32_even
cmp di, PLANE_SIZE
jb short @@EVEN_YLOOP1
sub di, PLANE_SIZE
even
@@EVEN_YLOOP2:
call put32_even
jnz short @@EVEN_YLOOP2
lodsw
cmp al, 80h
jz short @@EVEN_COLOR_LOOP
@@RETURN:
MRETURN
; ---------------------------------------------------------------------------
@@ODD_COLOR_LOOP:
[Maintenance] [th04/th05] Declare GRCG register setting functions in C land Part of P0089, funded by [Anonymous] and Blue Bolt.
2020-04-26 14:26:40 +00:00
call @@grcg_setcolor
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
mov @@rows_left, @@PATTERN_HEIGHT
mov di, cs:srpt32x32_vram_topleft
cmp di, (RES_Y - @@PATTERN_HEIGHT + 1) * ROW_SIZE
jb short @@ODD_YLOOP2
@@ODD_YLOOP1:
call put32_odd
cmp di, PLANE_SIZE
jb short @@ODD_YLOOP1
sub di, PLANE_SIZE
nop
@@ODD_YLOOP2:
call put32_odd
jnz short @@ODD_YLOOP2
lodsw
cmp al, 80h
jz short @@ODD_COLOR_LOOP
MRETURN
; ---------------------------------------------------------------------------
[Maintenance] [th04/th05] Declare GRCG register setting functions in C land Part of P0089, funded by [Anonymous] and Blue Bolt.
2020-04-26 14:26:40 +00:00
; void __usercall near @@grcg_setcolor(uint4_t col<ah>);
@@grcg_setcolor:
GRCG_SETCOLOR_DIRECT ah
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
ret
even
; ---------------------------------------------------------------------------
; These put functions take:
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
; • const dots32_t* row_color_pixels<ds:si>
; • dots32_t* vram_offset<es:di>
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
; • uint3_t first_bit<cl>
; • uint8_t& rows_left<ch>
[Maintenance] Use `dots` for 1bpp lines, and `planar` for B/R/G/E dot structs I tried `brge` for the latter, but that had *the* most horrible ergonomics, and I misspelled it as `bgre` 100% of the times I typed it manually. Turns out that `dots` is also consistent with master.lib's naming scheme, leaving `planar` to *actually* refer to types storing multiple planes worth of pixels. These types are showing up more and more, and deserve something better than their previous long-winded and misleading name. Part of P0081, funded by Ember2528.
2020-03-06 23:25:03 +00:00
; • dots8_t first_mask<dl>
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
; [rows_left] is decremented at the end. ZF then indicates whether this was
; the last row.
@@first_bit equ cl
@@words equ bh
@@carry_pixels equ bl
put32_even: ; if X is even
xor @@carry_pixels, @@carry_pixels
mov @@words, 2
lodsd
@@EVEN_WORD_LOOP:
ror ax, @@first_bit
mov dh, al
and al, @@first_mask
xor dh, al
or al, @@carry_pixels
mov @@carry_pixels, dh
or ax, ax
jz short @@EVEN_SKIP_BLANK_WORD
mov es:[di], ax
@@EVEN_SKIP_BLANK_WORD:
add di, word
shr eax, (8 * word)
dec @@words
jnz short @@EVEN_WORD_LOOP
or @@carry_pixels, @@carry_pixels
jz short @@EVEN_SKIP_BLANK_5TH
mov es:[di], @@carry_pixels
@@EVEN_SKIP_BLANK_5TH:
add di, (ROW_SIZE - dword)
dec @@rows_left
retn
even
put32_odd: ; if X is odd
mov @@words, 2
lodsd ; EAX = the 32 pixels of this row
ror al, @@first_bit
mov @@carry_pixels, al
and al, @@first_mask
jz short @@ODD_SKIP_BLANK_1ST
mov es:[di], al
@@ODD_SKIP_BLANK_1ST:
xor @@carry_pixels, al
inc di
shr eax, (8 * byte)
@@ODD_WORD_LOOP:
ror ax, @@first_bit
mov dh, al
and al, @@first_mask
xor dh, al
or al, @@carry_pixels
mov @@carry_pixels, dh
or ax, ax
jz short @@ODD_SKIP_BLANK_WORD
mov es:[di], ax
@@ODD_SKIP_BLANK_WORD:
add di, word
shr eax, (8 * word)
dec @@words
jnz short @@ODD_WORD_LOOP
add di, (ROW_SIZE - (dword + 1))
dec @@rows_left
retn
Z_SUPER_ROLL_PUT_TINY_32X32_RAW endp
[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() {
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
even
mov BX,SP
push DS
push SI
push DI
@@num = 2
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
@@PATTERN_HEIGHT = 16
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
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 ; １色もないとき(おいおい)
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
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
mov CH,@@PATTERN_HEIGHT
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
mov DI,BX
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
cmp DI,(SCREEN_HEIGHT-@@PATTERN_HEIGHT+1)*SCREEN_XBYTES
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
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
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
mov CH,@@PATTERN_HEIGHT
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
mov DI,BX
[Reverse-engineering] [th04/th05] Micro-optimized 32×32 sprite display Which *looks* like a master.lib function, but only because ZUN adapted his own micro-optimized super_roll_put_tiny() for 32×32. Good thing we covered that one first! Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-08 12:05:07 +00:00
cmp DI,(SCREEN_HEIGHT-@@PATTERN_HEIGHT+1)*SCREEN_XBYTES
[Reduction] [th04/th05] Micro-optimized version of super_roll_put_tiny() Y'know, maybe ZUN measured and all of this actually mattered? What do I know? Funded by -Tom-.
2018-12-31 19:41:13 +00:00
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 ; }