241
CaDan SHMUP / Re: Script system ideas
« on: April 14, 2011, 01:59:58 pm »
Spending some time drafting up the script system specs. Will be a few days before I can get anything out with respect to that.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to. 241
CaDan SHMUP / Re: Script system ideas« on: April 14, 2011, 01:59:58 pm »
Spending some time drafting up the script system specs. Will be a few days before I can get anything out with respect to that.
242
CaDan SHMUP / Re: Yet another shooter« on: April 09, 2011, 12:11:38 am »
Hehe. I'll be making a new thread once I actually get code down on the new CaDan. For this edition, I'll be using SPASM to perform the compile job, since I've fallen in love with it after beginning the E:SoR reboot.
It'll be tough to keep this up and still have to deal with two jobs, but I'm sure I'll be able to get something going. 243
CaDan SHMUP / Script system ideas« on: April 09, 2011, 12:09:08 am »
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. 244
CaDan SHMUP / Re: Yet another shooter« on: April 08, 2011, 11:48:52 pm »
This project is being restarted.
Reasons: (1) Major pain in the arse to modify assets (2) Too many bugs in the script system (3) Compiles using TASM. 'nuff said. 245
Escheron: Shadow over Ragnoth / Re: Escheron: Shadow over Ragnoth« on: April 08, 2011, 11:46:43 pm »
I'm going to have to put this project on hold for a while. Gonna spend time rebooting CaDan.
246
Humour and Jokes / Re: Pucrunch Decompressor Axiom features the Nommer of Fishies« on: April 01, 2011, 11:23:58 pm »Dammit, I can't read this because Persona 3 is still on my to-play list. Grr. Must play Persona. (Mucho thanks for marking spoilers, though. Honestly, FF.net almost ruined Fire Emblem for me.)I don't think there's too many spoilers about either works, unless you consider an indirect reference to an important event a spoiler. EDIT: Finally got it published on FF.net : http://www.fanfiction.net/s/6878194/1/A_Short_His_Persona I guess I ought to write more fanfiction or something. Feels decent. Else, I should work on more code. Also, the system seems to filter out "IgnoreME.txt" for some odd reason... 247
The Axe Parser Project / Re: [Axiom] Pucrunch Decompression and tools« on: March 29, 2011, 11:35:36 am »I downloaded your Axiom and was looking at the ReadME for it, and I found that the program read from external files in archive. While it is still quite useful in this form, I have a feature request: could we read the compressed data inline so that we can package the whole program as a single file, under the 8811 byte limit? Thanks.That's a pretty good suggestion. Funny thing is, that's the way the pucrunch decompressor was originally coded. I think it should be easy enough to add in. Just gotta find some time to do it. 248
The Axe Parser Project / Re: [Axiom] Pucrunch Decompression and tools« on: March 28, 2011, 05:38:06 pm »Quote from: pudecomp/ReadMe.txt Q: When will you write a Pucrunch compression Axiom?It was already answered in the ReadME, but I understand the fact that many people might not even download the file and read it unless they're convinced that it's the right thing for them. Still, it was hard enough modifying the pucrunch decompresser to work as an Axiom. On the idea of compressors, there's probably a reason why the compressor is written in C (not assembly of any sort). If you could point me to a good C to Z80 cross-compiler, I might consider it only for writing a standalone compressor. If you tried to use it as an Axiom, I will guarantee you. The Axiom will end up eating more space than anything you could possibly code up. Now... if I wanted a good exercise, I might just write a standalone compressor in Z80 ASM anyway. If DJ_O starts asking why E:SoR isn't getting anyone done, I'll start blaming everyone involved. Including the Nommer of Fishies. 249
The Axe Parser Project / Re: [Axiom] Pucrunch Decompression and tools« on: March 28, 2011, 12:40:34 pm »I might be an enormous noob, but could you also provide a link to the compressor of Pucrunch (I have never heard of Pucrunch)It's in the archive. DecompAx\pc\pucrunch.exe Instructions are in the IgnoreMe.txt file. Details regarding pucrunch can be found here: http://www.cs.tut.fi/~albert/Dev/pucrunch/ 250
The Axe Parser Project / [Axiom] Pucrunch Decompression and tools« on: March 28, 2011, 12:20:55 pm »
Just to say. I'm in love with the idea of using pucrunch for just about everything that could be compressed. Bitmaps, tilemaps, text, it mattered not. I use it for just about everything. After messing around with it in CaDan and E:SoR, and after writing the Athena installer, I figured I might as well write an Axiom to do the decompression as well.
So here we have it. Something that decompresses pucrunch-compressed data. Useful for large games with tons of data files. Contains two versions of the pucrunch decompressor, one for use in RAM and one for use as a Flash Application (Axe will automatically select the correct version). Contains tools that you can use on the PC side of things to compress and package what you want. 251
Humour and Jokes / Pucrunch Decompressor Axiom features the Nommer of Fishies« on: March 28, 2011, 10:36:20 am »
Just so you know, I'm a fan of the movie How to Train Your Dragon, and I've played Persona III, so I figured how well it would be for the characters in that movie to have the sort of problems presented in that game. I haven't really fully thought out the idea so it rested on the backburners of my imagination. Now, keep in mind that I'm a Z80 ASM coder, not a storyteller. So with what little I had, I ... uh. Really didn't do much. That was...
Some odd night a few days ago, I was working on a pucrunch decompressor Axiom and I thought about something. Completely random. Very random. So I put it here in the randomness subforum. An exact copy is found in that project's "IgnoreME.txt" file, which is... well. An alternative to the "ReadME.txt" file (it exists too!). I would post this mess on fanfiction.net, but I'm not sure if it would be classified as a crossover. The content sure indicates that, but no characters are being used from PIII. Just didn't feel like it. So anyway, the copy from my file (make sure the screen's width is set to be able to display 80 columns). Tell me what you think about my randomness. EDIT: May contain a spoiler or two from both titles. Code: [Select] ___________ 252
Escheron: Shadow over Ragnoth / Re: Escheron: Shadow over Ragnoth« on: February 24, 2011, 08:38:48 pm »
The stats that needs to be calculated are already well-defined in the design documentation of the project, provided by Zera. Everything is defined to excruciating detail, so nothing is missed. Much of the calculations can and will fit inside 8 bits, but for that off chance, things extend to 16 bits during calculation.
As far as the 255 and 65535 thing goes, we ASM programmers have very novel ways in making sure they don't go past that without any of us knowing. This isn't to say these things cannot happen. They sometimes do and they cause much strife and grief in debugging them. When damage isn't expected to rise higher than 1024 and no stat can exceed 255 (the sole exceptions being enemy HP and current GP), it's hard to imagine anything going past 65535. So the issue isn't making up statistics and having them flow together. The real issue is implementing the rock-solid plan that came before coding ever started. EDIT: The design documentation that I speak of is going to be kept secret until I release the source for E:SoR, which hopefully won't happen until after the game is released. 253
Escheron: Shadow over Ragnoth / Re: Escheron: Shadow over Ragnoth« on: February 21, 2011, 08:08:22 pm »
I'm not trying hard enough. Gotta get some stuff out of the way before I can continue. The most pressing matter is recreating stat calculations and the like.
254
ASM / Re: CheckFindSym problem« on: February 19, 2011, 10:54:16 pm »
Have you tried re-chkfindsym'ing the files between the copy? Creating variables changes pointers in RAM, so after creating anything, any previous pointer is invalidated. You need to check again. Just my thoughts.
255
The Axe Parser Project / Re: ERR:?« on: February 09, 2011, 11:52:59 pm »
Not totally sure how this would apply, but I've gotten that error before. It was due to some faulty input to a _ChkFindSym romcall. Not sure what else could trigger that error, but the TI-OS does have error checking for strange things like that.
|
|