Skip to content

Detailed Specifications

Jump to bottom
TheLX5 edited this page Dec 3, 2020 · 3 revisions

Here you can find specifications about several things of the VWF system itself.

WIP SECTION!!!!

RAM Usage

Since the level isn't being used nor rendered, using the reserved RAM for level data is fair play. This system makes use of it to store several things.

WIP

HDMA Details

The system makes use of 3 HDMA channels for various purposes.

Channel Destination Source Description
3 $2100 !VWF_HDMA Handles fade in/out in the whole screen
4 $2111 !VWF_SCROLL Handles text scrolling.
5 $2109 ROM Shifts up the BG3 tilemap to properly show the current topic.

WIP

Custom game loop

VWF Cutscene Tool completely overrides the original game loop in order to show up text.

  • While the system comes in a sprite form, once the "level" fully loads, any other sprite becomes unoperative since the SNES CPU will be busy running a new game loop.
  • The game is unable to run UberASM codes (except for NMI's hijack), so you can't really affect the system by injecting code outside it.
  • There are a lot of unused cycles due to this running its own game loop, which they could be used for something else, like custom ASM scripts (which are detailed below)

VWF Text

The text displayed on the screen has some special specifications that can be followed in order to create custom fonts.

  • The maximum allowed character size is 16*12 pixels
  • The characters must be 1bpp
  • You can't have more than 128 different characters per font
  • The if the width of a character is over 8 pixels, you need to separate the other 8 pixels in another tile, which is 0x400 bytes away from the current tile.
  • The character's width must be specified in a separate file/table

WIP

ASM Code execution

Version 2.0 adds a way to execute ASM routines, be it once or every frame. Such feature is super useful and you must know what specifications and limitations it has:

  • It must return in a RTL
  • You're allowed to write anything that asar and PIXI accepts, the script will not touch your ASM code and you're 100% responsible of what you write
  • The data bank is set to $7E ($40 on SA-1 ROMs)
  • A is set to 8-bit, XY are set to 16-bit
  • Data bank, Y, Direct Page and Processor Status are preserved prior executing the custom code
  • If your code runs every frame, it will be executed before AddMusicK code, ExAnimation handler and Mario pose handler

SA-1 Support

Support for Vitor Vilela's SA-1 Pack is here, but not in the way you'd expect it. Since the sprite's code run on SA-1 and most of the code in the game loop are registers, the code is forced to run on SNES side at all times. There's no performance gains in making it run on SA-1 since there's not much happening on screen. It'd also make the code way more complex to get some things to run on SA-1 side.

Clone this wiki locally