Used for the treasure chest opening effect in Rance Quest.
Implemented using draw_plugin. The render() method of draw_plugin is no
longer dedicated to custom sprites, but can be used for any sprites to
override the default sprite rendering function.
It is called when the plugin is unbound from a sprite, or when the
sprite to which the plugin is bound is released.
This prevents memory leaks when sprites are destroyed without the plugin
being released, and simplifies lifetime management of the DrawDungeon
plugin.
Used in Tsuma Shibori, and some indie System 4 games.
This HLL is a draw plugin that uses SACT2's "custom sprite" mechanism.
Custom sprites do not have a texture. Instead, the plugin's render()
callback draws them directly to the main surface.
This adds a new parameter `blend` to `gfx_draw_glyph()`. When `blend` is
true, the function performs normal alpha blending (same as
`gfx_draw_glyph_to_pmap()`).
If `blend` is false, the resulting pixel color will be the text color
and the alpha value will be copied from the glyph texture. However, if
the alpha value is less than 0.01, the pixel will not be written.
If you are drawing on a transparent texture (which will later be blended
into another texture), `blend` should be false. If you are drawing on top
of an image, `blend` should be true.
`gfx_draw_glyph()` used to fill transparent pixels with text color, but
this step is no longer needed and has been removed.
Text sprites hold the height of the text drawn on them, and
sact_SP_TextNewLine increases the Y coordinate by this value if
nTextSize is 0.
The nTextSize argument of sact_SP_TextHome affects this value.
Beat Blades Haruka depends on this behavior.
So far only basic debugging functionality is implemented (breakpoints,
stepping, stack traces/variables).
This is not tested against an established DAP client. My intention is to
create a custom GUI frontend and extend the protocol to support
xsystem4-specific features, such as inspecting the scene. (This work is
underway.)
Instruction references are hex-encoded address strings. Clients do not
need to obtain them from DAP requests. This is outside the spec, but it
is needed for a binary-only debugger.
Functions that write directly to stdout (e.g. printf) should generally
not be used any more. Instead, use either sys_message (which respects
sys_silent) or log_message (which will send the message to the debugger
if DAP is enabled). stderr can be used as normal.
Most of the functionality of gfx_render_texture (draw method, blend
rate) is moved into sprite_render, since this was the only place using
it.
The draw method and blend rate are now stored in sact_sprite objects
instead of textures.
sact_sprite now has two renderers: the old SACT2 renderer (with blend
rate as the only shader parameter) and the new ChipmunkSpriteEngine
renderer, which supports multiply/add colors and the "surface area"
feature from PartsEngine.
Rance Quest now runs up to the first Flash-related function call
(Flash?!?!).
Plugins can implement this so that scene_print will print additional
information for the sprite. RE_plugin implements this to dump the 3D
scene information.
Add a scene_print function which prints a textual representation of the
current scene. This works by attaching a `debug_print` function to each
entity in the scene. This function is implemented for SACT2 and
GUIEngine entities. A default implementation will be used of none is
provided.
This can be accessed from the debugger via the `scene` command (although
the output is typically too much to view in a terminal; it's better to
run `scene_print` somewhere and redirect stdout to a file).
Add a mechanism for libraries to resolve incompatibilities between
library versions before linking.
This is currently used for ChipmunkSpriteEngine and GoatGUIEngine,
where early versions used integer IDs when loading CGs (later versions
use strings).
ReignEngine is the 3D rendering engine used in Toushin Toshi III, and is
the predecessor of the 3D engines for Rance Quest, Rance 9, Evenicle,
etc.
This implements minimal functionality to be able to draw the first 3D
dungeon scene. Many important parts such as motion and lighting are not
implemented yet.
This introduces draw_plugin struct that can be attached to a sprite.
The update() function of attached plugin is called every frame by
sact_Update(). This corresponds to the DrawPlugin mechanism of
System4/SACT2.
This is currently used only from DrawDungeon. The 3D engine for Toushin
Toshi 3 etc. will also use this.
This improves the look and (especially) the performance of text
rendering in the MangaGamer version of Sengoku Rance.
There are still some bugs/unimplemented features, but the game should be
more or less bearable to play in this state.
Use functions which expect UTF-8 encoded file names (and convert them to
UTF-16 on Windows).
This should fix various issues on Windows when reading/writing files
with Japanese characters in their names.
The method parameter of this function has a different meaning from that
of SACT2.SP_SetDrawMethod.
I've only checked it in Widenyo, but it seems 0 and 1 are valid values
and 1 is additive blending.
Create a separate interface for managing the scene. The sact_sprite
interface is implemented on top of this, as is GoatGUIEngine (which is
now independent of sact_sprite).
This will allow more specialized graphics interfaces to be implemented
without adding to the complexity of the sact_sprite interace. (For
example, GoatGUIEngine needs to store multiple textures per sprite for
button states; this is not supported by sact_sprite.)
Implement a new interface for managing archives. This is mainly to
support loading afa archives alongside ald archives.
Also included here is some code for creating an index for afa CG
archives (the numbers used to reference CGs in afa archives correspond
to the file name, not the position in the archive).
Create pixel-only textures as RGB (no alpha). This fixes some issues
with DrawGraph functions writing to an alpha channel that shouldn't
exist (e.g. causes black screen in Haru Urare).
This doesn't fix the analogous issue for CGs which shouldn't have an
alpha channel.
Ensure that sact_get_sprite always returns a sprite object if sprite
number is not negative. SACT2 functions in general should work before
pixel data is attached to a sprite.
This also fixes the default for the 'show' property (true) and changes
the logic for adding/removing sprites from the scene to be less
error-prone (checked whenever a sprite is dirtied).
Implement the SP_SetText* and MultiSprite_* functions added by
StoatSpriteEngine (as well as the TRANS_* functions introduced in
SACTDX). Enough to get to the opening movie in Vanish!
Split the code from sact_graphics.c into sprite.c and hll/SACT2.c.
sprite.c contains an index-independent sprite/scene interface, whereas
hll/SACT2.c handles the indexing of sprites.
This is to better support the StoatSpriteEngine.MultiSprite_* functions,
which use a different indexing system.
kichikuou