Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/platform/x86real/pc98/blitter.hpp

88 lines
2.4 KiB
C++
Raw Normal View History

[Platform] [PC-98] Generic byte-aligned sprite blitter The fact that every sprite format comes with its own blitter is one of the major sources of bloat in PC-98 Touhou, and of TH01 in particular. So how about writing a single decently optimized blitter, and calling into that from the entire game? Especially because generating distinct blitting functions for every width is a much better use of all that memory: It eliminates horizontal loops, and ensures that we use the optimal MOV variant for each sprite size. Removing any checks for empty bytes (which will turn out to never have been a good idea for any PC-98 model ever) and unrolling the main blitting loop using Duff's Device already gets us something that, depending on the PC-98 model, is easily 2-4× faster than the typical naive C implementation you'd find in TH01. With master.lib being not that faster… Making more use of C++ templates would have been fancy, but horizontal sprite clipping can change the blit width depending on runtime values. So, we're back to X macro code generation after all. Part of P0233, funded by [Anonymous].
2023-02-18 21:35:10 +00:00
/// Optimized byte-aligned sprite blitter
/// -------------------------------------
[Maintenance] #include each header's dependencies within the header itself OK, this is the big one. We still keep using `#include` guards only where we absolutely need to, but with each header now being valid in isolation, this can now actually help *minimize* the length of each translation unit's `#include` list. Turns out that after removing all the duplicates, we only *actually* need to guard 29 headers across all 5 games. Part of P0285, funded by [Anonymous] and iruleatgames.
2024-05-25 18:31:09 +00:00
#include "planar.h"
[Platform] [PC-98] Generic byte-aligned sprite blitter The fact that every sprite format comes with its own blitter is one of the major sources of bloat in PC-98 Touhou, and of TH01 in particular. So how about writing a single decently optimized blitter, and calling into that from the entire game? Especially because generating distinct blitting functions for every width is a much better use of all that memory: It eliminates horizontal loops, and ensures that we use the optimal MOV variant for each sprite size. Removing any checks for empty bytes (which will turn out to never have been a good idea for any PC-98 model ever) and unrolling the main blitting loop using Duff's Device already gets us something that, depending on the PC-98 model, is easily 2-4× faster than the typical naive C implementation you'd find in TH01. With master.lib being not that faster… Making more use of C++ templates would have been fancy, but horizontal sprite clipping can change the blit width depending on runtime values. So, we're back to X macro code generation after all. Part of P0233, funded by [Anonymous].
2023-02-18 21:35:10 +00:00
typedef void (* blit_func_t)(seg_t plane_seg, const void far* sprite);
struct Blitter {
blit_func_t write;
blit_func_t or;
};
// Internals
// ---------
[Research] Benchmark various sprite blitting approaches Running this on various PC-98 models confirms that unchecked blitting (i.e., what you would intuitively consider to be the best method) is in fact faster than checking either byte of a 16-pixel-wide sprite beforehand, and has been throughout the PC-98's lifespan. For optimal performance on the 286 and 386, we might want to use MOVS instead of MOV, but even that difference is way too small to truly matter. Also, nice to see turns out that our blitter outperforms a naive pure C implementation by 2-4×, depending on the model. And master.lib is not *that* much faster… The gaiji in `Research/blitperf.bmp` were taken from the Unifont version 15.0.01 glyphs for: • U+2022 BULLET • • U+23F1 STOPWATCH ⏱ • U+1F40C SNAIL 🐌 Part of P0233, funded by [Anonymous].
2023-02-19 19:38:11 +00:00
// Mainly here because BLITPERF needs access to them to implement custom
// blitters.
[Platform] [PC-98] Generic byte-aligned sprite blitter The fact that every sprite format comes with its own blitter is one of the major sources of bloat in PC-98 Touhou, and of TH01 in particular. So how about writing a single decently optimized blitter, and calling into that from the entire game? Especially because generating distinct blitting functions for every width is a much better use of all that memory: It eliminates horizontal loops, and ensures that we use the optimal MOV variant for each sprite size. Removing any checks for empty bytes (which will turn out to never have been a good idea for any PC-98 model ever) and unrolling the main blitting loop using Duff's Device already gets us something that, depending on the PC-98 model, is easily 2-4× faster than the typical naive C implementation you'd find in TH01. With master.lib being not that faster… Making more use of C++ templates would have been fancy, but horizontal sprite clipping can change the blit width depending on runtime values. So, we're back to X macro code generation after all. Part of P0233, funded by [Anonymous].
2023-02-18 21:35:10 +00:00
static const upixel_t UNROLL_H = 8;
struct blit_state_t {
vram_offset_t vo;
// First blitted byte within the sprite. Can be nonzero if the sprite was
// clipped at the left or top edge of VRAM.
uint16_t sprite_offset;
// Always set to the original width of the sprite. Can be larger than the
// blitted width if the sprite is clipped.
vram_byte_amount_t sprite_w;
// 16-bit because it gets loaded into BX anyway.
pixel_t loops_remainder;
int16_t loops_unrolled;
};
extern blit_state_t blit_state;
#define blitter_body(plane_seg, sprite, func_row, row_p1, row_p2) { \
register int16_t loops_unrolled = blit_state.loops_unrolled; \
_SI = FP_OFF(sprite); \
_SI += blit_state.sprite_offset; \
_DI = blit_state.vo; \
_DX = blit_state.sprite_w; \
_BX = blit_state.loops_remainder; \
\
/* Turbo C++ 4.0J does not back up DS if the function mutates it. */ \
/* [blit_state] can't be accessed anymore beyond this point! */ \
_asm { push ds; } \
_DS = FP_SEG(sprite); \
_ES = plane_seg; \
\
static_assert(UNROLL_H == 8); \
switch(_BX) { \
case 0: do { func_row(row_p1, row_p2) \
case 7: func_row(row_p1, row_p2) \
case 6: func_row(row_p1, row_p2) \
case 5: func_row(row_p1, row_p2) \
case 4: func_row(row_p1, row_p2) \
case 3: func_row(row_p1, row_p2) \
case 2: func_row(row_p1, row_p2) \
case 1: func_row(row_p1, row_p2) \
/* */} while(--loops_unrolled > 0); \
} \
\
_asm { pop ds; } \
}
// ---------
// Initialization
// --------------
// All of these set up blitting of a ([w]*8)×[h]-pixel sprite at the given VRAM
// offset, cutting it at the respectively checked VRAM boundaries and assuming
// that it does not touch the others. If the sprite would be cut to a width or
// height of 0, they return a `nullptr` and leave the blitter in an invalid
// state.
// Checks all 4 edges of VRAM.
const Blitter __ds* blitter_init_clip_lrtb(
vram_x_t left, vram_y_t top, vram_byte_amount_t w, pixel_t h
);
[Maintenance] Fix another bunch of accumulated typos and dead code Part of P0239, funded by Ember2528.
2023-04-17 01:53:29 +00:00
// Checks the bottom edge of VRAM.
[Platform] [PC-98] Generic byte-aligned sprite blitter The fact that every sprite format comes with its own blitter is one of the major sources of bloat in PC-98 Touhou, and of TH01 in particular. So how about writing a single decently optimized blitter, and calling into that from the entire game? Especially because generating distinct blitting functions for every width is a much better use of all that memory: It eliminates horizontal loops, and ensures that we use the optimal MOV variant for each sprite size. Removing any checks for empty bytes (which will turn out to never have been a good idea for any PC-98 model ever) and unrolling the main blitting loop using Duff's Device already gets us something that, depending on the PC-98 model, is easily 2-4× faster than the typical naive C implementation you'd find in TH01. With master.lib being not that faster… Making more use of C++ templates would have been fancy, but horizontal sprite clipping can change the blit width depending on runtime values. So, we're back to X macro code generation after all. Part of P0233, funded by [Anonymous].
2023-02-18 21:35:10 +00:00
const Blitter __ds* blitter_init_clip_b(
vram_x_t left, vram_y_t top, vram_byte_amount_t w, pixel_t h
);
// --------------