Some changes in the
SPReD/SPD.
SPReD:
- data export: changed exported ASM format, +now the names of pointers to sprites without '_frame' postfix (extern spd_SPRITE* <sprite_name>)
SPD v0.6:
- added 'General information' section
- added 'spd_SATB_to_VRAM()' and 'spd_SATB_to_VRAM( _spr_cnt )' functions
- optimized 'spd_SATB_clear_from( _pos )'
- added 'spd_SATB_set_sprite_LT' for simple sprites, it takes a less processing time compared to 'spd_SATB_push_sprite' and allows you to use sprite offset values unlike HuC sprite functions
- added functions for simple sprites:
spd_set_palette_LT( ind ),
spd_get_palette_LT(),
spd_set_pri_LT( SPD_SPR_PRI_HIGH/SPD_SPR_PRI_LOW ),
spd_set_x_LT( X ),
spd_get_x_LT(),
spd_set_y_LT( Y ),
spd_get_y_LT(),
spd_show_LT(),
spd_hide_LT()
- added a little note about using the 'SPD_DEBUG' flag
- added cyan border color as attributes transformation indicator
- added 'SPD_SG_BANK_INIT_VAL' as initial value for the '_last_bank_ind' in 'spd_sprite_params(...)'
- the double-buffer index in 'spd_get_dbl_buff_ind()' and the second argument in 'spd_dbl_buff_VRAM_addr(...)' changed to a byte value
- the type of the second argument for 'spd_copy_SG_data_to_VRAM(...)' and 'spd_SG_data_params(...)' has changed, now '_src_bank' is a byte and therefore a pointer to a byte
- updated samples
Re-export all your projects to work with the new library version.General information:~~~~~~~~~~~~~~~
1. The library works with both simple sprites and meta-sprites.
The only difference is the use of the following functions: '
spd_SATB_push_sprite' for meta-sprites and '
spd_SATB_set_sprite_LT' for simple sprites.
'
spd_SATB_set_sprite_LT' - optimized to work with simple sprites. It supports sprite offset values, but does not support double-buffering and doesn't increment SATB position, unlike '
spd_SATB_push_sprite'.
2. The
SPReD-PCE exports both meta-sprites and simple sprites (
16x16,16x32,16x64,32x16,32x32,32x64).
The
CGX/CGY flags are automatically applied to exported sprites. So you don't need to configure anything in your HuC program.
3. The library supports an arbitrary number of sprite sets, which are switched between using the '
spd_sprite_params' function.
4. Double-buffering is supported for meta-sprites. This requires 2x video memory for SG data, but ensures that there are no glitches when synchronizing SG and VRAM inner SATB.
Compare both meta-sprites with and without double-buffering and decide which one is better in your case. As a rule, double-buffering helps when meta-sprites are at the top of the screen.
But it also depends on the amount of SG data is being loaded to VRAM.
[upd]5. Supports changing the color palette for meta-sprites. Use '
spd_change_palette' right after '
spd_SATB_push_sprite'.
[upd]6. Simple or meta-sprite graphics can be loaded to any VRAM address. Use 'spd_alt_VRAM_addr' right after 'spd_sprite_params' and before '
spd_copy_SG_data_to_VRAM', '
spd_SATB_push_sprite' and '
spd_SATB_set_sprite_LT'.
7. There are two ways to load SG data to VRAM:
- automatically, when calling '
spd_SATB_push_sprite' or '
spd_SATB_set_sprite_LT';
- manually with '
spd_copy_SG_data_to_VRAM' for graphics caching before further use, as a rule for simple sprites, or to load a meta-sprite graphics without double-buffering after VBLANK/vsync();
Keep this in mind when planning the logic of your program.
8. The library can be used in combination with HuC sprite functions. This makes it much easier to initialize data for HuC sprites.
You can also use similar SPD library functions:
(!) Functions with the '
_LT' postfix are designed to work with simple sprites.
spr_set( N )
->
spd_SATB_set_pos( N )
spr_pal( _plt_ind )
->
spd_set_palette_LT( _plt_ind )
spr_get_pal()
->
spd_get_palette_LT()
spr_pri( val )
->
spd_set_pri_LT(
SPD_SPR_PRI_HIGH/
SPD_SPR_PRI_LOW )
spr_x( _x )
->
spd_set_x_LT( _x ) -
doesn't support sprite offset value spr_get_x()
->
spd_get_x_LT()
spr_y( _y )
->
spd_set_y_LT( _y ) -
doesn't support sprite offset value spr_get_y()
->
spd_get_y_LT()
spr_show()
->
spd_show_LT()
spr_hide()
->
spd_hide_LT()
There are also following optimized similar functions:
init_satb()/
reset_satb() ->
spd_SATB_clear_from( N )
satb_update()
->
spd_SATB_to_VRAM()
9. Performance. Starting with the fastest function:
[upd] Direct writing to SATB using: 'spd_set_palette_LT', 'spd_set_pri_LT', 'spd_set_x_LT', 'spd_set_y_LT' etc. or HuC functions.
spd_SATB_set_sprite_LT( <sprite_name>, X, Y )
spd_SATB_set_sprite_LT( <exported_name>_frames_arr, spr_ind, X, Y )
spd_SATB_push_sprite( <sprite_name>, X, Y )
spd_SATB_push_sprite( <exported_name>_frames_arr, spr_ind, X, Y )
Use the following functions, if you don't use animations:
spd_SATB_set_sprite_LT( <sprite_name>, X, Y )
spd_SATB_push_sprite( <sprite_name>, X, Y )
This will work faster, than functions that use sprite indexing:
spd_SATB_set_sprite_LT( <exported_name>_frames_arr, spr_ind, X, Y )
spd_SATB_push_sprite( <exported_name>_frames_arr, spr_ind, X, Y )
The sprite indexing is designed specifically to make working with animations easier. So use these functions only for animated sprites.
10. Use '
SPD_DEBUG' to keep track of how efficiently/frequently SG data is loaded to VRAM.
You can read the rest of the changes
here.
As usual, all the changes in the dev build.
Perhaps it's a matter of time.
Because it messes up sprite graphics that is legally stored there.
