Before this, all objects that share a texture were drawn at once.
Objects were not depth-sorted, so if a transparent object was drawn
first, objects behind it were not drawn.
After this, dungeon is drawn for each cell, sorted by distance from
the camera position. To reduce the number of cells to be drawn, PVS
(Potentially Visible Set) stored in dgn files is used.
This fixes Rance VI which passes SACT2.SP_SaveCG and
SACT2.SP_SetCGFromFile absolute paths like
`system.GetSaveFolderName() + "\\" + "ScreenA.qnt"`.
Also, now savedir_path() uses unix_path() rather than sjis2utf().
Implement a system for allocating anonymous channels so that libraries
can play sounds without having to manage channels.
A library that uses audio_play_sound must ensure that audio_update is
called periodically to garbage collect finished channels.
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).
Used in Shaman's Sanctuary. Mostly identical to StoatSpriteEngine, but
with a few additions and some removed functions (notably, the
MultiSprite functions were removed).
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.
This is a serialization interface for a particular struct type. I've
implemented it somewhat generically, only checking that the name of the
struct matches the expected type. The actual structure of the objects
passed in is not checked, and in fact this structure differs between
games.
The serialized data produced by ADVSceneKeeper.Save should be identical
to what's produced by AnteaterADVEngine.dll from Shaman's Sanctuary.
In addition to DrawDungeon.c, this adds the following files in
{src,include}/dungeon/:
- dgn.{h,c}: Parser for .dgn (map data)
- dtx.{h,c}: Parser for .dtx (textures)
- tes.{h,c}: Parser for .tes (sound IDs associated with textures)
- dungeon.{h,c}: Renderer main routines
- mesh.{h,c}: Renderer for walls and stairs
- skybox.{h,c}: Renderer for background cubemap
- event_markers.{h,c}: Renderer for event markers
And the following changes are made to the existing graphics code:
- sact_Update() calls dungeon_update(), so that event markers animate
- gfx_render_texture() renders vertically flipped image when
texture.flip_y == true (see the comment in dungeon_context_create())
Some features are not implemented yet, including 2D maps and door
animation.
This makes cglm a dependency.
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.
ref types are currently passed to HLL functions as pointers into the
heap. If the HLL function itself needs to allocate memory from the heap,
it can cause the heap to be reallocated, rendering these heap pointers
invalid.
In order to work around this, hll_call now guarantees 64 slots are
available on the heap before calling any HLL function. This is not a
great solution, but it should work to the extent that HLL functions only
allocate a fixed number of heap slots < 64.
This bug could be easily triggered by scrolling up on the message log in
Sengoku Rance.
kichikuou