I know not much has been stated here about any "official" CaDan workings, but I'm just letting y'all know that I've decided to restart the project. The aim is to make it easier to modify its assets so anyone can modify the project without much hassle. Also, to squish bugs and get it compiling under SPASM, which is my new favorite assembler/compiler.
So, to start things off, I'm taking a poll on what I intend on doing with the script system. The following is a crosspost from Omnimaga:
The real reason why I'm redoing CaDan is so geekboy can continue with his wonderful take on what the game was supposed to have been. He's complained (with good reason) that the current state of things is ... inadequate. Anyone listening in on HWCP this April 6th, 2011, will have an idea.
Also, it'll be a while before I can get screenies of the new code in action, because... code hasn't been written yet! I'm just announcing my intentions.
So, to start things off, I'm taking a poll on what I intend on doing with the script system. The following is a crosspost from Omnimaga:
Quote:
...
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?
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?
The real reason why I'm redoing CaDan is so geekboy can continue with his wonderful take on what the game was supposed to have been. He's complained (with good reason) that the current state of things is ... inadequate. Anyone listening in on HWCP this April 6th, 2011, will have an idea.
Also, it'll be a while before I can get screenies of the new code in action, because... code hasn't been written yet! I'm just announcing my intentions.