So now that I've announced that I'm restarting CaDan, let's get straight to the point, shall we?

The script system, which allows you to create those nice, beautiful patters, is in need of some serious overhauling. Thing is, there's a few limitations on what the system can do. We're here to hammer them all out.

At the moment, I suppose only geekboy happens to have enough knowledge about the script system to actually suggest much, but I'm open to suggestions from everyone else too! After all, it's a public thread, and everyone wants a piece of CaDan action!

Anyway...

Engine details:

* (NOTE) : Henceforth, the term "register" is referred to with respect to the virtual chunks of memory with which the script system has to work with.
* Four one-byte registers reserved.
* All bullet trajectories are done in polar coordinates, with a fixed velocity.
* Instructions used to load a register with the angle needed to shoot a bullet that would intersect with the player's current position.
* Mathematical operations. At the moment, only ADD is supported, since one can always add with a negative number to achieve it.
* Bitwise logical instructions. Only AND is supported.
* Program flow changing instructions, including an unconditional jump (goto) and conditional jumps (jump), with which mathematical operations may affect the "flags". Contains subroutine instructions, but they aren't very intuitive, and requires quite a bit of keeping track of.
* Pause instructions, both single cycle and multi-cycle.
* Special memory access, given a table of allowed values to change. Originally a way to coordinate attacks between boss scripts and enemy scripts.
* Boss setup and spellcard instructions, used to load special pattern tables. They get their own registers.
* Boss takedown and special effects, including explosions and return to stage.
* Stage setup and progression instructions, including background changes, and enemy/boss creation.
* A way to run actual Z80 ASM code.

What is planned in the reboot:
* Full 8 register setup. Stage scripts will be allowed to have two banks of these, accessed by special exchange instructions.
* Spellcard animation scripts, including a fully working sprite routine and background change instructions. They get their own set of registers. Spellcards have been rather... neglected.
* Register to register support for load and math/logic instructions.
* Support for XOR and OR routines, along with actual subtraction routines. We'll go for some real multiplication and division routines, while we're at it.
* Rotation. For extracting nibbles.
* Support for relocatable scripts and associated assets.

What has been suggested in the reboot:
* Support for jump tables and loops similar to C's SWITCH command.
* Second 128 bullet table and modified interrupt scheme to handle it, accessible via slowdown command.
* Tilemapped dynamic backgrounds

What do you think? Would you suggest something else? Or more?

EDIT: Added elements to table.

more ideas these are ones we have discused over irc a bit so just reiterating

1) External level support i mean we have that CaDanite thread down below ^_^ (once the scripting system is finalized and we have the set up for external scripts maybe ill make that as an asm project I want to learn asm now so might be a good idea)

2)Replays got to have replays and if the system is like it was this time that shouldn't be to hard to add

3) a easy way to add NoClip for practice/tasing / pure lazyness

^_^ more coming eventually xD

Well for the slow down thats interesting and can be done as thats based on a piece of data in ram

as for fireballs i can already "kinda" do that with the current engine it would be hackish but its doable but a better system for special bullet types would be loved

Double-post. Will be like a week or two more. School and work and all that business.

well after poking Dan in an Email (Dwedit) we got this

"Spiffy compression" is actually very bad.  I'd gladly purge it from the face of the internet if I could.

Anyway, I'm just responding to let you know about a new compression method I've been trying out since then.

A while ago, I was reading a neat article about image data compression, this page suggests using prediction combined with bit-level RLE to compress images:
http://hbfs.wordpress.com/2009/04/14/ad-hoc-compression-methods-rle/

So I had implemented this compression method, I wanted to see how well it did.  I had to modify this compression method for 1-bit images.

I used this test image:



The compression method works by creating a predicted image by looking at the current pixel, the pixel to the left, and the pixel above the current pixel.



After you make a predicted image, you can compress that, and it compresses better than a regular image.
After you decompress it, you need to also un-predict it back to a normal image.

The compression method used is RLE, when you see two of the same bit, it starts an RLE run, just like the algorithm described on that page.

The Bubble Bobble title screen there compresses to 601 bytes, which beats WinRAR by 36 bytes.

I've written a compressor in C#, but I haven't written any decompressors in Z80 yet.  Are you interested in me writing one?
By the way, the compression method works much better on higher bit depths, like NES or Gameboy 2bpp images, because the predictor emits far more zeroes than anything else, and you can take advantage of that.

Good luck on your game!

Thats actually looking really promising i wonder what the requirements on calc would be though ram wise? More emailing away xD