Skip to content

Minimal world engine for old computers. Scriptable NPCs, growable crops, editable maps, in glorious CGA (or VGA).

License

Notifications You must be signed in to change notification settings

indigoparadox/dsekai

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

dsekai

Code Grade

Overworld Screenshot

dsekai is an extremely minimal world engine, intended to run on very old hardware. It is originally targeted to the 8086/8088 CPU with the intention to make it more portable later. See below for a list of supported platforms.

This project is being built around/in tandem with the unilayer project, in order to create a somewhat-universal framework/library for games on legacy/weird platforms.

There are also some rough examples of CGA graphics programming in unilayer/graphics/dosg.c, if that's what you're into.

Roadmap

Features that are planned include:

  • ASN.1 save dumps.
  • Housing system based on in-game map editing.
  • Item usage and crafting.
  • Minimal resource use (shooting for <500k RAM).
  • Multi-height raycasting POV support.
  • Compile script source files as part of JSON loading.

Linking and Compiling Considerations

Ideally, this engine will compile with legacy compilers as a general rule. For this reason, the following rules/limitations should be observed within the codebase:

  • C should be limited to C89/ANSI C in general. No C99 features should be used. In some cases, not all ANSI features should be used.
  • Except within platform-specific modules that can definitely handle it, dynamic allocation should also be avoided.
  • Except within platform-specific modules that can definitely use them, external dependencies should be avoided.

In general, these restrictions are relaxed for items in the tools/ and check/ subdirectories (though these should also be limited to C89). For this reason, items in the src/ directory should also avoid depending on items in the tools/ and check/ directories (except for in platform-specific modules that do not have these restrictions that may use the tools/ subdirectory. Nothing should depend on the check/ subdirectory).

Items in the tools/ and check/ subdirectories may depend on the src/ directory freely.

API Coding Considerations

In an attempt to keep the API consistent, functions should adhere to the following rules:

  • Arguments should be in order of state modifiers first, followed by a pointer to the object being modified if no global state is modified or a pointer to the global state struct which should be auto-unlocked before it is accessed with engines_state_unlock().

Documentation

Some attempt has been made at documentation with doxygen. Simply run doxygen in the project root in order to generate HTML documentation under doc/.

This documentation is also available at https://indigoparadox.github.io/dsekai/.

This is a work in progress.

Building

Currently, this project uses GNU make to (cross-)build on a GNU/Linux system. Compilers and tools required depend on the desired platforms to build for.

For MS-DOS, the INCLUDE environment variable must be set to the location of the OpenWatcom header files (e.g. /opt/watcom/h).

The script pkgs.sh in the root directory should build the recommended set of packages if the proper compilers are installed.

Datafiles

This engine should be capable of retrieving assets (levels, graphics, etc) from different locations, depending on how it was built (e.g. ASN.1 vs JSON maps support). Aside from loading directly from the filesystem, it should be able to use OS-level resources embedded in the binary. On platforms without this facility, a rough approximation of this is emulated using object embedding.

Platforms

The following platforms are currently supported:

  • MS-DOS w/ CGA Graphics (Maybe VGA graphics in the future...)
  • GNU/Linux with SDL (May work with other POSIX platforms.)
  • Windows (16-bit/32-bit)
  • WebASM

The following platforms are mostly functional, but still a little wonky:

  • PalmOS >= 3.5
  • GNU/Linux with Xlib (May work with other POSIX platforms.)
  • GNU/Linux with NCurses (May work with other POSIX platforms.)
  • Nintendo DS

The following platforms are planned to be supported but not yet functional:

  • Mac-OS 6/7
Platform Make Target Requirements
+MS-DOS bin/dsekai.exe OpenWatcom
SDL bin/dsekai SDL2
Xlib bin/dsekaix Xlib
PalmOS bin/dsekai.prc PRCTools
+Win16 bin/dsekai16.exe OpenWatcom
Win32 bin/dsekai32.exe OpenWatcom
MacOS 7 bin/dsekai16.dsk Retro68
NDS bin/dsekai.nds DevKitPro
WebASM bin/dsekai.js emscripten
Curses bin/dsekait NCurses
    • Platforms marked with + do not support JSON tilemaps directly.

Just using "make" will attempt to build all currently working targets with OS-level resources and statically compiled maps.

Platform-Specific Notes

MS-DOS

dsekai is being written to support MS-DOS in real mode on an 8086. This means that it only uses conventional memory. This leads to some technical considerations:

  • dsekai uses overlays to page unused engines to disk during execution. The engine .ovl files must be kept with the dsekai.exe file for it to work properly! Please see the Makefile.dos for more information.

Mechanics

Items

Items are defined in each tilemap in an array. Through scripts, items can be coped from the item definition array into the player's inventory where they can then be used even if the player is on a different tilemap.

Crops

Crops are also defined in each tilemap in an array. However, seeds in the player's inventory only reference the crop GID. This means that crops can only grow on a tilemap in which they are defined. This also means that crop GIDs MUST NOT collide between tilemaps.

Crops

Modding

Mapping

Maps are stored as JSON files in the format used by the Tiled map editor.

Please see map_field.json in the assets directory for an example.

The following special considerations should be observed for the dsekai engine:

  • Scripts are loaded from the map file according to the rules in that section.
  • NPC (or "mobile") spawns are stored in an objects layer called "objects". The engine selects the NPC sprite based on its name and its script based on a custom property called "script".
  • The static layer of the map is loaded from a layer called "terrain".

Skinning

TBA

Scripting

Information on scripting including detailed instruction reference has been moved into the documentation.

For the time being, the script compiler can be compiled by using make bin/compile, and then running bin/compile <path-to-script.s> to generate bytecode output that can be pasted into tilemaps.

See assets/m\_field for some example scripts.

Tools

Included in the tools/ subdirectory are a few tools required for preprocessing and compiling. These include tools for preprocessing resources from easier-to-edit formats to more compact formats for resource-limited platforms, as well as tools for packing up resources as part of compilation.

mkresh

Creates header files with resource listings to be included as OS-level resources.

convert

Converts between various image formats common to resource-limited platforms.

Usage

./bin/convert [options] -ic <in_fmt> -oc <out_fmt> -if <in_file> -of <out_file>

Options:

  • -ic [In format extension from Input Formats table.]
  • -oc [Out format extension from Output Formats table.]

CGA options:

These options only apply to raw CGA files:

  • -ib [in bpp] (defaults to 2)
  • -ob [out bpp] (defaults to input bpp)
  • -iw [in width] (requried for CGA in)
  • -ih [in height] (required for CGA in)
  • -il [in line padding] (full-screen uses 192)
  • -ol [out line padding]

Input Formats

Type Extension
Windows Bitmap bmp
Mac Icon icns
CGA Memory Dump cga

Output Formats

Type Extension
Windows Bitmap bmp
Mac Icon icns
CGA Memory Dump cga

map2asn

Converts maps from JSON to a more compact ASN.1 representation for use with resource-limited platforms.

Usage: map2asn <JSON tilemap input path> <ASN.1 tilemap output path>

headpack

Packs resources into #include-able header files to be inserted directly into the final binary.

Usage: headpack <header path> <paths to files to encode>

About

Minimal world engine for old computers. Scriptable NPCs, growable crops, editable maps, in glorious CGA (or VGA).

Topics

Resources

License

Stars

Watchers

Forks