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

111 lines
1.9 KiB
NASM
Raw Normal View History

[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
proc_defconv pi_slot_put
@@slot = word ptr [bp + (cPtrSize + 2)]
@@y = word ptr [bp + (cPtrSize + 4)]
@@x = word ptr [bp + (cPtrSize + 6)]
push bp
mov bp, sp
push si
push di
mov si, @@slot
mov di, si
shl si, 2
Make previously reduced ZUN functions available to C
2015-02-21 13:12:22 +00:00
les si, _pi_slot_buffers[si]
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
imul di, size PiHeader
push @@x
push @@y
Make previously reduced ZUN functions available to C
2015-02-21 13:12:22 +00:00
mov ax, _pi_slot_headers.PiHeader._xsize[di]
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
push ax
shr ax, 1
push ax
Make previously reduced ZUN functions available to C
2015-02-21 13:12:22 +00:00
mov di, _pi_slot_headers.PiHeader._ysize[di]
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
call pi_slot_put_rowloop
pop di
pop si
pop bp
ret 6
Make previously reduced ZUN functions available to C
2015-02-21 13:12:22 +00:00
endp_defconv
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
align 2
; ---------------------------------------------------------------------------
proc_defconv pi_slot_put_quarter
@@quarter = byte ptr [bp + (cPtrSize + 2)]
@@slot = word ptr [bp + (cPtrSize + 4)]
@@y = word ptr [bp + (cPtrSize + 6)]
@@x = word ptr [bp + (cPtrSize + 8)]
push bp
mov bp, sp
push si
push di
xor ax, ax
xor dx, dx
mov si, @@slot
mov cl, @@quarter
test cl, 1
jz short @@bottom_quarter?
mov ax, 160
@@bottom_quarter?:
test cl, 2
jz short @@put
mov dx, ((640 * 200) / 2) / 16
@@put:
shl si, 2
Make previously reduced ZUN functions available to C
2015-02-21 13:12:22 +00:00
les si, _pi_slot_buffers[si]
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
add si, ax
mov ax, es
add ax, dx
mov es, ax
push @@x
push @@y
push 320
push 320
mov di, 200
call pi_slot_put_rowloop
pop di
pop si
pop bp
ret 8
Make previously reduced ZUN functions available to C
2015-02-21 13:12:22 +00:00
endp_defconv
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
; ---------------------------------------------------------------------------
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
; void pascal pi_slot_put_mask_rowloop(
; void far *pi_buf<es:si>,
; int h<di>,
; int x, int y, int w, size_t stride_packed
; );
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
pi_slot_put_rowloop proc near
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
@@stride_packed = word ptr [bp+2]
@@w = word ptr [bp+4]
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
@@y = word ptr [bp+6]
@@x = word ptr [bp+8]
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
@@h equ di
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
mov bp, sp
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
@@put_row:
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
push es
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
call graph_pack_put_8_noclip pascal, @@x, @@y, es, si, @@w
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
pop es
inc @@y
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
cmp @@y, RES_Y
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
jb short @@next_row
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
sub @@y, RES_Y
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
@@next_row:
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
add si, @@stride_packed
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
mov ax, si
shr ax, 4
mov dx, es
add dx, ax
mov es, dx
and si, 0Fh
[Maintenance] [th05] Clarify pi_slot_put() a bit Can't blame WindowsTiger for writing hard-to-review code when he just adapted what I wrote in 2014…
2019-12-15 14:08:35 +00:00
dec @@h
jnz short @@put_row
[Reverse-engineering] Slot-based PI display Also covering the two variations for blitting only every second row or blitting only a 320x200 quarter, as seen in the endings. So yeah, there's indeed nothing wrong with piread.cpp. TH03 just uses that separate function that only blits every second row of an image, and indeed always loads the entire image as it would appear in a PNG conversion. Here's what happens if you display these images using the non-interlacing function: https://www.dropbox.com/s/885krj09d9l0890/th03%20PI%20no%20interlace.png
2014-12-18 13:36:43 +00:00
retn 8
pi_slot_put_rowloop endp