2020-08-20 19:59:45 +00:00
|
|
|
; Draws the hardcoded spark sprite with the given ID at the given position.
|
2019-02-27 17:05:22 +00:00
|
|
|
; pointing to the top-left point. Assumptions:
|
|
|
|
; • ES is already be set to the beginning of a VRAM segment
|
|
|
|
; • The GRCG is active, and set to the intended color
|
|
|
|
|
2020-08-20 19:59:45 +00:00
|
|
|
; void near fastcall spark_render(screen_x_t left, vram_y_t top, int sprite_id);
|
2019-02-27 17:05:22 +00:00
|
|
|
public @spark_render
|
|
|
|
@spark_render proc near
|
|
|
|
push si
|
|
|
|
push di
|
|
|
|
mov si, ax ; SI = [x]
|
|
|
|
mov bx, dx ; BX = [vram_y]
|
|
|
|
sar ax, 3 ; x / 8
|
|
|
|
shl dx, 6 ; [vram_y] * 64
|
|
|
|
add ax, dx
|
|
|
|
shr dx, 2 ; (([vram_y] * 64) / 4) = [vram_y] * 16
|
|
|
|
add ax, dx
|
|
|
|
mov di, ax ; ([vram_y] * 64) + ([vram_y] * 16) = [vram_y * ROW_SIZE]
|
|
|
|
and si, 7 ; [x] & 7
|
|
|
|
mov ax, si
|
|
|
|
shl si, 7 ; *= SPARK_SIZE * SPARK_SPRITES (offset of X-shifted sprite)
|
[Maintenance] Decide how to handle pre-shifted sprites in C land
Ideally, the future sprite compiler should automatically pre-shift such
sprites, and correctly place the shifted variants in memory, by merely
parsing the C header. On disk, you'd then only have a .BMP with each
individual cel at x=0.
And that's why we need macros and consistent naming: To express these
semantics, without having to duplicate the sprite declaration in some
other format. sSPARKS[8][8][8] wouldn't help anyone 😛
Now, we could go even further there by defining a separate type
(`preshifted_dots8_t`), and maybe get rid of the _W macro by replacing
it with a method on that type. However,
• that would be inconsistent, since we'll need the _H macro anyway, for
both the actual rendering code and the sprite compiler
• we couldn't directly call such a method on a 2D or 3D array, and have
to go down to a single element to do so (`sSPARKS[0][0][0].w()`)
• making it a static method instead duplicates the type all over the
code
• and any variables of that type would no longer be scalar-type values
that can be stored in registers, requiring weird workarounds in those
places. As we've already seen with subpixels.
Part of P0085, funded by -Tom-.
2020-03-25 14:22:51 +00:00
|
|
|
add si, offset _sSPARKS
|
2019-02-27 17:05:22 +00:00
|
|
|
and cx, 7 ; & (SPARK_SPRITES - 1)
|
|
|
|
shl cx, 4 ; * SPARK_SIZE
|
|
|
|
add si, cx
|
|
|
|
|
2020-04-13 11:55:52 +00:00
|
|
|
blit_dots16_empty2opt_emptyopt_roll <bx>, SPARK_H
|
2019-02-27 17:05:22 +00:00
|
|
|
|
|
|
|
@@ret:
|
|
|
|
pop di
|
|
|
|
pop si
|
|
|
|
retn
|
|
|
|
@spark_render endp
|
|
|
|
even
|