Language…
7 users online: Danik2343, DinoMom, Firstnamebutt, masl, Odinstafel, Saibot1997, Zavok - Guests: 215 - Bots: 326
Users: 64,795 (2,380 active)
Latest user: mathew

Discussion of Tessera, my new Sprite Tool (updated)

I think it would be better if fiddling with default sprites were optional patches, but still sounds useful to me.

As a side note, relating to the poison mushroom sprite, I wonder if it would be better to use stack shenanigans to call parts of SMW's sprite code directly instead of disassembling it when you want to make a variant. I was thinking of doing that to make a customizable powerup sprite, because good luck doing a full disassembly of that thing the way it jumps around all over the place.
Your layout has been removed.
Actually, I decided to forgo the modified init routines in favor of simply changing each one's ending RTS to RTL. I did modify the init routine for the goal tape, though, since it uses the extra bits. (This also means that the goal tape uses an extra byte, so be warned!) I also finally finished repointing everything, which took quite a while. Some sprites might run slightly faster, though, particularly some of the bank 3 ones.

Also, I'm thinking of adding support for a new sprite format. Instead of a .cfg file read as text, it would be a binary file containing the standard 9 bytes (acts-like setting, Tweaker bytes, extra property bytes) plus a few extra bytes for more custom stuff. "More custom stuff" -> I may add support for custom sprite clipping and object clipping, as well as two extra Tweaker tables. That's only a thought, though. In the meantime, I'm not sure what the file extension for the new file would be...".scfg" was my pick, but that could change.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Binary .cfg files? What, you want to make cfg files even HARDER to fiddle with?

Also, I still disagree with modifying old sprites, at least too much. Mostly because other things may fiddle with them, and it sounds harder to remove. Instead it makes more sense to me to make wrapper functions instead, and using stack tricks. Then again, if it works, it works.

I do have a growing apprehension about what this will do with existing hacks though.
Your layout has been removed.
Keep the existing format unless you've got a very good reason to change it ("I feel like it" does not count as "very good"). Forcing people to edit every single CFG file in the sprite section will just be annoying.
And I happen to like the ability to easily edit the filenames with Notepad. It'll just confuse me if people start using a binary format.
<blm> zsnes users are the flatearthers of emulation
Well, it would still support both formats. You'd just have the option to use the other. But you know, if you set a default program, you can edit binary files just as easily as you can text files. My main reason for adding the extra format was that they would be easier to parse. The whole .cfg thing was an arbitrary decision made by mikeyk anyway. As for existing hacks...yeah, anyone who has any goal tapes or non-normal sprites (shooters, generators, run-once sprites, cluster sprite generators, scroll sprites) in levels will have to remove them and reinsert them after running the tool. Every other sprite should transfer fine.

Also, what do you guys think of the "more custom stuff" (i.e. custom sprite and object clipping, two extra Tweaker tables)? This would be optional (usable by adding four extra bytes to the sprite file), and I doubt I'll even include it in this version anyway.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Supporting two formats, one that's easier to parse and one everyone uses?
Something about that feels a bit wrong. Assuming you care about backwards compatibility, you'll need to support the old format anyways. I can't see how supporting two formats is easier than supporting one, but whatever. It's your tool, you don't need to agree with my opinions.
<blm> zsnes users are the flatearthers of emulation
Personally, I think the cfg file should be even MORE textual, with a property=value format instead of a meaningless list of numbers. But that's just me. :P Alcaro is right though, making a "easier to parse" format then supporting both formats anyway is just silly.

As for "more custom stuff", personally I would rather a basic sprite tool perhaps with possible extensions instead of a whole bunch of new stuff. Come to think of it, I wonder if a plug-in system and/or extendable tables is out of the question? Instead of implementing all this in a base pre-compiled patch, maybe call xkas directly to insert things and have a simple way to define patches? I donno.

Bah, I should just shut up and see what happens.
Your layout has been removed.
Some kind of .ini or .xml based format would be neat to allow future expansions to the format in a not-completely-tacked-on way. Switching to a binary format seems to make it way less user friendly for no reason other than, to be frank, laziness. Come on, parsing something like this:

setting1 = 12345
omgwtf = bbq.214
herpa=derp

is laughably trivial. Even an .ini-like category system is easy. .xml may be overdoing it a bit, though.
God I don't even think about xml for config files. Yes xml may be good for structured data, but even then I think it's just too damn verbose and redundant to be useful. For config files isn't just overdoing it, it's taking a orbital laser and blowing up the whole planet it's on.

Anyway, having a ini-like config format might also be nice for specifying flags and other values like the palette explicitly as well, instead of only the raw bytes (though that should be an option too).

But eh, I am just wishlisting now.

Also: On a unrelated note, does any one think a community CVS system for utilities like this is a good idea? Would anyone actually use it?
Your layout has been removed.
Originally posted by KilloZapit
making a "easier to parse" format then supporting both formats anyway is just silly.

People would have a cow if I supported only the new format, though.

Originally posted by Smallhacker
setting1 = 12345
omgwtf = bbq.214
herpa=derp

Yeah, I could do that. But would that really be any better? It would either be this:

Code
Sprite1656Val = 01
Sprite1662Val = A3


or this:

Code
SpriteClipping = 4
CanBeJumpedOn = 0
DiesWhenJumpedOn = 0


The first one wouldn't be any more useful than the current format, and while the second one would be time- and space-consuming, the same effect could be achieved by simply using the .cfg editor. In fact, what can any of these "more textual" formats do that the .cfg editor can't? And I still say that simply setting a certain file extension to open with a hex editor is just as trivial as having it in text format in the first place.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
But the only reason people use the cfg editor is because the format isn't self explanatory, plus as smalls pointed out, a property=value format is easy to expand. And yeah, my thought was more along the lines of the second example.

Honestly it's a minor thing anyway, so whatever.
Your layout has been removed.
You're thinking something like this?

Code
Assembler: xkas

Acts like: 36

Object clipping value: 0
Can be jumped on: False
Dies when jumped on: False
Hop in/kick shells: False
Disappear in cloud of smoke: False

Sprite clipping value: 00
Use shell as death frame: False
Falls straight down when killed: False

Use second graphics page: False
Palette: 8
Disable fireball killing: False
Disable cape killing: False
Disable water splash: False
Don't interact with Layer 2 objects: False

Don't disable clipping when killed with star: False
Invincible to star/cape/fire/bouncing bricks: False
Process when offscreen: False
Don't change into a shell when stunned: False
Can't be kicked like a shell: False
Process interaction with the player every frame: False
Gives a powerup when eaten by Yoshi: False
Don't use the default interaction with the player: False

Inedible: False
Stay on Yoshi's mouth: False
Weird ground behavior: False
Don't interact with other sprites: False
Don't change direction if touched: False
Don't turn into coin when goal passed: False
Spawns a new sprite: False
Don't interact with objects: False

Make platform passable from below: False
Don't erase when goal passed: False
Can't be killed by sliding: False
Takes 5 fireballs to kill: False
Can be jumped on with upward Y speed: False
Death frame 2 tiles high: False
Don't turn into a coin with silver P-switch: False
Don't get stuck in walls if carriable: False

Extra property byte 1: 00
Extra property byte 2: 00

Custom sprite clipping value: 00
Custom object clipping value: 00

Bit 0 of seventh Tweaker table set: False
Bit 1 of seventh Tweaker table set: False
Bit 2 of seventh Tweaker table set: False
Bit 3 of seventh Tweaker table set: False
Bit 4 of seventh Tweaker table set: False
Bit 5 of seventh Tweaker table set: False
Bit 6 of seventh Tweaker table set: False
Bit 7 of seventh Tweaker table set: False

Bit 0 of eighth Tweaker table set: False
Bit 1 of eighth Tweaker table set: False
Bit 2 of eighth Tweaker table set: False
Bit 3 of eighth Tweaker table set: False
Bit 4 of eighth Tweaker table set: False
Bit 5 of eighth Tweaker table set: False
Bit 6 of eighth Tweaker table set: False
Bit 7 of eighth Tweaker table set: False


And...

Quote
a property=value format is easy to expand.

So is a binary file...

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
You're thinking something like this?

Code
Assembler: xkas

Acts like: 36

Object clipping value: 0
Can be jumped on: False
Dies when jumped on: False
Hop in/kick shells: False
Disappear in cloud of smoke: False

Sprite clipping value: 00
Use shell as death frame: False
Falls straight down when killed: False

Use second graphics page: False
Palette: 8
Disable fireball killing: False
Disable cape killing: False
Disable water splash: False
Don't interact with Layer 2 objects: False

Don't disable clipping when killed with star: False
Invincible to star/cape/fire/bouncing bricks: False
Process when offscreen: False
Don't change into a shell when stunned: False
Can't be kicked like a shell: False
Process interaction with the player every frame: False
Gives a powerup when eaten by Yoshi: False
Don't use the default interaction with the player: False

Inedible: False
Stay on Yoshi's mouth: False
Weird ground behavior: False
Don't interact with other sprites: False
Don't change direction if touched: False
Don't turn into coin when goal passed: False
Spawns a new sprite: False
Don't interact with objects: False

Make platform passable from below: False
Don't erase when goal passed: False
Can't be killed by sliding: False
Takes 5 fireballs to kill: False
Can be jumped on with upward Y speed: False
Death frame 2 tiles high: False
Don't turn into a coin with silver P-switch: False
Don't get stuck in walls if carriable: False

Extra property byte 1: 00
Extra property byte 2: 00

Custom sprite clipping value: 00
Custom object clipping value: 00

Bit 0 of seventh Tweaker table set: False
Bit 1 of seventh Tweaker table set: False
Bit 2 of seventh Tweaker table set: False
Bit 3 of seventh Tweaker table set: False
Bit 4 of seventh Tweaker table set: False
Bit 5 of seventh Tweaker table set: False
Bit 6 of seventh Tweaker table set: False
Bit 7 of seventh Tweaker table set: False

Bit 0 of eighth Tweaker table set: False
Bit 1 of eighth Tweaker table set: False
Bit 2 of eighth Tweaker table set: False
Bit 3 of eighth Tweaker table set: False
Bit 4 of eighth Tweaker table set: False
Bit 5 of eighth Tweaker table set: False
Bit 6 of eighth Tweaker table set: False
Bit 7 of eighth Tweaker table set: False


Well I wouldn't name something "Bit 0 of seventh Tweaker table set", probably would use shorter names in general without spaces, use the "=" instead of ":" and it would be useless to explicitly define things as false if that was the default, but otherwise, yeah. That sprite would probably look more like this:
Code
Assembler = xkas
ActsLike = 36
Palette = 8


Come on, you were just trying to make it look overly verbose and you know it.

Originally posted by imamelia
Quote
a property=value format is easy to expand.

So is a binary file...


No, you just expand the file not the format. :P *shot for being a wiseass*
Your layout has been removed.
Originally posted by KilloZapit
Come on, you were just trying to make it look overly verbose and you know it.

Um, no...

Originally posted by KilloZapit
it would be useless to explicitly define things as false if that was the default

No, I'd still have every option there. It would be easier to see what all the options are so they could be changed if necessary.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
I guess that would make a good example file at least. Anyway why am I still talking about this? I am shutting up now.
Your layout has been removed.
All right, I think I got custom sprites working. I'm not 100% sure it works, but I didn't get any bugs when I tried it out. Here's the patch, if you're curious or want to test it (and I would gladly welcome testers).

Now comes the hard part...coding the tool itself...

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Okay, this...freaking...SUCKS. I've had plenty of problems with the tool coding before, but now I simply cannot figure out a good way to get the size of a sprite's .asm file (or the installed hacks, for that matter) once assembled. It apparently didn't occur to byuu that maybe somebody would want to assemble something without it being padded to a multiiple of 0x8000 bytes, and apparently there is no good way to read command-line output in Perl and on Windows. Um, how many people would be disappointed if I just released the ASM source and said to heck with the tool itself? This is a huge freaking pain in the butt.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Oh..how unfortunate. Ever since you mentioned something that you would make an NPC sprite which is compatible with RPG Hacker's VWF Dialogues patch, I couldn't wait for your new sprite tool. I don't know any programming, so I can't help you with this problem, but I sincerely hope that somebody can help you with this... I don't know how hard it would be to work around with an ASM source, but since I definitely want to use NPCs with VWF Dialogues, I might end up using it... Of course, something like Romi's sprite tool would be much better.
Either way, best luck.
I don't know how good Perl is at reading/writing files and such, but one thing you could try doing is internally have the program add "db $42" or something similar at the end of the sprite file. The size of the compiled sprite would be everything up to the last instance of $42.

Example: If you had a sprite that was just

Code
INIT: RTL
MAIN: RTL


Have the program add some dummy byte onto the end just before it has xkas compile it.

Code
INIT: RTL
MAIN: RTL

db $42


Now you know exactly where the file ends; it ends exactly where the final $42 is in the compiled file. Read the file, trim everything after and including the $42, and insert that into the ROM.

EDIT: But I would have no problem with just using a patch, assuming it's simple to use. It seems like it would be faster than a tool, if at the expense of user-friendliness (so maybe release both if possible?).
I should get a new layout.

Probably won't, though.
This is why SMWC needs its own standardized assembler, custom-made to fit our needs as opposed to the needs of a homebrewer.