NinForge Demo Release - Introduction to NinForge
================================================

What is NinForge?
-----------------

NinForge itself is kinda difficult to categorize. Its a kind of file system that
makes up a NES development project. Instead of ASM files with all kinds of files included
to them, NinForge projects uses some obligatory files, along with resource files, and the
common library.
Programming is written in ASM (with tons of macros that can be used), but depending on how
in the project you place it, its used for different purposes. The files in NF projects uses
a format similiar to each other, editable in whatever text editor.
Ive released the NFCompiler mostly to show off the concept. The plans is to make NFDesign,
wich will be the tool for developing and designing NF projects. The idea isnt that you go
make your project with notepad, unless ofcourse you love that stuff :)
The NFDesign program will give use of the NinForge system a meaning.
Included with the pack is a "Hello World!" demonstration (in samples\hw).
I might release more sample projects later.

What is the NFCompiler?
-----------------------

It is the program that reads all the files in a NinForge project, and based on that,
creates pure ASM wich then can be compiled to a NES binary. CC65 is the only compitable
assembler. (version 2.10.0 is probably the only version that works also)

Common Library
--------------

The common library is included to every NinForge project. It deals with startup, the loop of
the program, NMI, and IRQ. It contains numerous routines (that can be called using Macros),
as well as other Macros. Its also designed so includable libraries can be integrated several places
in the program-structure. In a way the common library is the game engine.

Includable Libraries
--------------------

These can be included in a project to add features with your project without coding them yourself.
Currently theres a Graphics library, Joypad library, and a Random Generator library.
The Graphics library you must include in any NF project if you wanna use graphical Resource file data to write to VRAM (graphics memory). For example, if you have designed a Palette resource
named "mypal", on a line you can write "palwrite_source pal_mypal" and it will use a routine in
the grapics library to write the palette to the VRAM next Vblank. And so on.
Anyway, libraries are highly configurable. Their memory use is fixed on its on, no need to
bother with that.

Resource Files
--------------

Resource files are placed in a \resource sub-folder of your project, with the extension .res
A .res file can contain multiple components with all types of resources.
(See docs\files.txt for file format)

The different types of Resource data:

	Processes

		These are pieces of code specially designed for multi-tasking in the program's run. Once a
		process are loaded to memory (done by Stadiums or from other code), they are continously
		called. After the process returns by RTS, it doesnt take much time before it is called
		at its start-adress again. (Other processes are called meantime, and NMI if Vblank
		are triggered). Processes has reserved memory for values that must be remembered between
		calls. Also, each process is granted a frame-counter automatically incerased each frame.
		The start-adress of a process (where it starts next time called) can be changed in memory.
		There's plenty of functions within the common library that can be used to deal with
		processes.

	Stadiums

		While processes are continously called, Stadiums are called once. Their purpose
		is to serve as entry and exit-points of a sequence in the NES game/program. For example,
		you may want a stadium for initializing and drawing a level. Another part of Stadiums is
		script-like data that tells to load/unload processes in memory. You can unload
		all processes with a special command. A Stadium can be triggered anywhere in your
		program with a simple command. A NFP project has to start up with a stadium, wich one
		is defined in a configuration file.

	Routines

		Routines arent specially-designed for anything, they are more like placeholders for
		well.. your own routines. You might not want these mixed with Process or Stadium
		data, wich is possible, but very messy.

	String Blocks

		These are blocks of data, intended for lines of text. A string blocks can contain
		several of these lines. Each line has three parts of data: Vertical tile placement,
		Horizontal tile placement, and Text.

	Constructions

		These are a kind of strings, just that they are meant for graphical tiles, and not
		letters. A construction can contain multiple "lines" to be drawn on the screen. Briefly,
		these have a Y and X coordinate, length, and can be drawn Horizontal or Vertical. There
		are more properties on the lines, covered in the "docs\files.txt" doc. Constructions are
		perfect for message windows, etc.

	Palettes

		I guess this is pretty self-explanary :) Anyway, palette datas can be quite large. You
		can load a defined amount of colors, from a defined place in the resource data, to
		a defined place in the PPU palette, so to say.

	Raw Data

		Raw hex. Meant as an alternative to ".byte $40,$20", etc. typing. In NFDesign, making
		these chunks of hex will probably going to be very effective.

Further Documentation
---------------------

The \docs folder contains documentation with
the following content:

files.txt - Contains detailed format description of every file in a NF project.
prog.txt - A smal guide in developing a NF project.
graphics.txt - A guide on how to use the Graphics library
               and Resources to draw graphics to VRAM (video RAM)
routines.txt - Contains information on Macros that can be used in programming.