======================================
MT Engine MK2 v 0.89 (Nicanor Edition)
======================================

This version corresponds to the game "Nicanor the Profaner". Includes one
New version of msc3, 3.92

-----------------------------
Easier Scripting with Alias
-----------------------------

As of version 3.92 of msc3, you can skip the FLAG word if you use
alias. That is, the compiler will accept

SET $ KEY = 1

and also

IF $ KEY = 1

---------
Safe Spot
---------

If you define #define DIE_AND_RESPAWN in config.h, the player, upon dying, goes to
Reappear in the "last safe point". If DIE_AND_RESPAWN is active, the
Engine saves the position (screen, x, y) each time we
Tile nontransferable (other than a floating object).

We can control the definition of the "safe spot" from our
Script. If we decide to do this (for example, to define a "checkpoint"
Manually), it is convenient to deactivate that the motor stores the safe
Spot automatically with:

#define DISABLE_AUTO_SAFE_SPOT

Whether or not we do this, we can define the safe spot from the script with
These two commands:

SET SAFE HERE			Sets the "safe spot" to the current position of the
player.
						
SET SAFE n, x, y		Sets the "safe spot" to screen n in the Coordinates (of tile) (x, y).

=====================
MT Engine MK2 v 0.88c
=====================

EYE: As of this version the classic module of handling of enemies
(#define USE_OLD_ENEMS) will no longer be supported and will no longer be supported.
It will still be there, but it is likely that there are many things that
Ing. It should not be used.

TODO: Write an application that changes a format .ene file
Old to the new format, in case you want to do some other rehash of
An old game of the Churrera.

This release integrates some improvements in scripting, such as strings
Of decorations (see below) or the sword of Sir Ababol as a type of
HITTER.

There is no game with this, but the Espadewr demo.

------------
Decoration
------------

Basically is to do the engine / extraprints.h but from the script.
Until now we decorated the screens with extra tiles putting strings
Of SET TILE (x, y) = t. That's a pain in writing and maintaining and
Also occupied 4 bytes per tile.

Now we can define tiles of tiles in which the whole set of
Tiles will occupy 2 * n + 2, where n is the number of tiles. A good improvement
Compared to the original, which occupied 4 * n bytes.

The theme is like this: just enter this in the ENTERING_SCREEN (or in
Any site that supports commands: this serves to change good
Bits of the screen from the script and can come great to implement
Puzzles that modify the stage:

IF TRUE
THEN
	DECORATIONS
		x, y, t
		x, y, t
		...
	END
END

Each line x, y, t defines the position and the number of an extra tile of
decor. You can put all that you want.

This serves to save a lot of memory and have well-decorated screens.
Generally, you do NOT need the 48 tiles of a tileset extended to the
time. There is always a group of tiles that repeats more. The idea is
Set that tileset as the main tileset (0-15) and place the tileset
Others as decorations.

In addition, the new map2bin is responsible for automatically detecting and
Generate the necessary script lines.

-----------------------
REENTER, REDRAW, REHASH
-----------------------

REDRAW has been redesigned to work better and faster. Redraw
Again the screen from the buffer, and this includes everything we have
Placed before with SET TILE (x, y) = t.

REHASH re-enters the screen to, among other things, initialize
the enemies. It is necessary if an enemy is changed from linear type to type Flying, since you have to initialize some variables.

REENTER, as always: it's REDRAW + REHASH.

-------------------------------------
Change enemies and backup enemies
-------------------------------------

In addition to turning them off and on (Ninjajar!), We can now change the type
Of the enemies. The type contains whether or not it fires, what pattern of movement
Follow, and what sprite he has.

ENEMY n TYPE t			Sets type "t" for enemy "n".

However, it must be taken into account that this is destructive: if we change the
Type of an enemy, the original type will be lost forever.

In multilevel games this is no problem because with decompressing
New level let's get ready.

For single-level games, we have introduced an "enemy backup" that
We can activate from config.h using:

#define ENEMY_BACKUP

The backup takes up 3 bytes per screen and saves the original type of all
enemies. 

From scripting, we can do:

ENEMIES RESTORE			Restores to its original values the enemies of
The current screen.
	
ENEMIES RESTORE ALL		Restore the type of ALL level enemies.

If you only need to restore them at the start of each game, you can go from using
ENEMIES RESTORE ALL in the script and activate the RESTORE_ON_INIT directive in
Config.h

------
Sword
------

Hemos aadido la espada de Sir Ababol 2 como nuevo tipo de hitter (interna-
mente). Por el momento, no es posible disponer de puo y espada en el mismo
juego, aunque ya haremos algo para posibilitarlo en un futuro.

#define PLAYER_HAZ_SWORD

El grfico de la pantalla se define donde todos los dems: en extrasprites.h

---------
More things
---------

Hemos cambiado de todo pero ahora me falla la memoria... A ver, cosas misce-
laneas que s recuerdo:

#define PLAYER_WRAP_AROUND

Hay que usarlo slo si se ha definido #define PLAYER_CANNOT_FLICK_SCREEN. Con
ambas activas, adems de no poder salir de la pantalla, si nos acercamos a un
extremo lateral saldremos por el contrario.



====================
MT Engine MK2 v 0.88
====================

Edicion Leovigildo F. WTF? Es un puto HUEVO DE PASCUA, pero he ampliado
el motor en varias direcciones. Algunas pueden ser tiles para otros 
juegos, y otras no. A ver si me acuerdo de todo:

--------------------------------
Cosas de scripting sin scripting
--------------------------------

These are things that can be done with scripting, but being simple and
To store the pots in an array, if you were just going to use scripting
For this, you save it and you can fit more. Namely:

- engine/levelnames.h

Allows you to name each screen. Names must have
A fixed length and defined all in the same chain, all followed
And in order. You can see it in levelnames.h itself, where you can also
Set up location and color and such. To activate:

#define ENABLE_LEVEL_NAMES

- engine/extraprints.h

Permite definir impresiones de tiles extra para cada pantalla. Hay mucha
gente que ha usado scripting nicamente para esto (lo que me parece una 
pena, si me preguntan). Ahora no hace falta activar el scripting, el 
cdigo ocupa muy poco y cada impresin nicamente 2 bytes. Para activarlo:

#define ENABLE_EXTRA_PRINTS

Para establecer qu se imprimir, hay que editar extraprints.h. Ah se
define un array por cada pantalla con prints extra. Cada print extra se
compone de 2 bytes: "xy" y "tile". "xy" usa 4 bits para X y 4 para Y. Es
muy fcil de gestionar en hexadecimal, "x" va de 0 a F e "y" de 0 a 9. El
byte "tile" es simplemente el nmero de tile. La lista se acaba con un 
0xff (valor 255).

Por ejemplo, para imprimir un tile 17 en la posicin X=10, Y=2, los dos
bytes seran 0xA2, 17. Para imprimir un tile 33 en la posicin X=5, Y=7
los dos bytes seran 0x57, 33.

Por ltimo, hay otro array *prints con una entrada por cada pantalla del
mapa. Si en una pantalla no hay prints extra, se pone un 0. Si s que 
los hay, se pone el array de prints de la pantalla correspondiente.

- engine/sim.h

SIM significa "Simple Item Manager", y sirve para manejar items e inven-
tario sin necesitar scripting para juegos sencillos en los que haya X
objetos en Y contenedores por todo el mapa, y el juego se termine cuando
los X objetos se han colocado en otros sitios. Sin ms.

#define ENABLE_SIM

Activar el SIM. Esto meter cdigo redundante con el sistema
de scripting, por lo que ambos sistemas NO SON COMPATIBLES. Si usas 
scripting, maneja tus objetos a mano.

El SIM tiene unas cuantas directivas para configurarlo:

// General
#define SIM_MAXCONTAINERS		6
#define SIM_DOWN
//#define SIM_KEY_M
//#define SIM_KEY_FIRE

La primera, SIM_MAXCONTAINERS, define el mximo nmero de contenedores
(que no de objetos) que habr en el juego. Un contenedor puede estar
vaco o contener un objeto. Juegos en los que haya que poner tres 
objetos en otros tres sitios diferentes, por ejemplo, necesitarn seis
contenedores: los 3 que contendrn a los objetos, y 3 vacos con el
"destino final".

Las tres siguientes, definen qu tecla se usa para interactuar (coger/
dejar objeto). Respectivamente, abajo, M o FIRE. Define slo una, como
con el scripting.

Un componente del SIM es el inventario. El inventario es exactamente el
mismo que te sale cuando usas scripting y lo defines en tu script. Se
configura con las siguientes directivas:

// Display:
#define SIM_DISPLAY_HORIZONTAL
#define SIM_DISPLAY_MAXITEMS	2
#define SIM_DISPLAY_X			24
#define SIM_DISPLAY_Y			21
#define SIM_DISPLAY_ITEM_EMPTY	31
#define SIM_DISPLAY_ITEM_STEP	3
#define SIM_DISPLAY_SEL_C		66
#define SIM_DISPLAY_SEL_CHAR1	62
#define SIM_DISPLAY_SEL_CHAR2	63

Si se define SIM_DISPLAY_HORIZONTAL, el inventario se mostrar en una
linea horizontal. Si no se define, se mostrar en una linea vertical.

SIM_DISPLAY_MAXITEMS define el nmero de slots del inventario.

SIM_DISPLAY_X y SIM_DISPLAY_Y indican la coordenada de la pantalla donde
se mostrar el inventario. SIM_DISPLAY_ITEM_STEP define cada cuntas
celdas de carcter se dibujar un nuevo slot a partir de las coordenadas
iniciales.

SIM_DISPLAY_ITEM_EMPTY especifica qu tile representa el slot vaco.

SIM_DISPLAY_SEL_C especifica el color del selector, y SIM_DISPLAY_SEL_CHAR1
y SIM_DISPLAY_SEL_CHAR2 qu dos carcteres de tu charset utilizar para
dibujarlo.

Una vez definido todo esto, tendremos que abrir engine/sim.h para terminar
de configurar nuestro juego.

En sim.h se definen dos arrays: sim_initial y sim_final. El primero define
la ubicacin de los contenedores en el mapa y su contenido inicial; el 
segundo define un estado final que har que ganemos el juego si se alcanza.

sim_initial es un array de estructuras. Se define una entrada por cada
container del juego (en total, SIM_MAXCONTAINERS entradas). Cada entrada 
tiene un formato {n_pant, XY, tile}, donde n_pant es la pantalla donde se
encuentra, XY son las coordenadas (4 bits X, 4 bits Y, como en extraprints)
y tile es el tile que representa al objeto contenido en el container al
principio del juego.

Por ejemplo {10, 0x54, 32} har que en la pantalla 10 haya un container
en la posicin X=5, Y=4, que tenga inicialmente el objeto 32.

{3, 0xB3, 0} har que en la pantalla 3, en la posicin X=11, Y=3, haya un
container vaco.

sim_final es un array de nmeros. Simplemente especifica qu item debe
haber en cada container para terminar el juego. 

Por ejemplo, imaginemos un juego tonto donde hay un objeto en la pantalla 0
y otro en la pantalla 1, y hay que intercambiarlos para ganar. Los objetos
aparecern ambos en X=7, Y=4, y se representarn con los tiles 20 y 21.

En ese caso, SIM_MAXCONTAINERS valdra 2 y nuestros arrays seran:

SIM_CONTAINER sim_initial [SIM_MAXCONTAINERS] = {
	{0, 0x74, 20},
	{1, 0x74, 21}
};

unsigned char sim_final [SIM_MAXCONTAINERS] = {21, 20};

Tan sencillo como esto. Al principio, los contenedores contienen los objetos
20 y 21, y al final deben contener los objetos 21 y 20.

NOTA IMPORTANTE: SIM necesita que activemos los Floating Objects de tipo
contenedor en config.h

#define ENABLE_FO_OBJECT_CONTAINERS

Adems: si no has enredado debera estar igual, pero asegrate de todos
modos que el valor de FT_FLAG_SLOT en config.h y de FLAG_SLOT_SELECTED en
sim.h se corresponden. Parece guarrero, pero est as para posibles futuras
ampliaciones.

--------------------
Mejoras en el JETPAC
--------------------

El Jetpac se nos ocurri en la Churrera 1.0 y lo programamos, pero sin
probar. No lo usamos hasta la Churrera 3.1, cuando hicimos Cheril the
Goddess, y era muy rawro. Luego lo usamos en Jet Paco. 

Desde el principio habamos pensado en darle chicha con recargas, fuel
que se acaba, y cosas asn, pero hasta AHORA no se ha hecho.

#define PLAYER_HAS_JETPAC            	
#define JETPAC_DEPLETES				4	
#define JETPAC_FUEL_INITIAL			25	
#define JETPAC_FUEL_MAX				25	
#define JETPAC_AUTO_REFILLS			2
//#define JETPAC_REFILLS				
//#define JETPAC_FUEL_REFILL		25	

PLAYER_HAS_JETPAC, de toda la vida, activa este sistema. Si slo defines
esto, tendrs un jetpac como en jetpaco. Guay.

Si activas JETPAC_DEPLETES con valor "X", el jetpac tendr fuel que se 
ir agotando cada X frames, con X una potencia de 2 (2, 4, 8, 16...). 
Teniendo esto activo, podemos definir ms comportamientos.

JETPAC_FUEL_INITIAL y JETPAC_FUEL_MAX son necesarias en todo caso si 
activas JETPAC_DEPLETES. Especifican el valor de fuel al principio del juego
y el valor mximo que se puede alcanzar.

Con esto hemos conseguido que el fuel se gaste. Ahora hay que decidir cmo
recuperarlo:

Si activas JETPAC_AUTO_REFILLS con valor "Y", el jetpac se recargar slo
cuando no se est usando, cada Y frames, con Y una potencia de 2.

Si, en cambio, activas JETPAC_REFILLS, aparecern recargas que se colocan 
como hotspots de tipo 6 en el colocador. Cada recarga recargar el nmero de
unidades especificado en JETPAC_FUEL_REFILL.

----
Whoa
----

S, eso digo yo. Para un easter egg. Adems he corregido unos cuantos bugs
que he visto por ah y he limpiado algunas cosillas.


====================
MT Engine MK2 v 0.87
====================

Edicin Leovigildo III. Tiene pocas cosas puramente nuevas, pero trae
un porrn de mejoras internas, arreglos de bugs, optimizaciones...

El mdulo nuevo de enemigos.
----------------------------

Para usarlo, asegrate de comentar #define USE_OLD_ENEMS.

Ahora los enemigos son mucho ms flexibles. Cada uno define varias cosas:

- Qu sprite usa, de 0 a 3.
- Qu tipo de movimiento lleva: lineal, volador...
- Si dispara o no.

Adems est preparado para que sea muy fcil meter ms comportamientos.

Todo se especifica en el tipo de enemigo, que se divide en varios campos
a nivel de bits:

76543210
XBBBBFSS

Donde:

- X is reserved to mark if an enemy is crushed.
- BBBB Is the type of movement. For now there are implemented these:

0001 (1) - Linear back and forth, as always.
0010 (2) - flying. Like the fantys type 6.
0011 (3) - persecutor. The bum type 7 always.
1000 (8) - Mobile platform As "1" but mobile platform.

Eyelet! If you use type 2, you have to enable ENABLE_FLYING_ENEMIES. Yes
Use type 3, enable ENABLE_PURSUE_ENEMIES.

- F is whether it triggers (1) or not (0). If you activate it for an enemy,
Remember that you have to enable ENABLE_SHOOTERS and set MAX_COCOS
and other things.

- SS Is the sprite number, according to sprites, de 0 a 3 (00, 01, 10, 11).

The "type" of enemy is calculated, therefore, using this formula tonter:

S + 4 * F + 8 * B, Where S is the sprite, F is fired, and B is the behavior

To place them you can calculate the value of the type of enemy using
The above formula (is binary) or use the MK2 Putter there
In / enems, where you can set the values separately. What pisses you off.

Modifications to floating objects
-------------------------------------

- You can now better control your behavior with respect to the
Gravity - if we want to use them in games of genital view, more than
nothing:

#define FO_GRAVITY
#define FO_SOLID_FLOOR	

Activating the first, the FO will fall if there is no soil underneath. With the
Will stop at the bottom sign of the screen in place.
To disappear.

- FOs "kill" while you carry them. This is for the nonsense
Of this game, I do not know if it will work for anything else ... Anyway I do not
It cost to put it in the config instead of a custom paranoia ...

#define CARRIABLE_BOXES_DRAIN		7

- Corchonetas. Los FO pueden ser corchonetas. Si caes sobre ellos, 
rebotars. Puedes definir el mximo de velocidad rebotante.

#define CARRIABLE_BOXES_CORCHONETA	
#define CARRIABLE_BOXES_MAX_C_VY	1024	

For this to work you have to give the behavior "bouncing"
To the tile that represents the corkboard. This means that in a
Future version we can use bouncing tiles that are not FO, only
Defining the behavior ... I believe.

// 0 = Walkable (no action)
// 1 = Walkable and kills.
// 2 = Walkable and hides.
// 4 = Platform (only stops player if falling on it)
// 8 = Full obstacle (blocks player from all directions)
// 10 = special obstacle (pushing blocks OR locks!)
// 16 = Breakable (#ifdef BREAKABLE_WALLS)
// 32 = Conveyor 
// 64 = CUSTOM F.O. -> CORCHONETA!

- Scripting FO

Esto puede servir para muchas cosas pero hay que usarlo con cuidado. Se
emplea en Leovigildo III para detectar que le tiramos una corchoneta en
la cabeza al domador.

Bsicamente, si se activa, cuando un FO "cae", se almacena su tipo y posicin
en tres flags (configurables) y se llama a PRESS_FIRE en el script de esa
pantalla.

#define ENABLE_FO_SCRIPTING			
#define FO_X_FLAG					1
#define FO_Y_FLAG					2
#define FO_T_FLAG					3	

Esto empieza a dar mucho miedo. Ya daba miedo en Ninjajar. Ahora es aterrador.

====================
MT Engine MK2 v 0.86
====================

Edicin "Phantomas Engine". Ahora se puede hacer juegos de Phantomas - esto 
abre la posibilidad de aadir muy fcilmente ms motores de movimiento 
puramente lineales (sin inercia).

// Phantomas Engine
// ----------------
// Coment everything here for normal engine
#define PHANTOMAS_ENGINE 		1		// Which phantomas engine:
										// 1 = Phantomas 1
										// 2 = Phantomas 2
										// 3 = LOKOsoft Phantomas
										// 4 = Abu Simbel Profanation
										
#define PHANTOMAS_FALLING 		4		// Falling speed (pixels/frame)
#define PHANTOMAS_WALK			2		// Walking speed

#define PHANTOMAS_INCR_1		2		// Used for jumping
#define PHANTOMAS_INCR_2		4
#define PHANTOMAS_JUMP_CTR		16		// Total jumping steps up&down


// Most things from now on won't apply if PHANTOMAS_ENGINE is on...
// Try... And if you need something, just ask us... Maybe it's possible to add.

// For example, BOUNDING_BOX_8_BOTTOM works for PHANTOMAS/PROFANANTION engines.

It's simple (or not). There are four engine types, as seen in the code.
Then there are configuration parameters.

As it is, by selecting engine 1 the movement will be as in
Phantomas 1, engine 2 will do as Phantomas 2, and engine 4 as Abu
Simbel Profanation ... But playing with the values ??you will get other
things.

Engines 1, 2 and 4 are based on two types of jumps. At
Engines 1 we have high jump (2 high tiles, 1 wide) and long jump
(1 tile high, 4 wide). In engine 2 we have a long jump 
(slightly more than 2 tiles of high, 2 tiles of width) 
and short (1 tile x 1 tile), and in addition

We can change the direction of the jump in the middle of the air. 
In the engine
4 we have jumps just like in engine 2, but we can not change the
Direction and also if we press only jump the doll will jump to arrive
(It is necessary to press jump + left or right to jump sideways).

In addition we have used to add support for enemies 100% custom
To the enemy module, and we have included a pair as "addons": drops and
Arrows, which use their own sprites. In addition, there is a new utility To convert sprites for these goings-on.

#define ENABLE_DROPS					// Enemy type 9 = drops
#define ENABLE_ARROWS					// Enemy type 10 = arrows

These enemies are placed with the setter. Look at the files

\dev\addons\drops\move.h 
\dev\addons\arros\move.h

To see how your values are specified. Or the question in the forum.

The best thing is that if you want to use this we put a message or something asking
The example micro-game where you see everything in action. I do not think so
Let's get it out of the way, I do not have the time or the energy.

====================
MT Engine MK2 v 0.85
====================

Cambios y aadidos para la segunda carga de Leovigildo. Son un montn, a ver
si me acuerdo:

- Se puede lanzar las cajas CARRIABLE_BOXES pulsando FIRE. Las cajas matan
los bichos y los cuentan en un flag:

#define CARRIABLE_BOXES_THROWABLE		// If defined, carriable boxes are throwable!
#define CARRIABLE_BOXES_COUNT_KILLS 2	// If defined, count # of kills and store in flag 2.

- Modo mono-pantalla. Slo se puede cambiar de pantalla por scripting, no se
detecta el cambio de pantallas de toda la vida cuando el nio se pega al borde.
Esto sirve para hacer juegos de pantalla en pantalla.

#define PLAYER_CANNOT_FLICK_SCREEN		// If defined, automatic screen flicking is disabled.

- Contar cuntos bichos hay en la pantalla y meterlos en un flag. Para hacer
gegos de "mtalos todos para pasar" o cosas por el estilo, del palo "si
matas todos los bichos pasa algo".

#define COUNT_SCR_ENEMS_ON_FLAG	1		// If defined, count # of enems on screen and store in flag #

- Cada vez que se cambia de pantalla, mostrar el nmero de pantalla +1
en plan nmero de nivel. Para juegos pantalla-a-pantalla.

#define SHOW_LEVEL_ON_SCREEN			// If defined, show level # whenever we enter a new screen

- Vamos a cambiar el mdulo de enemigos, as que nos vamos preparando. 
Como el mdulo viejo no lo voy a borrar, puedes seguir usndolo si especificas

#define USE_OLD_ENEMS					// If defined, use old enems (like in Churrera)

- Desactivar plataformas mviles en juegos de plataformas. Ahora puedes tener
cuatro enemigos diferentes. 

#define DISABLE_PLATFORMS				// If defined, type 4 are enemies in side-view mode

- Enemigos resucitan al entrar en la pantalla. Vale, esto ya estaba, pero 
ahora tiene algunos cambios:

#define RESPAWN_ON_ENTER				// Enemies respawn when entering screen
#define RESPAWN_ON_REENTER				// Respawn even on a REENTER in the script (by default REENTER doesn't respawn enemies!)

	Si activas la primera, al entrar con el mueco en una pantalla los enemigos 
	volvern a la vida. 
	
	Si activas, adems, la segunda, los enemigos volvern a la vida tambin tras
	el comando REENTER en el script.

- Hemos mejorado un montn de cosas, entre ellas el timer, que estaba algo
roto (todava quedarn muchas cosas de la Churrera que estn rotas, vamos poco 
a poco).

===================
MT Engine MK2 v 0.8
===================

Hemos reescrito el motor casi entero. An falta el mdulo de enemigos, que 
queremos reorganizar. Por eso an no estamos en la 1.0.

El nuevo motor funciona prcticamente igual que la Churrera 3.X, pero funciona
ms rpido y ocupa menos memoria. Adems hay un montn de cosas nuevas, como
los "hitters" de Ninjajar (por ahora para dar hostias, pero pronto para hacer
espadas), mejor soporte multi-fase en el scripting, poder saltar de una fase
a otra, motor de items mejorado...

Floating Objects
================

#define ENABLE_FLOATING_OBJECTS

Son tiles interactuables que no forman parte del mapa. Se colocan desde el 
script. Por ahora el motor puede manejar dos tipos.

Los floating objects se colocan en cada pantalla desde el script:

	ADD_FLOATING_OBJECT t, x, y

- Carriable boxes

#define ENABLE_FO_CARRIABLE_BOXES
#define CARRIABLE_BOXES_ALTER_JUMP 180
#define FT_CARRIABLE_BOXES			16

Son cajas que se pueden transportar. Necesita que reservemos 10 bloques de 
sprites ms (ver main.c, al principio) para un sprite extra. Las cajas se cogen
y depositan pulsando ABAJO. Las cajas se ven afectadas por la gravedad y se
apilan unas a otras. 

Puedes definir el tile que usan con la directiva FT_CARRIABLE_BOXES. Los 
objetos emplean el comportamiento definido para este tile. Ser el valor
que hay que darle a "t" a la hora de colocarlos desde el script, por ejemplo
para poner una de estas cajas en la posicin 7, 8 habiendo definido que su
tile es el 16 hacemos:

	ADD_FLOATING_OBJECT 16, 7, 8

Si defines CARRIABLE_BOXES_ALTER_JUMP, el valor mximo de la velocidad de
salto se cambiar por el valor especificado cuando llevemos una caja.

- Item containers

#define ENABLE_FO_OBJECT_CONTAINERS		
#define FT_FLAG_SLOT				30	

Estos estn pensados para ser usados con el motor de inventario del scripting.
Cada contenedor en realidad representa un flag del sistema de scripting. Al 
pintar la pantalla se pintar el tile cuyo nmero est almacenado en el flag
correspondiente.

Para crearlos desde el scripting:

	ADD_FLOATING_OBJECT 128 + f, x, y
	
Donde f es el flag que queremos representar. Por ejemplo, si vamos a usar el
flag 10 para representar un contenedor en la posicin 4, 4 de la pantalla, 
deberamos crearlo as:

	ADD_FLOATING_OBJECT 138, 4, 4
	
Como esto es un poco confuso, hemos aadido un alias. Lo mismo puede hacerse
llamando a:

	ADD_CONTAINER f, x, y
	
El ejemplo anterior sera:

	ADD_CONTAINER 10, 4, 4
	
El motor reacciona a estos bloques intercambiando el objeto seleccionado del
inventario con el que haya en el contenedor.

Alias en el script
==================

Porque haciendo Ninjajar nos quisimos volver locos con tanto flag, hemos
aadido alias. Definimos un bloque al principio del script as:

DEFALIAS
	$ALIAS N
	...
END

A partir de entonces, podemos sustituir "N" por "$ALIAS". Por ejemplo, si
usamos el flag 2 para abrir una puerta verde y el flag 3 para ver si hemos
hablado con el ogro hacemos:

DEFALIAS
	$PUERTA_VERDE 2
	$HABLA_OGRO 3
END

En el script podemos usar los alias en vez del numerico:

...
    IF FLAG $HABLA_OGRO = 0
    THEN
        EXTERN 10
        SET FLAG $HABLA_OGRO = 1
    END
...

=======
3.99.3c
=======

#define PLAYER_CAN_FIRE_FLAG   1

Si se define, el flag indicado controla si el jugador puede (1) o no (0) disparar.

MOTOR DE ITEMS
--------------

Queremos conseguir que pueda haber un pequeo inventario en pantalla y poder 
seleccionar un objeto de l, y adems queremos que los objetos que compongan 
el inventario no sean fijos y que podamos saber, desde el script, qu objeto 
hay seleccionado.

- En una seccin inicial del script, vamos a definir "el itemset" (hay que 
ponerle nombres a las cosas, aunque sean nombres tan chungos como este): cuantos 
espacios tiene, dnde se colocan, y como se distribuyen los objetos. Algo as:

Cdigo:
ITEMSET
   # Nmero de huecos:
   SIZE 3
   
   # Posicin x, y
   LOCATION 2, 21
   
   # Horizonta/vertical, espaciado
   DISPOSITION HORZ, 3
   
   # Color y caracteres para pintar el selector
   SELECTOR 66, 82, 83
   
   # (si se define) qu tile representa el tile vaco
   EMPTY 31
   
   # Flag que contiene qu hueco est seleccionado
   SLOT_FLAG 14
   
   # Flag que contiene qu objeto est en el hueco seleccionado
   ITEM_FLAG 15
END

- Un objeto se representa por su tile. Si tenemos una corona en el tile 10,
el objeto corona ser el 10. Si en un hueco del inventario est el 10, 
significa que en ese hueco est la corona. El valor 0 siempre representar 
un hueco vaco. Esto simplifica el cdigo una barbaridad.

- En el script habr cambios. ITEM n = t significa que en el hueco "n" est 
el objeto representado por el tile t. Definimos, pues, las siguientes 
condiciones:

Cdigo:
IF ITEM n = t
IF ITEM n <> t

Comprueban que en el espacio "n" est o no el objeto de tile "t".

Cdigo:
IF SEL_ITEM = t

Comprueba que en el espacio seleccionado por el selector est el objeto de 
tile "t"

Y los siguientes comandos:
Cdigo:
SET ITEM n = t

Establece en el hueco n el tile t. Obviamente, para quitar un objeto del hueco 
n, pondremos un 0.

Hay una limitacin, por tanto, en el nmero de objetos que puede llevar el 
personaje a la vez. Con un poco de cabeza, como he dicho, se puede gestionar 
esto muy bien, y con un mnimo de cdigo aadido al motor tenemos una 
herramienta bastante potente. Todo esto hay que combinarlo con los flags para 
tener funcionalidad completa. Con los ITEMs solo podemos saber si tenemos o 
no un ITEM en el inventario, pero no si se ha usado ya. Para eso necesitamos 
los flags.

Cmo se usa esto? Pongamos un ejemplo.

Imaginad que en la pantalla 6 tenemos un objeto "corona", representado por el 
tile 33, y lo tenemos en (7, 7). Adems, el flag que indica su estado es el 3, 
que valdr 0 cuando an no lo hayamos cogido ni nada, para pintarlo en la 
pantalla.

Cdigo:
ENTERING SCREEN 6
    IF FLAG 3 = 0
    THEN
        SET TILE (7, 7) = 33
    END
END


Vamos a gestionar el hecho de cogerlo. Podemos hacerlo en modo bsico o en modo
virguero. Veamos el modo bsico primero. En el modo bsico asignamos "a mano" 
un hueco fijo para cada item. La corona la colocaremos en el hueco 2:

Cdigo:
PRESS_FIRE AT SCREEN 6
    IF PLAYER_TOUCHES (7, 7)
    IF FLAG 3 = 0
    THEN
        SET FLAG 3 = 1
        SET TILE (7, 7) = 0
        SET ITEM 2 = 33
    END
END

El juego con el flag 3 es simplemente para que no vuelva a dibujarse. Cuando el
flag 3 valga 1 no se volver a pintar el objeto al volver a entrar en la 
pantalla, ni intentaremos cogerlo de nuevo. Por lo dems, lo que se hace es
 hacer que en el hueco 2 est el objeto 33.

Imaginad que en la pantalla 12 tenemos que usarlo en la coordenada 5, 8. Pues 
habr que comprobar que el item seleccionado es el 33:
Cdigo:
PRESS_FIRE AT SCREEN 12
    IF SEL_ITEM = 33
    THEN
        SET ITEM 2 = 0
        # mas cosas
    END
END


Si el objeto seleccionado es el 33 (que slo podr ocurrir si antes lo 
colocamos en el hueco 2), lo quitamos del inventario (poniendo un 0 en el slot 
2) y luego hacemos ms cosas.

El modo virugero es que el objeto vaya al hueco seleccionado. Para eso usamos 
la indireccin que permite el motor de scripting con el operador #. Recordad 
que estamos usando el flag 10 para representar el hueco seleccionado. Juguemos 
con eso. Adems, habr que comprobar que el hueco est libre!

Cdigo:
PRESS_FIRE AT SCREEN 6
    IF PLAYER_TOUCHES (7, 7)
    IF FLAG 3 = 0
    IF FLAG 10 <> 0
    THEN
        # Mal! el hueco no est libre!
        SOUND 2
    END

    IF PLAYER_TOUCHES (7, 7)
    IF FLAG 3 = 0
    IF FLAG 10 = 0
    THEN
        SET FLAG 3 = 1
        SET TILE (7, 7) = 0
        SET ITEM #10 = 33
    END
END


What do we do? Then place the tile 33 object (our crown) in the selected space, which is no more than the one stored in flag 10 (remember that # 10 means "the value of flag 10").

To prove that we have it, then the same.

What do you think? Doubts? Something to comment? If it does, I'll do exactly as I described.

=======
3.99.3b
=======

Minimal revision. It is arranged to be able to have 128K games with a
Only level (ie use MODE_128K without COMPRESSED_LEVELS).

Right now there are two examples that can help you if you want to make a 128K game:

- Goku Mal: 128K with compressed levels. See this doc and the sources of the game.
- The new adventures of Dogmole Tuppowsky: 128K with only one level, more info in
The forum of mojonia.

Also, in spare I added the file extern-texts.h whose contents you can use
In extern.h if you want a simple way to display texts on screen using the
EXTERN command n of the script.

======
3.99.3
======

Tiles animados
--------------

Si se define:

#define ENABLE_TILANIMS			32		// If defined, animated tiles are enabled.
										// the value especifies firt animated tile pair.

In config.h, tiles> = the specified index are considered animated.
In the tileset, they come in pairs. If, for example, "46" is defined, then
The only pair of tiles 46 and 47 will be animated. The motor will detect them and each
Frame will cause one of the tiles 46 to change state.

There can be up to 64 animated tiles on the same screen. If you put more, pet

128K Mode
---------

You have to do a lot of manual work with this. I'm sorry, but it's like that. 
First you will have to create a make.bat that will build everything you need. 
For this you can rely on the file spare / make128.bat and adapt it to your project.

The 128K mode is the same as the 48K but use WYZ Player and also supports several 
levels. You can not have longer levels, but you can have several levels.

To use it, you need to activate three things in config.h:

#define MODE_128K						// Experimental!
#define COMPRESSED_LEVELS				// use levels.h instead of mapa.h and enems.h (!)
#define MAX_LEVELS			4			// # of compressed levels

In MAX_LEVELS you have to specify the number of levels you are going to use.

In churromain.c you have to change the position of the stack and place it below the main binary:

#pragma output STACKPTR=24299

Then you have to modify levels128.h, which is where the level 
structure is defined and included in 128K mode. There you will 
see an array of levels, with information about levels. In 
principle, very little information is included:

// Level struct
LEVEL levels [MAX_LEVELS] = {
	{3,2},
	{4,3},
	{5,4},
	{6,5}	
};

The first value is the resource number (see below) that contains the level. 
The second value is the number of the song in WYZ PLAYER that should sound while playing 
level.

To prepare a level you have to use the new utility buildlevel.exe in / utils. 
This utility takes the following parameters:

$ buildlevel mapa.map map_w map_h lock font.png work.png spriteset.png 
extrasprites.bin enems.ene scr_ini x_ini y_ini max_objs enems_life behs.txt level.bin

	* Map.map Is mappy mappy
 * Map_w, map_h Are the dimensions of the map on screens.
 * Lock 15 for autodetect locks, 99 if no locks
 * Font.png is a 256x16 file with 64 ascii characters 32-95
 * Work.png is a 256x48 file with the tileset
 * Spriteset.png is a 256x32 file with the spriteset
 * Extrasprites.bin you find it in / levels
 * Enems.ene the file with the enemies / hotspots of colocador.exe
 * Scr_ini, scr_x, scr_y, max_objs, enems_life level values
 * Behs.txt a file with tile types, separated by commas
 * Level.bin is the output file name.
   
When we have all levels built, we have to compress them with apack:

$ /utils/apacke.exe level1.bin level1c.bin
...

When we have all levels compressed, we will have to create the binary images that 
will be loaded in the extra RAM pages.  For that we use the librarian utility in 
the / bin folder. In fact, it's a good idea to work on the / bin folder for this.

The utility librarian uses a list list with the compressed binaries that must be 
inserted in the binary images that will go in the extra pages of RAM. The first 
thing we will have to put in is the title.bin, frame.bin and ending.bin files, 
in that order. If you do not have .bin you should use a
Length 0, but you must specify it. Then we will add our levels. For example:

title.bin
marco.bin
ending.bin
level1c.bin
level2c.bin
level3c.bin
level4c.bin

There we added four compressed levels.

When you run librarian, you will be filling in 16K images destined to go in the extra RAM. 
First it will create ram3.bin, then ram4.bin and finally ram6.bin, according to I need more space.

It will also generate the file librarian.h, which we will have to copy to / dev. 
Here we can see the resource number associated with each binary:

RESOURCE resources [] = {
   {3, 49152},   // 0: title.bin
   {3, 50680},   // 1: marco.bin
   {3, 50680},   // 2: ending.bin
   {3, 52449},   // 3: level1c.bin
   {3, 55469},   // 4: level2c.bin
   {3, 58148},   // 5: level3c.bin
   {3, 60842}   // 6: level4c.bin
};

These resource numbers are those that we will have to specify in the array levels mentioned above.
Specifically, resources 3, 4, 5 and 6 are those containing the four levels.

With all this done and prepared, the tape will have to be mounted. 
For this you have to create a suitable loader.bas (you can see an example in /spare/loader.bas) and 
build a .tap with each block of RAM (again, the example in /spare/make.bat builds the tape with 
binaries in RAM3 and RAM4).

You will also need RAM1.BIN to build RAM1.TAP, containing the WYZ player with the songs. 
For this you will have to modify /mus/WYZproPlay47aZX.ASM in / mus to include your songs. 
You have an example in / spare.

As you can see, it's a bit tedious. I recommend that you build mini-projects in 48K as you make 
the levels, and that in the end you build a 128K version with all.

In addition, you can use the extra space to put more compressed screens, or even code to use 
passwords to jump directly to the levels.  You can see examples of all this in Goku Mal 128.

Hotspots tipo 3
===============

Hemos hecho esta modificacin, propuesta en el foro, fija a golpe de directiva.
Si defines

#define USE_HOTSPOTS_TYPE_3				// Alternate logic for recharges.

Las recargas aparecern nica y exclusivamente donde t las coloques, usando
el hotspot de tipo 3.

Pausa / Abortar
===============

Si se define

#define PAUSE_ABORT						// Add h=PAUSE, y=ABORT

Se aade cdigo para habilitar la tecla "h" para pausar el juego y la tecla
"y" para interrumpir la partida. Si quieres cambiar la asignacin tendrs que
tocar el cdigo en mainloop.h

Mensaje al coger objetos
========================

Se se define

#define GET_X_MORE						// Shows "get X more" 

Aparecer un mensaje con los objetos que te quedan cada vez que coges uno.

-------------------------------------------------------------------------------

=========
3.99.2mod
=========

Esta fue una versin especial con una cosa que nos pidi Radastan, los...

Tiles animados
==============

Todo se basa en tilanim.h. Este archivo se incluye si se define en config.h la 
directiva ENABLE_TILANIMS. Adems, el valor de esta directiva es el que define 
el nmero de tile menor que se considera animado.

En tilanim.h hay, adems de la definicin de datos, dos funciones:

void add_tilanim (unsigned char x, unsigned char y, unsigned char t) 
se llama desde la funcin que pinta la pantalla actual si detecta que el tile 
que va a pintar es >= ENABLE_TILANIMS. Aade un tile animado a la lista de 
tiles.

void do_tilanims (void) se llama desde el bucle principal. Bsicamente 
selecciona un tile animado al azar entre todos los almacenados, le cambia el 
frame (de 0 a 1, de 1 a 0) y lo dibuja.

Para usarlo slo tienes que definir en config.h la directiva ENABLE_TILANIMS 
con el tile animado menor. Por ejemplo, si tus cuatro ltimas parejas de 
tiles (8 en total) son los animados, pon el valor 40. Luego, en el mapa, se 
tiene que poner el tile menor de la pareja, o sea, el tile 40 para 40-41, el 
42 para 42-43... Si no lo haces as pasarn cosas divertidas. El cdigo es 
(tiene que ser) minimal, no se comprueba nada, as que cuidao.

Por cierto, esto no se ha probado. Si lo pones en tu gego y se peta, danos
un toque.

-------------------------------------------------------------------------------

======
3.99.2
======

Venga, las churreras van saliendo como churros. Estamos que lo rompemos, y
se nos ocurren cosas nuevas todos los das. Las iremos metiendo a medida que
se nos ocurran gegos que las lleven.

Estas son las cosas nuevas que hay en esta versin de la churrera:

Temporizadores
==============

Se aade a la churrera un temporizador que podemos usar de forma automtica
o desde el script. El temporizador toma un valor inicial, va contando hacia
abajo, puede recargarse, se puede configurar cada cuntos frames se decrementa
o decidir qu hacer cuando se agota.

#define TIMER_ENABLE

Con TIMER_ENABLE se incluye el cdigo necesario para manejar el temporizador.
Este cdigo necesitar algunas otras directivas que especifican la forma de
funcionar:

#define TIMER_INITIAL		99	
#define TIMER_REFILL		25
#define TIMER_LAPSE 		32

TIMER_INITIAL especifica el valor inicial del temporizador. Las recargas de
tiempo, que se ponen con el colocador como hotspots de tipo 5, recargarn el
valor especificado en TIMER_REFILL. El valor mximo del timer, tanto para el
inicial como al recargar, es de 99. Para controlar el intervalo de tiempo que
transcurre entre cada decremento del temporizador, especificamos en TIMER_LAPSE
el nmero de frames que debe transcurrir.

#define TIMER_START

Si se define TIMER_START, el temporizador estar activo desde el principio.

Tenemos, adems, algunas directivas que definen qu pasar cuando el temporiza-
dor llegue a cero. Hay que descomentar las que apliquen:

#define TIMER_SCRIPT_0	

Definiendo esta, cuando llegue a cero el temporizador se ejecutar una seccin
especial del script, ON_TIMER_OFF. Es ideal para llevar todo el control del
temporizador por scripting, como ocurre en Cadverin.

//#define TIMER_GAMEOVER_0

Definiendo esta, el juego terminar cuando el temporizador llegue a cero.

//#define TIMER_KILL_0
//#define TIMER_WARP_TO 0
//#define TIMER_WARP_TO_X 	1
//#define TIMER_WARP_TO_Y 	1

Si se define TIMER_KILL_0, se restar una vida cuando el temporizador llegue a
cero. Si, adems, se define TIMER_WARP_TO, adems se cambiar a la pantalla
espeficiada, apareciendo el jugador en las coordenadas TIMER_WARP_TO_X y 
TIMER_WARP_TO_Y.

//#define TIMER_AUTO_RESET

Si se define esta opcin, el temporizador volver al mximo tras llegar a
cero de forma automtica. Si vas a realizar el control por scripting, mejor
deja esta comentada.

#define SHOW_TIMER_OVER	

Si se define esta, en el caso de que hayamos definido o bien TIMER_SCRIPT_0 o
bien TIMER_KILL_0, se mostrar un cartel de "TIME'S UP!" cuando el temporizador
llegue a cero.

Scripting:
----------

Como hemos dicho, el temporizador puede administrarse desde el script. Es
interesante que, si decidimos hacer esto, activemos TIMER_SCRIPT_0 para que
cuando el temporizador llegue a cero se ejecute la seccin ON_TIMER_OFF de
nuestro script y que el control sea total. 

Adems, se definen estas comprobaciones y comandos:

Comprobaciones:
---------------

IF TIMER >= x
IF TIMER <= x

Que se cumplirn si el valor del temporizador es mayor o igual o menor o igual
que el valor especificado, respectivamente.

Comandos:
---------

SET_TIMER a, b

Sirve para establecer los valores TIMER_INITIAL y TIMER_LAPSE desde el script.

TIMER_START

Sirve para iniciar el temporizador.

TIMER_STOP

Sirve para parar el temporizador.

---

Control de bloques empujables
=============================

Hemos mejorado el motor para que se pueda hacer ms cosas con el tile 14 de
tipo 10 (tile empujable) que simplemente empujarlo o que detenga la trayectoria
de los enemigos. Ahora podemos decirle al motor que lance la seccin PRESS_FIRE
de la pantalla actual justo despus de empujar un bloque empujable. Adems, el
nmero del tile que se "pisa" y las coordenadas finales se almacenan en tres
flags que podemos configurar, para poderlas usar desde el script para hacer 
comprobaciones.

Este es el sistema que se emplea en el script de Cadverin para controlar que
coloquemos las estatuas sobre los pedestales, por poner un ejemplo.

Recordemos lo que tenamos hasta ahora:

#define PLAYER_PUSH_BOXES 				
#define FIRE_TO_PUSH					

La primera es necesaria para activar los tiles empujables. La segunda obliga al
jugador a pulsar FIRE para empujar y, por tanto, no es obligatoria. Veamos 
ahora las nuevas directivas:

#define ENABLE_PUSHED_SCRIPTING
#define MOVED_TILE_FLAG 		1
#define MOVED_X_FLAG 			2
#define MOVED_Y_FLAG 			3

Activando ENABLE_PUSHED_SCRIPTING, el tile que se pisa y sus coordenadas se 
almacenarn en los flags especificados por las directivas MOVED_TILE_FLAG,
MOVED_X_FLAG y MOVED_Y_FLAG. En el cdigo que se muestra, el tile pisado se
almacenar en el flag 1, y sus coordenadas en los flags 2 y 3.

#define PUSHING_ACTION

Si definimos esta, adems, se ejecutarn los scripts PRESS_FIRE AT ANY y
PRESS_FIRE de la pantalla actual.

Recomendamos estudiar el script de Cadverin, el cual, adems de ser un buen
ejemplo del uso del temporizador y del control del bloque empujable, resulta
ser un script bastante complejo que emplea un montn de tcnicas avanzadas.

---

Comprobar si nos salimos del mapa
=================================

Es aconsejable poner lmites en tu mapa para que el jugador no se pueda
salir, pero si tu mapa es estrecho puede que quieras aprovechar toda la 
pantalla. En ese caso, puedes activar:

#define PLAYER_CHECK_MAP_BOUNDARIES

Que aadir comprobaciones y no dejar que el jugador se salga del mapa.
Ojo! Si puedes evitar usarlo, mejor: ahorrars espacio.

---

Tipo de enemigo "custom" de regalo
==================================

Hasta ahora habamos dejado sin cdigo los enemigos de tipo 6, pero 
hemos pensado que no nos cuesta poner uno, de ejemplo. Se comporta como
los murcilagos de Cheril the Goddess. Para usarlos, ponlos en el colo-
cador de enemigos como tipo 6 y usa estas directivas:

#define ENABLE_CUSTOM_TYPE_6			
#define TYPE_6_FIXED_SPRITE 	2		
#define SIGHT_DISTANCE			96

La primera los activa, la segunda define qu sprite va a usar (menos 1,
si quieres el sprite del enemigo 3, pon un 2. Sorry por la guarrada,
pero ahorro bytes). La tercera dice cuntos pxels ve de lejos el bicho.
Si te ve, te persigue. Si no, vuelve a su sitio (donde lo hayas puesto
con el colocador).

Esta implementacin, adems, utiliza dos directivas de los enemigos de
tipo 5 para funcionar:

#define FANTY_MAX_V             256	
#define FANTY_A                 12	

Define ah la aceleracin y la velocidad mxima de tus tipo 6. Si vas a 
usar tambin tipo 5 y quieres otros valores, s un hombre y modifica el
motor.

---

Configuracin de teclado / joystick para dos botones
====================================================

Hay gegos de vista lateral que se juegan mejor con dos botones. Si activas
esta directiva:

#define USE_TWO_BUTTONS

El teclado ser el siguiente, en vez del habitual:

A izquierda
D derecha
W arriba
S abajo
N salto
M disparo

Si se elige joystick, FIRE y M disparan, y N salta.

---

Disparos hacia arriba y en diagonal para vista lateral
======================================================

Ahora podrs permitir que el jugador dispare hacia arriba o en diagonal.
Para ello define esto:

#define CAN_FIRE_UP	

Esta configuracin funciona mejor con USE_TWO_BUTTONS, ya que as separamos
"arriba" del botn de salto.

Si no pulsas "arriba", el personaje disparar hacia donde est mirando. Si
pulsas "arriba" mientras disparas, el personaje disparar hacia arriba. Si,
adems, ests pulsando una direccin, el personaje disparar en la diagonal
indicada.

---

Balas enmascaradas
==================

Por velocidad, las balas no llevan mscaras. Esto funciona bien si el fondo
sobre el que se mueven es oscuro (pocos pixels INK activos). Sin embargo, 
hay situaciones en las que esto no ocurre y se ve mal. En ese caso, podemos
activar mscaras para las balas:

#define MASKED_BULLETS

