This function is responsible for generating random dungeons for Pastel
Chime Continue.
The dgn_generate_drawfield() function implements the main logic. This
algorithm constructs the dungeon through a multi-step process involving
room creation, recursive expansion, wall placement, treasure room
generation, and corridor pruning/extension.
AutoDungeonE_Create() calls this function to create a layout based on
specified parameters, and then populates arrays with the proposed
coordinates of items, enemies, and traps.
This implementation strives to faithfully reproduce the behavior of
DrawField.dll, including its bugs, although it has not been strictly
verified.
This HLL implements the core gameplay logic for the 3D dungeon
exploration mode.
Key features:
- Collision and Movement:
- Implements 2D collision detection for player movement against walls.
- Field_CalcMove() function calculates the desired position and
adjusts it to slide along walls upon collision.
- Party and AI Mechanics:
- Field_UpdatePlayersUnit() manages party movement, creating a smooth,
snake-like following behavior for up to two companions.
- Field_UpdateEnemyPos() provides basic enemy AI, enabling them to
chase the player when in line-of-sight and within range, or return
to a base position otherwise.
- Interactive Environment:
- Field_UpdateDoors() implements automatic doors that open and close
based on player proximity.
- Field_CheckObjectHit() detects when the player enters the hit-range
of an object, triggering events.
- 3D Space UI:
- Adds dungeon_project_world_to_screen() to translate 3D world
coordinates into 2D screen positions.
- Field_UpdateObjectNamePlate() and Field_UpdateDoorNamePlate() use
this projection to display and manage interactive nameplates for
objects and doors.
- Data Persistence:
- DungeonDataSave() and DungeonDataLoad() serializes and deserializes
the complete dungeon state to .DSD files.
- Integrates dungeon data with the main save system by copying .DSD
files to/from slot-specific .DSA files.
Note: The most complex function in this HLL, the dungeon generator
AutoDungeonE_Create(), is not implemented in this change.
DrawField is a variant of DrawDungeon. Unlike the first-person
perspective of DrawDungeon, DrawField uses a third-person, bird's-eye
view camera.
Key features include:
- Character Rendering: A new system to render up to 256 billboarded
sprites (characters, enemies, etc.) in the 3D world. The renderer
supports controlling position, sprite animation, and visibility for
each character.
- DrawField HLL API: Functions for loading assets, managing characters,
and manipulating dungeon properties like door locks.
- Renderer: The core renderer is updated to support the DrawField mode.
This includes disabling fog, handling sprite sheets via UV
manipulation, and rendering ceilings as billboards.
- Map: The 2D map has been updated to reflect the DrawField style,
including colored door lock indicators.
* dtx_load_from_dtl() loads lightmap textures.
* dgn_calc_lightmap() calculates lightmap texture index for each cell
based on the state of the surrounding walls.
Texture.dtl contains multiple sets of wall, floor, and ceiling texture
images. dtx_load_from_dtl() randomly selects a texture set using the
floor number as the random seed and returns it as a dtx structure.
In DrawDungeon2, dungeons are generated randomly using a dedicated
random number generator (mtrand43.c), which is a Mersenne Twister with
N=4, M=3.
The entry point for map generation is dgn_generate_drawdungeon2(),
which deterministically generates a floor map using the floor number as
the random seed.
I verified that generated floor layout, player starting position,
exit, and treasure chest locations match the original DrawDungeon2.dll
up to the 1000th floor.
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.
It is implemented as a post-processing effect. The hack for the
projection transform matrix has been removed, because now the image is
flipped upside down in the post-processing stage.
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.
* Cells loaded from walk-data are half-transparent.
* The player symbol is half-transparent when showing different floors.
* Clear the texture before drawing a small map so that no garbage is
left when the drawing is clipped.
Major differences from DrawDungeon.hll are:
- DGN, DTX, TES are loaded from individual files, not from a DLF archive
- 2D map functions are not used
- (unimplemented) Spinning motion of event markers
- (unimplemented) Additional 3D object types (polygon models and roofs)
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.
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.