XT-Engine: small, but powerful platform game engine in asm

[ketmar]

EDIT:

XTE1 is not developed anymore, and XTE2 doesn't have a real demo yet. @ketmar will post when it will be ready. thank you!

The XTE source code repository link there: http://ketmar.no-ip.org/fossil/xtengine/.

the optimisation topic created by @Joefish finally made me to finish my old idea about "universal platform engine". so, here it is, XT-Engine Tech Preview Demo v0.0.2!

what is XT-Engine exactly, you may ask? let me quote readme file:

Spoiler

XT-Engine is simple, fast and powerful engine for creating platform games.
It is currently oriented at assembler users, but can easily be adapted to
use with Z88DK, or any other compiler.

The code of the engine is heavily commented, and the engine has clean
public API.

some engine features:

* the core rendering engine is about 2kb of machine code
* uses about 1.5kb of working area (including framebuffer, and room tilemap)
* can render the whole 32x24 screen area (or smaller, if you want that)
* internal tilemap is 32x24 bytes, so tilemap address calculation is easy
* doesn't use IY (so it is possible to run it in IM 1)
* supports masked sprites, each sprite is 24x16 pixels
* supports 4 graphics set for each sprite (for easy using of 16x16 preshifted sprite gfx)
* sprites will not flicker even if the engine is interrupted (but may be teared)
* updates only changed tiles
* automatically erases sprites at old positions when the sprite is moved
* no need to do anything special for sprite moving, just change the coords
* has IM 2-driven sound engine from Steve Turner as a bonus ;-)
* works at ~18-20 FPS with 10 24x16 sprites moving, and with simple platforming logic
* simple platforming game demo included
* 48K-compatible
* per-tile "always on top" flag; not per tile index, but per tile on a tilemap!
this means that you can make any room tile "on top"; but there is no way
do dynamically change this yet (TODO)
* NO NFTs ATTACHED!

in short, this is the game engine for creating flip-screen platform games, written in Z80. it support fullscreen playing area, can be used in IM 1 mode, contains bounding-box and per-pixel collision detection API, and can run in ~18-20 FPS with 10 sprites and platform game logic. it is also quite small: the core engine is about 2kb of machine code, and it is using about 1.5kb of RAM for data (this includes room tilemap).

you can use up to 63 8x8 tiles in your rooms, any individual tile can have "tile always on top" flag (any room tile, not the whole tile type!), and the engine has support for several sprite attr modes ("don't change", "always change", "change only on tile #0"). also, all the sprites are properly masked sprites, not a cheating "xor-print" ones! and of course, the sprites can freely overlap without any flickering.

WARNING! this is not "game creator" a-la AGD! XT-Engine is assembler library which you can use to skip writing things like screen rendering, collision detection, sound fx, input management, and such. i.e. it is a set of assembler routines to include in your own asm projects.

this is prerelease tech demo. while it is already usable, i am planning to better optimise the code, and add some more features for the release (sprites of different sizes, more utility API, documentation, and better demo game).

screenshot from the included demo:

Spoiler

note that (some) guardians in the demo are not using predefined coords, they are using platforming logic. i.e. those horizontal and vertical guardians which aren't ignoring the brick tiles are honestly checking the tilemap.

Link removed. the code is under WTFPL license.

have fun, and happy hacking!

[ketmar]

also, Fossil repository with the source code. contains the whole development history. ;-)

[Inky]

also, Fossil repository with the source code. contains the whole development history.

Nice to see Fossil being used too

[Ralf]

this is prerelease tech demo. while it is already usable, i am planning to better optimise the code, and add some more features for the release (sprites of different sizes, more utility API, documentation, and better demo game).

Don't neglect the demo. If you do a crap demo with a good engine then nobody will know that the engine is good. Make it pretty. Yes, pretty graphics
have nothing to do with the engine itself but again, when people see bad or borrowed graphics they usually don't inquire more.

This engine has potential, 10 masked sprites is really a lot.

And do you wish to keep 8x8 tiles or will it also be expanded to different tile sizes?

8x8 tiles are a bit limiting. Storing a location made of them takes quite a lot of memory. Making any more complicate graphics with them is not
comfortable

[ketmar]

Don't neglect the demo. If you do a crap demo with a good engine then nobody will know that the engine is good. Make it pretty. Yes, pretty graphics
have nothing to do with the engine itself but again, when people see bad or borrowed graphics they usually don't inquire more.

yeah, i know that. but sadly, i'm not an artist, and not a game designer. that's why i never released any game for Speccy: i simply cannot into it. so the best i can do is to rip sprites from other games.

any volunteers to help with game design and gfx, btw?

This engine has potential, 10 masked sprites is really a lot.

thank you! actually, now there are even more sprites. ;-) and the upcoming beta has support for different sprite widths (8 and 16 pixels), and arbitrary sprite height. it means that if you want to have smaller sprites (like projectiles, for example), you don't need to waste CPU time to render zeroes, and RAM bytes to store them. so i added several smaller sprites to the demo, bumping it to about 12, and without a speed loss.

also, the beta is better optimised too, and has other new features. it is almost 3kb now, but there are options to turn off unused engine parts. without any extra features, and with only bounding box collision detection, the engine code could be shrinked to ~1900 bytes.

And do you wish to keep 8x8 tiles or will it also be expanded to different tile sizes?

8x8 tiles are a bit limiting. Storing a location made of them takes quite a lot of memory. Making any more complicate graphics with them is not comfortable

you don't need to store locations in this format at all. many games (like Jack the Nipper 2, for example) create rooms from "supertiles" instead. i.e. JtN2 has a set of 4x4 "supertiles" built from 8x8 tiles (i.e. each "supertile" is 32x32 pixels), and when unpacking the room, it builds 8x8 tilemap from those "supertiles".

i.e. you can define several bigger tile configurations, and build your rooms from those bigger tiles, with a simple unpacking routine. or use any other data compression methods. also note that it is possible to switch tileset gfx with a simple API call, so each unpacked room can use its own tile graphics.

i'm planning to show how to do something like that in one of the demos for the full release.

i'm also thinking about writing a game authoring shell, kinda like AGD, so people could use it instead of asm. either this, or make PL/M interface for my PL/M compiler, if i'll ever finish it. ;-)

maybe a 16K demo game too, because the engine is small enough to be used with 16K Speccy, and it works perfectly with IM1 interrupts. 16K game with masked sprites, yay! (one or two, because there's no memory for more, lol.)

p.s.: 8x8 tiles is what makes the engine fast. contrary to "normal logic", changing tile size will only make the engine bigger and slower.

p.p.s.: added some background tiles to show that the engine doesn't really care, and can work with that too.

Spoiler

it looks awful in dynamics due to clashing, of course, but the speed is still the same as with black bg. score is printed directly into tilemap too, because why not? ;-)

[ketmar]

i implemented most features i wanted to have for the first beta release. (btw, i never mentioned it, but of course, you can configure the view area; it can be smaller than the tilemap, show any tilemap part, and positioned whereever you like.)

still need help with a sample game. simple game idea, anyone? sprite art, please? PM me if you can help!

Spoiler

if i'll be able to create a good demo game with original gfx, i'll switch the license from current GPL back to WTFPL! yes, this is blackmail. ;-)

[ketmar]

made sprite printing slighly faster; won ~3300-5600 ts on my 10+ sprite scene. wow. also, added compile-time switch to use unmasked sprites ("or" printing, no need to store sprite masks). tbh, i'm doing it all to avoid writing the documentation. ;-)

[ketmar]

I NEED YOUR HELP. PLEASE.

the spoiler below contains the draft engine reference. of course, this is not a full documentation, but it should give you some basic idea of the engine API. please, read it (if you have some free time), and tell me if you were able to make heads or tails of it. ;-) any questions/additions/notes are welcome: i'll try to improve the docs to answer them.

of course, the engine will have higher-level overview too, and some examples. at least i hope that i'll be able to write them. ;-)

WARNING! the text is quite big.

Spoiler

what is XT-Engine
=================

XT-Engine is small and fast game engine for writing tile-based games.

The engine supports maximum working area of 32x24 tiles, each tile is 8x8
pixels, with an attribute.

The engine can be used to write any type of non-scrolling tile-based game.
It can be flip-screen platformer, or top-down shooter (flip-screen too ;-),
or even something like Arkanoid. I.e. anything that can be expressed in
terms of tiles, and requires no scrolling.

The engine supports flicker-free masked sprites, and can render 10 24x16
sprites at ~20 FPS. There are compile-time options to add support for
sprites with smaller width, and to use non-masked sprites (printed with
"OR" instruction, like in Manic Miner/Jet Set Willy).

XT-Engine also has support for tile animation.


Engine Tilemap
==============

Internally, the engine keeps 32x24 working tilemap (one byte per tile). This
tilemap holds both tile flags (in bits 0-1), and tile codes (in bits 2-7).
I.e. tile code is shifted left by 2 bits. Also note that tile with code #0
always rendered as "clear all pixels" (i.e. it cannot have custom graphics,
but can have custom attributes).

The working tilemap can be modified to create tile animations (or to write
a game like Lode Runner/Arkanoid), or to collect collectibles.

There is also support for "always on top" tiles. Such tiles will block
sprite printing over them (i.e. the sprites will hide "behind" such tile).
This is completely transparent for you, just set "on top" tile flag, and
XT-Engine will do the rest.


xte_data_tilemap
----------------

Tilemap data, 32x24 bytes. This area is always aligned on 256-byte
boundary, and always 32 tiles wide.


Tilemap modification API
========================

COMING SOON.



MOBJs (active room sprites)
===========================

XT-Engine needs to know some info about your sprites. This info is gathered
in so-called "mobj struct", and active sprite is called "mobj" ("map
object", if you are curious about the abbrev.). MOBJ struct format is
described below.


mobj structure
--------------

db size ; size of the whole structure, including this byte
dw ai_func ; AI controller for this mobj
db spry ; sprite vertical coordinate, in pixels
db sprxt ; sprite horizontal coordinate, in tiles
db sprxo ; sprite horizontal offset (0-3) (see below)
db sprhgt ; sprite height, in pixels
db attr ; sprite attribute (see below)
dw sprgfxr ; address of sprite gfx table (see below)
db prmode ; (see below)
db cdmark ; used as "processed" mark in coldet, don't touch
bounding box:
db bb_xofs, bb_yofs ; unsigned offsets
db bb_wdt, bb_hgt ; unsigned sizes
the following two fields are used by `xte_process_mobjs_ai`:
db speed ; sprite speed (# of game frames to wait before moving)
db pleft ; set to speed, decremented on each ai loop
user data:
you can put any additional mobj data here
it is neither used, nor modified by the engine

sprxo
-----

This is "sprite offset". It can be in [0..3] range (inclusive), and both
selects the animation frame for the sprite, and specifies sprite horizontal
offset for bounding box checks. Minimal horizontal sprite step is 2 pixels.

attr
----

Sprite attribute. If `__XTE_OPT._SPRITE_WEAK_ATTRS` option is enabled,
FLASH bit has a special meaning: if it is set, sprite attributes will be
print only over tile with index #0 (i.e. empty one).

If the attribute is 0, it means "don't set sprite attributes".

prmode
------

Sprite width and printing mode.

If `__XTE_OPT._SPRITE_PRINT_MODES` option is enabled, you can set bit 4 to
print this sprite as "white mask only". I.e. only inverted mask will be
printed. This is useful to create "hit effects" when some projectile hit
the sprite.

If `__XTE_OPT._SPRITE_SMALL_WDT` option is enabled, bits 0-2 of this field
contains sprite width in chars. This is somewhat unusual, though: 3-char
wide sprite has width code 0. I.e. the meaning of bits 0-2 are:

0: 3-char wide sprite (24 pixels)
1: 1-char wide sprite (8 pixels)
2: 2-char wide sprite (16 pixels)
3: undefined, and reserved

Also, bit 7 of this flag has special meaning for bounding box collision
checks. If it is set, bounding box coldet API will ignore `sprxo` field.
This is useful for animated mobjs moving only vertically, because `sprxo`
is used to select animation frame in this case, but doesn't offset the
sprite position.



Rendering API
=============

xte_mark_tilemap_for_copying
----------------------------

Mark the whole tilemap for initial copying. Should be called after building
a new room, or such.

IN:
none
OUT:
AF,HL,BC,DE: dead


xte_force_all_ontop_render
--------------------------

Call this to force rendering of all "on top" tiles. You prolly won't need
to call this function manually, becase `xte_mark_tilemap_for_copying` will
do it for you, and you'd better use special "change tile" API for
animation.

WARNING! Internal API, do not use!

IN:
none
OUT:
AF,DE,HL: dead
B: 0


xte_set_tile_gfx_address
------------------------

Set tile graphics address (see above for the format). Should be called once
before "entering" a room. I.e. call this function, then build a new
tilemap, and then call `xte_mark_tilemap_for_copying`.

IN:
HL: address
OUT:
AF, DE, HL: dead


xte_render_frame
----------------

Render game frame. Sprite lists should be already prepared (see
`xte_build_mobjs_rowlist`).

Note that this function will use all registers except IY (including the
alternate register set).

It is safe to call this function with interrupts enabled, even in IM1 mode.

IN:
none
OUT:
AF,BC,DE,HL,AF',BC',DE',HL',IX: dead



Sprite List API
===============

Before rendering a frame, the engine needs to know which sprites are
active, and where they are. Each active sprite will use some memory, at
most XTE_SPL.sizeof*((sprite_height+7)/8+1) bytes. I.e. one 16-pixel high
sprite will use at most 42 bytes in working heap.

Each active sprite is described in "mobj struct" (see "structs description"
to know more). You can either place mobj structs one after another and
process them with one API call, or manually process each mobj struct, or
combine this two methods.


xte_set_spl_heap_start
----------------------

Set working heap starting address. The heap will grow to higher addresses
(i.e. from 0 to #FFFF). This is usally called on program startup.

IN:
HL: heap start address
OUT:
HL: heap start address


xte_build_mobjs_rowlist
-----------------------

Process mobj structs placed one after another, prepare rendering lists.

IN:
none
OUT:
everything is dead, except IY
this includes alternate regs (with AFx), and IX


xte_rowlist_insert_mobj
-----------------------

Process one mobj struct. The function above simply calls this one to do its
work, but you can manually call this function if you need to.

IN:
IX: mobj info struct address
OUT:
everything is dead, except IY
this includes alternate regs (with AFx), and IX


xte_process_mobjs_ai
--------------------

If you have your mobj structs placed one after another, you can use this
function to run their AI functions. Call this once per game frame.

IN:
none
OUT:
everything is dead, because AI controllers may do anything



Collision Detection API
=======================

XT-Engine supports two types of collision detection: using bounding boxes,
and pixel-perfect. Bounding boxes are faster.

Note that you should call this after `xte_build_mobjs_rowlist`, but before
`xte_render_frame`. Calling coldet API after rendering a frame will not
find any collisions, and calling this API before `xte_build_mobjs_rowlist`
will have undefined results.

Collision checks are done with one "main" mobj (usually the player, or a
projectile). The API can be stopped on the first found collision, or used
to enumerate all collisions.

Note that if there are more than one collision, the order in which they
will be returned is unspecified.

When the API detects a collision, it puts collider mobj struct address to
IX, and calls your callback function. Your callback should return with
CARRY flag set to stop further checks, or with CARRY flag reset if you want
to continue searching. The callback will be called only one for each
object.

Calling coldet API from callback itself is UB (i.e. this won't work).

Your callback is free to modify any registers.

You can call coldet API several times (up to 127), if you need to. Also
note that there is a little reason to "optimise" coldet by calling bounding
box API first, and then pixel-perfect: pixel-perfect API will not check
non-overlapping sprites anyway.


xte_coldet_bbox
---------------

Bounding box collision detection.

IN:
IX: mobj struct address
HL: collision response callback
OUT:
everything is dead, except IY (if your callback didn't modified it)
this includes all alternate regs (with AFx)


xte_coldet_perpix
-----------------

Pixel-precise collision detection. This is slower than bounding boxes, but
will allow you to write your own Jet Set Willy. ;-)

IN:
IX: mobj struct address
HL: collision response callback
OUT:
everything is dead, except IY (if your callback didn't modified it)
this includes all alternate regs (with AFx)

[Mpk]

Silly question time :

The readme says that

Code: Select all

WARNING! you need my UrAsm to build it! https://repo.or.cz/urasm.git

Why is that? If it's asm it should build in any compiler?

[ketmar]

Why is that? If it's asm it should build in any compiler?

mostly because i'm using some simple macros do avoid code duplicating, and struct defs, and such. those small things which are different amongst all asms. it won't be hard to adapt it to any other assembler that have conditional compilation and local labels, but i don't want to spend my time on that before i finish everything i planned. as it is just a tech demo yet, i thought that it will be easier to simply give people my asm so they could experiment with the thing.

currently, the engine has many compile-time options, and they affect both speed and size (the engine can be as small as ~1KB, or slightly bigger than 3KB with all features included), and contains some code duplication in sprite printing routines (for speed; but there is compile-time option to convert some dups to CALLs too).

as i am using my asm exclusively for decades, and simply don't know how macros and such work in others, i wrote the thing using the tool which i know best. i will try to provide sources for sjasm+/pasmo later (or what else people are using these days? point me in the right direction, please!)


p.s.: as nobody volunteered with gfx and game ideas yet (which i fully understand ;-), i decided to simply clone some existing games in XT-Engine, to show what could be done with it. i'll prolly write a Manic Miner clone (with one or two rooms), maybe simple Breakout (or Arkanoid, if you wish), and some top-down shooter/maze example. not a full games, but rather some demos of what is possible, and how to start.

[ketmar]

just4fun, list of available compile-time engine options. changing each option really changes the generated code and the execution speed, so you can create a custom engine for your game simply by changing some defines! ;-)

Spoiler

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; view area
;; while the tilemap is always 32x24 tiles, you can set view
;; area to be smaller, and place it anywhere on the screen
;; just make sure that it has at least one tile visible ;-)
;; X OFFSET/RESIZE COST: ~20 bytes

; view area size (32x24 max)
XTE_VIEW._WIDTH = 32
XTE_VIEW._HEIGHT = 24

; position on the screen (in chars)
XTE_VIEW._TOP = 0
XTE_VIEW._LEFT = 0

; window offset in the tilemap
XTE_VIEW._OFSX = 0
XTE_VIEW._OFSY = 0


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; renderer options

; if this is not zero, "flash" bit of tile attribute
; will have a special meaning: "always force tile attribute"
; "flash" will be reset, and any sprite attrs will be ignored
; this makes code slightly bigger, and slightly slower, so
; you can turn this off if you don't need this feature
; COST: ~56 bytes
__XTE_OPT._TILE_FORCE_ATTRS = 1

; if this is not zero, the engine supports "on top" tiles
; if this is turned off, setting flag "on top" for tile is UB
; COST: ~51 bytes
__XTE_OPT._TILE_ONTOP_FLAG = 1


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; sprite options

; if this is not zero, the engine will use only 16px wide sprites
; note that `_SPRITE_SMALL_WDT` is ignored if this is set
; TODO: support 8px wide sprites?
; COST: ~710 bytes
__XTE_OPT._SPRITE_WDT_ONLY_16PX = 0

; if this is not zero, sprites should not contain masks, and
; all sprites will be printed with "or"
; if you are using `_xte_mspr_XX` macro to define sprite gfx,
; you don't even need to change your sprite sources! ;-)
;
; WARNING! `__XTE_OPT._SPRITE_PRINT_MODES` MUST BE ZERO IF THIS IS SET!
;
; COST: ~52 bytes
__XTE_OPT._SPRITE_NO_MASK = 0

; if this is not zero, sprites will completely erase the tiles they touch
; (except the attrs, which are affected by the usual flags)
__XTE_OPT._SPRITE_ERASE_TILE = 0

; if this is not zero, "print mode" field sets sprite printing mode
; this is useful to make some enemies flash
; it makes sprite printing very slightly slower
; (adds several checks for each sprite)
; COST: ~311 bytes
__XTE_OPT._SPRITE_PRINT_MODES = 1

; if this is not zero, "flash" bit of sprite attribute has a
; special meaning: "print sprite attrs only over tile #0"
; it cost a little time for each sprite
; COST: ~66 bytes
__XTE_OPT._SPRITE_WEAK_ATTRS = 1

; if this is not zero, "print mode" field also contains
; codes for 16 and 8 pixels width sprites
; COST: ~548 bytes
__XTE_OPT._SPRITE_SMALL_WDT = 1

; if this is not zero, sprites will be properly clipped
; by the right screen border; otherwise they will simply disappear.
; COST: ~377 bytes
__XTE_OPT._SPRITE_RIGHT_CLIP = 1

; set this to non-zero to get smaller, but slower sprite printers
; COST: ~117 bytes
__XTE_OPT._SPRITE_SMALLER_PRINTERS = 0


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; collision detection options

; set this to 0 if you don't need bounding box collision detection
; COST: ~327 bytes
__XTE_OPT._COLDET_BBOX = 1

; set this to 0 if you don't need pixel-precise collision detection
; COST: ~606 bytes
__XTE_OPT._COLDET_PERPIXEL = 1

[Mpk]

Fair enough, thanks for the response.

(or what else people are using these days? point me in the right direction, please!)

I use Zeus, but I don't think that's very popular. I also compile with pasmo to try to avoid any compiler-specific non-standard practices.

[Turtle_Quality]

I use Zeus too.

I've noticed it will sometimes accept directives from other assemblers that are not in the Zeus docs, for instance dup and edup, apparently for compatibility.

Keep up the good work @Ketmar it's interesting reading

[ketmar]

I use Zeus too.

is there online documentation for it? sorry, i'm dumb, and didn't found it with quick searching.

Keep up the good work @Ketmar it's interesting reading

thank you! it's also a fully working engine too, it already exists! ;-) i need to finish documentation and demos to make the release. and i keep optimising the code (just won about 10ts per sprite line, and made the code smaller by several bytes). Z88DK integration would be nice too (yet i'm heavily using IX, and i'm not sure if Z88DK compiler will be happy with this ;-).

i also want to write a description of the algorithms and the inner workings of the engine, to make it easier for people to modify anything to fit their game better. the code is heavily commented, but high-level description never hurts. ;-)

[Mpk]

is there online documentation for it? sorry, i'm dumb, and didn't found it with quick searching.

Zeus lives at http://www.desdes.com/products/oldfiles/zeus.htm

It's a full IDE with inline debugging, breakpoints etcetera. Having everything in one package is really ideal for me.
There's a bunch of documentation files and samples at the link as well.

[ketmar]

Zeus lives at http://www.desdes.com/products/oldfiles/zeus.htm

thank you! sadly, it looks like the thing doesn't have any proper documentation besides the changelog (or i'm really blind), and i'm not ready to read 150+ kb of text to dig out how to do various things i need in Zeus (local labels, macros, structs). so prolly no Zeus version of XT-Engine. sorry.

[Mpk]

Zeus lives at http://www.desdes.com/products/oldfiles/zeus.htm

thank you! sadly, it looks like the thing doesn't have any proper documentation besides the changelog (or i'm really blind), and i'm not ready to read 150+ kb of text to dig out how to do various things i need in Zeus (local labels, macros, structs). so prolly no Zeus version of XT-Engine. sorry.

Structures :
http://www.desdes.com/products/oldfiles ... struct.asm
Macros :
http://www.desdes.com/products/oldfiles ... macros.asm
Labels / procedures :
http://www.desdes.com/products/oldfiles ... edures.asm

Agreed though, the documentation is spotty and conversational.

[ketmar]

oooh… they should tell people that examples are not simple dumps of assembler code, but contain explanations… i didn't even looked into them. thank you. small reference doc would be nice too, but eh, i can do it myself, i guess. ;-)

i wonder why they didn't adopted the common syntax for local labels (local labels are starting with dot, and reset by a new non-dot label)…

p.s.: also, are dots allowed in labels? (i don't have windows, so cannot test it myself; urasm .exe was compiled with MXE cross-compiler, and i didn't even ran it. ;-)

[Turtle_Quality]

Zeus does not like labels that contain dots - it's Windows title is "zeus z80 grumpy assembler"

Underlines "_" are okay, including labels that start with underline such as the following exciting example

_test :
jr _test

Zeus runs under Wine if that helps.

[ketmar]

Zeus does not like labels that contain dots

too bad. :-( it seems that it doesn't like everything i'm using… ;-)

[ketmar]

the progress somewhat stalled, because now i have to write the actual games… and writing clones is boring. (actually, writing games is boring… writing tools is fun! ;-)

p.s.: remainder: the code is still available in Fossil repo, XT-Engine is not vapourware! ;-)

[ketmar]

for some reason i wrote Yet Another Windowing and Menu System instead of examples. arrow-driven. arrow rendering takes ~11000ts max for 16x16 arrow (this includes restoring the screen at the old position, and saving at the new one), so the arrow won't flicker while moving. (no preshifted sprites!) also implemented proportional printing routine, even with simple kerning for things like commas. dunno why, don't ask me. that's how much i dislike to write something really usable! ;-)

Spoiler

p.s.: screen saving routine used to save the part under a window supports on-the-fly RLE compression, btw. most of the time windows are on top of each other and some empty space, so compression helps to win some backstore bytes.

[ketmar]

Tech Demo v0.0.3

brief changelog:

Spoiler

TECHNOLOGICAL BETA v0.0.3
* changed license to GPLv3. nobody will use XT-Engine anyway, so it doesn't matter.
* added some config options, reorganized sources, prefixed labels with "xte_".
* added "force tile attribute" flag ("flash" bit).
* added support for sprites with different height.
* added support for 16- and 8 pixels width sprites.
* option to use only 16 pixels wide sprites.
* support for masked or unmasked sprites (global compile-time switch for now).
* configurable view area.
* code optimisation, bugfixes.

[Mpk]

* changed license to GPLv3. nobody will use XT-Engine anyway, so it doesn't matter.

Think positive! I'm know that I'm planning to have a go at it, once I get some time. Hard to say when that will be, of course, but I'll get there.

[ketmar]

* changed license to GPLv3. nobody will use XT-Engine anyway, so it doesn't matter.

Think positive! I'm know that I'm planning to have a go at it, once I get some time. Hard to say when that will be, of course, but I'll get there.

yay! it would be great! ;-)

also, info for all: the license is negotiable. i mean, if you want your project to use some other license, i can give you a differenly-licensed XT-Engine version, for free! ;-) i just want to get some stats on "GPL-unhappy" people, so default is GPL.