It provides 64-bit calculation functions with virtual registers.
While the original CalcTable.dll accumulates instructions and executes
them with CalcTable.Run(), this implementation performs calculations on
the fly. This simplification is possible because Run() is only called
with loop=1.
This adds source-level debugging capabilities to the command-line
debugger, utilizing debug information generated by sys4dc. The debug
information format is documented at:
https://github.com/kichikuou/sys4dc/blob/master/docs/debug_info.md
The location of the debug information file can be specified with the
`--debug-info` command-line flag. If not specified, xsystem4 will
attempt to load it from `gamedir_path("src/debug_info.json")`.
When debug information is available, a breakpoint can be set at a
specific line in a file using `breakpoint <file> <line>`. Also, `step`
and `next` commands advance execution to the next source line (this is
naively implemented by repeating instruction-level stepping).
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 is used for collision detection between a map object and the player
character. The current implementation is very simple, only performing
AABB intersection tests, but it is enough to allow the player to walk
around the first dungeon in Rance Quest.
Use `git describe` instead of `git rev-parse` for the version number,
since this command will report the latest tagged version in addition to
the current commit.
DALKDemo is responsible not only for the opening demo but also for the
UI of the title menu. This change fully implements DALKDemo. DALKEDemo
is stubbed out.
== Handles
As a general pattern, these libraries have an interface based on integer
handles allocated by Open() and released by Close(); in the AliceSoft's
implementation, handles are pointers to internal objects. Note that:
* 0 is used to represent an invalid handle, and
* Small numbers cannot be handles. For example, Mamanyonyo has code that
treats an integer as a CG number if it is less than 10000, and as a
surface handle otherwise.
In this patch, handles are generated using id_pool.h functions. In order
to achieve the above, the interface is extended so that the minimum ID
value can be specified (the `base` parameter of id_pool_init()).
== Graphics System
Surface objects (implemented in vmSurface.[ch]) plays a central role in
Mamanyonyo's graphics system, and the sprite system (vmSprite.c) is
implemented on top of it. vmSprite.c uses scene.h functions.
== vmChrLoader and vmMapLoader
Since Mamanyonyo's character data format is the same as Widenyo's,
the ChrLoader code has been refactored and used from vmChrLoader.c.
On the other hand, MapLoader and vmMapLoader do not share code because
the map file format is different from Widenyo.
It is used (only?) in Beat Blades Haruka, when two enemies are found by
enemy seek.
This is just a screen effect and can be ignored without affecting
gameplay.
This SWF parser is far from complete, in particular it only supports
simple bitmap-filled rectangular shapes, but it covers all the features
used in Daiteikoku, Rance Quest, Pastel Chime 3 and Dorapeko.
Flash files are stored in archives in AFF format, which is an encrypted
SWF wrapper. The decryption code was adapted from GARbro.
xsystem4.scene: returns a list of scene entities
* all entities have an entityId that can be used in further requests
* SACT2 sprites have a 'sprite' member with a spriteId that can be
used in further requests
xsystem4.renderEntity: renders a scene entity and returns the texture
xsystem4.spriteTexture: returns the stored SACT2 sprite texture
xsystem4.renderParts: renders a parts object and returns the texture
xsystem4.partsTexture: returns the stored parts object texture
Image data in texture objects is RGB8888 encoded in base 64.
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.
The format should not be considered stable at this point, as PartsEngine
support is still experimental and subject to change. But it's useful to
have these functions for testing purposes.
The game currently runs up until the first unimplemented function
(SeekEndMotion) during the intro events, using the existing PE_
functions with a few minor fixes.
This allows playback of videos in encodings other than MPEG-1, e.g. VC-1
used in the English version of Rance VI.
The FFmpeg dependency is optional. If it's not available, the PL_MPEG
backend will be used.
Try to link statically as much as possible on Windows, to reduce the
number of DLLs that have to be shipped with Windows builds.
Also document the build process on Windows.
These HLLs play .mpg movie files (later games use .alm file extension,
but the format is the same, i.e. MPEG-PS) that contain MPEG1 video and
MP2 audio streams.
pl_mpeg.h is the PL_MPEG library (https://github.com/phoboslab/pl_mpeg)
imported from commit 5aeef4d07593be1960a0e4c7fe204809cfae30bd.
This adds a few mixer functions (mixer_stream_*) for playing custom
audio streams under the master mixer.
This implements a parser for particle effect definition files (.pae)
and a set of field accessor functions for the RE_ITYPE_PARTICLE_EFFECT
instance type. Rendering of effects is not yet implemented.
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).
There are now two types of asset management:
1. ID-indexed assets, where IDs are not necessarily sequential
2. name-indexed assets
Name-indexed assets can have additional archives added at run-time. This
is to support the CGManager.LoadArchive function used in Rance Quest
Magnum.
Name-indexed assets always use .afa archives. ID-indexed assets mostly
use .ald archives, except for Daiteikoku and Shaman's Sanctuary.
asset_get_by_name is now case insensitive and ignores the file
extension.
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.
SDL_ttf isn't really designed to be used with OpenGL. It caches glyph
bitmaps in memory, whereas we want to cache glyph textures on the GPU.
By using FreeType directly we avoid creating and destroying a new
texture every time a glyph is rendered.
Additionally, all glyph textures (including fnl-derived glyphs) now use
the GL_RED internal format instead of GL_RGBA.
The MangaGamer version of Rance 02 has a custom proportional font
implementation which makes assumptions about the font in use. This is
worked around by rewriting their '_CalculateWidth' function to use
fixed-width logic.
I also tried using TTF_SizeUTF8 to get the proper character width but I
found this made the text overflow even worse than using a fixed width
(at least with the default gothic font, perhaps other fonts would fare
better).
Add a new debugger interface using a simple command language. This is
less powerful than the scheme interface (which still exists) but more
ergonomic for interactive debugging.
This debugger has no external dependencies (it will however use readline
if available) and is included in builds by default.
A sample interaction might look like:
xsystem4 --debug /path/to/game
dbg(cmd)> breakpoint bar
Set breakpoint at function 'bar' (0x00001234)
dbg(cmd)> continue
Hit breakpoint at function 'bar' (0x00001234)
dbg(cmd)> backtrace
#0 0x00001234 in bar
#1 0x00002222 in foo
#2 0x00004444 in main
dbg(cmd)> locals
[0] i: 2
[1] s: "baz"
dbg(cmd)> locals 1
[0] j: 3
[1] obj: { m_i = 0; m_s = "" }
dbg(cmd)> quit
kichikuou