Banner
Views: 304,984,575
Time: 2014-07-26 02:06:20 AM
16 users online: aj6666, Bio, crimental1, o Dotsarecool, o Everest, gesundheit, gridatttack, leictreon, leod, Luigi1000, Mario Master 12, Rextep, o Richard Nixon, S.R.H., Skelux, Zerio - Guests: 21 - Bots: 60Users: 25,311 (1,235 active)
Latest: komodore
Tip: You can insert custom sprites on the overworld by using Overworld SpriteTool.
Discussion of Tessera, my new Sprite Tool (updated)
Forum Index - SMW Hacking - Resource and Tool Releases - Discussion of Tessera, my new Sprite Tool (updated)
Pages: « 1 2 3 4 5 6 7 8 »
Originally posted by DiscoMan
I think that Tessera should be compatible with the older sprites because most of sprites will be unused. I could use Tessera if it's compatible with older sprites since I've an full list of sprites that use both TRASM and xkas.

I don't ever plan on including TRASM support...that assembler just sucks too much. bass (and chasm if it's ever finished), yes. But I do plan to convert a large number of the old sprites to a form that works in this tool.

Which other types of sprites would be useful enough to include in Tessera? Extended sprites and cluster sprites go without saying, but the rest...? I almost forgot about overworld sprites; I'd have to look into how those are handled and get a working hack for custom overworld sprites. Besides that, though, there are minor extended sprites, score sprites, bounce sprites, smoke images, and spinning coins. At least the first two are certainly worth considering; the rest, maybe not.

Also, I'm seriously considering not even making it an option whether or not the two No More Sprite Tile Limits patches and the shared subroutine patch are installed. There are no known disadvantages to the first two, and every sprite I made or will make for the tool requires shared subroutines anyway.
Originally posted by imamelia
the two No More Sprite Tile Limits patches

I only know of one. Which is the other?
...you're not thinking of the one Kaijyuu made that requires editing every single graphics routine ever, right?
The other one is the one I made for sprite types that use the $0200 block.
Originally posted by imamelia
Originally posted by DiscoMan
I think that Tessera should be compatible with the older sprites because most of sprites will be unused. I could use Tessera if it's compatible with older sprites since I've an full list of sprites that use both TRASM and xkas.

I don't ever plan on including TRASM support...that assembler just sucks too much. bass (and chasm if it's ever finished), yes. But I do plan to convert a large number of the old sprites to a form that works in this tool.

Which other types of sprites would be useful enough to include in Tessera? Extended sprites and cluster sprites go without saying, but the rest...? I almost forgot about overworld sprites; I'd have to look into how those are handled and get a working hack for custom overworld sprites. Besides that, though, there are minor extended sprites, score sprites, bounce sprites, smoke images, and spinning coins. At least the first two are certainly worth considering; the rest, maybe not.

Also, I'm seriously considering not even making it an option whether or not the two No More Sprite Tile Limits patches and the shared subroutine patch are installed. There are no known disadvantages to the first two, and every sprite I made or will make for the tool requires shared subroutines anyway.


TRASM isn't that hard to convert to xkas. Xkas<->Bass is harder. Really though, as long as it's able to export bin files with the right pointers it shouldn't matter.

As for other types of sprites and installed patches, I have said it before, but it might be easier to just design the tool as more a general insertion tool with some sort of plug-in support. Because if your going to do those other types of sprites, it's not really that much of a stretch to add block support or levelasm or who knows what else.

Though one type of sprite I think would be useful is a "library sprite". A sprite that only exists as a container to call asm code by sprite number or something. It would be helpful for stuff like VWF Tool's sprites, though I don't know if anyone uses that anymore.
Last edited on 2011-09-14 10:46:30 AM by KilloZapit.
Originally posted by KilloZapit
As for other types of sprites and installed patches, I have said it before, but it might be easier to just design the tool as more a general insertion tool with some sort of plug-in support. Because if your going to do those other types of sprites, it's not really that much of a stretch to add block support or levelasm or who knows what else.

That might be a good idea...if I had a clue how to do such a thing.

Originally posted by KilloZapit
Though one type of sprite I think would be useful is a "library sprite". A sprite that only exists as a container to call asm code by sprite number or something. It would be helpful for stuff like VWF Tool's sprites, though I don't know if anyone uses that anymore.

I'm not sure what you're getting at here, but it could be useful.

Well, I think I can pretty much guarantee that the next version will have the ability to insert custom cluster, extended, and minor extended sprites as well as custom sprite clipping. Score sprites are debatable, and I currently don't know enough about the object clipping routine to customize it. Anything else is unlikely at best.
Originally posted by imamelia
Originally posted by KilloZapit
As for other types of sprites and installed patches, I have said it before, but it might be easier to just design the tool as more a general insertion tool with some sort of plug-in support. Because if your going to do those other types of sprites, it's not really that much of a stretch to add block support or levelasm or who knows what else.

That might be a good idea...if I had a clue how to do such a thing.

I would say your pretty close to doing it already. You already have tons of asm you seem to compile and patch to the rom while allowing the tool to build tables. All you have to do in generalize. Make a file that lists the asm files to include and what tables you need. I guess it's a bit trickier then that. You could even list perl files to include to process lists I guess. Might be more trouble the it's worth, might not. I donno.

It's just if your going to have all this vastly vastly different types of things you can insert, there is little reason not to generalize it as much as possible.
Originally posted by KilloZapit
I would say your pretty close to doing it already. You already have tons of asm you seem to compile and patch to the rom while allowing the tool to build tables. All you have to do in generalize. Make a file that lists the asm files to include and what tables you need. I guess it's a bit trickier then that. You could even list perl files to include to process lists I guess. Might be more trouble the it's worth, might not. I donno.

Most of them are interlinked, though. Really, the only things that don't go into the ROM automatically are the few optional patches, and those might not even stay optional.

Originally posted by KilloZapit
It's just if your going to have all this vastly vastly different types of things you can insert, there is little reason not to generalize it as much as possible.

Well, everything that can be inserted is a sprite; it is a sprite tool, after all.

Also, two things: One, should I even have options to insert or not insert the shared subroutine patch and No Sprite Tile Limits patch(es)? Pretty much every sprite I've made or will make for Tessera requires the former, and the latter is just all-around useful. It might be better to make the tool just insert them automatically. That brings me to the second thing: dynamic sprites. I'm sure that patch won't be inserted automatically, but it should at least be an option. Should I keep the current dynamic sprite patch, though? p4plus2 brought up an excellent point when he said that the creators should have, rather than DMAing data from ROM to RAM during normal gameplay and DMAing it again from RAM to VRAM during V-blank, simply set a pointer to the data during normal gameplay and process it during V-blank. That would save a lot of cycles and a lot of RAM, although it might make the time spent in V-blank very slightly longer. Considering that the one dynamic sprite that has a Tessera-compatible version is one I modified, that I'll probably do all the others anyway, and that very few people make dynamic sprites, it doesn't seem like it would be much of a problem for anyone except people who already have dynamic sprites in their hacks...and even then, they'd most likely have to port before using Tessera anyway (and I haven't seen a single use of that particular sprite in a hack). It doesn't seem like such a patch would be very difficult to make.
Originally posted by imamelia
Originally posted by KilloZapit
I would say your pretty close to doing it already. You already have tons of asm you seem to compile and patch to the rom while allowing the tool to build tables. All you have to do in generalize. Make a file that lists the asm files to include and what tables you need. I guess it's a bit trickier then that. You could even list perl files to include to process lists I guess. Might be more trouble the it's worth, might not. I donno.

Most of them are interlinked, though. Really, the only things that don't go into the ROM automatically are the few optional patches, and those might not even stay optional.

I think it's probably a good idea to try and sort out what needs what and how to conditionally patch things anyway, because I think it's going to be harder and harder to sort though bugs and to expand the tools function if it gets more convoluted. Plus I can't say I am happy with the idea of patching a bunch of weird stuff I don't quite understand or need. Trouble is going to be removing it after words unless you make a undo ips patch for each rom I guess.

Originally posted by imamelia
Originally posted by KilloZapit
It's just if your going to have all this vastly vastly different types of things you can insert, there is little reason not to generalize it as much as possible.

Well, everything that can be inserted is a sprite; it is a sprite tool, after all.

Also, two things: One, should I even have options to insert or not insert the shared subroutine patch and No Sprite Tile Limits patch(es)? Pretty much every sprite I've made or will make for Tessera requires the former, and the latter is just all-around useful. It might be better to make the tool just insert them automatically. That brings me to the second thing: dynamic sprites. I'm sure that patch won't be inserted automatically, but it should at least be an option. Should I keep the current dynamic sprite patch, though? p4plus2 brought up an excellent point when he said that the creators should have, rather than DMAing data from ROM to RAM during normal gameplay and DMAing it again from RAM to VRAM during V-blank, simply set a pointer to the data during normal gameplay and process it during V-blank. That would save a lot of cycles and a lot of RAM, although it might make the time spent in V-blank very slightly longer. Considering that the one dynamic sprite that has a Tessera-compatible version is one I modified, that I'll probably do all the others anyway, and that very few people make dynamic sprites, it doesn't seem like it would be much of a problem for anyone except people who already have dynamic sprites in their hacks...and even then, they'd most likely have to port before using Tessera anyway (and I haven't seen a single use of that particular sprite in a hack). It doesn't seem like such a patch would be very difficult to make.


I think you should totally rewrite the dynamic sprites thing. After all, you already more or less discarded most backwards compatibility, so you might as well redo it from scratch. As I said before, I think shared subroutines work better as something like library sprites, or some other method of inserting shared routines dynamically. I guess it doesn't really matter though. As for the No Sprite Tile Limits patch, I don't see the harm in making that optional, but available by default.

Really, I just see it becoming problematic if the tool just inserts patches willy nilly. It leaves the user without much control or understanding about what is inserted. It's the same problem I have with LM sometimes, I just don't feel I am in control or have a good idea of where everything is.
Originally posted by KilloZapit
I think it's probably a good idea to try and sort out what needs what and how to conditionally patch things anyway, because I think it's going to be harder and harder to sort though bugs and to expand the tools function if it gets more convoluted. Plus I can't say I am happy with the idea of patching a bunch of weird stuff I don't quite understand or need. Trouble is going to be removing it after words unless you make a undo ips patch for each rom I guess.

...Wait. Isn't that kind of a contradiction? You said that it should support insertion of more things, but then you said it was a bad idea to expand it because it would be more convoluted.

I'm not even sure I'm going to have another version out at this point...I know I've said it before, but I've hit another roadblock, HuFlungDu is the only other person here who knows Python, and he doesn't know why things aren't working either. A certain regular expression substitution isn't doing what it's supposed to, and even xkas itself is apparently breaking...and the strangest thing of all is that it does so for only one patch. The other three insert okay, and the one that causes the errors inserts okay when patched normally.
Originally posted by imamelia
Originally posted by KilloZapit
I think it's probably a good idea to try and sort out what needs what and how to conditionally patch things anyway, because I think it's going to be harder and harder to sort though bugs and to expand the tools function if it gets more convoluted. Plus I can't say I am happy with the idea of patching a bunch of weird stuff I don't quite understand or need. Trouble is going to be removing it after words unless you make a undo ips patch for each rom I guess.

...Wait. Isn't that kind of a contradiction? You said that it should support insertion of more things, but then you said it was a bad idea to expand it because it would be more convoluted.

I'm not even sure I'm going to have another version out at this point...I know I've said it before, but I've hit another roadblock, HuFlungDu is the only other person here who knows Python, and he doesn't know why things aren't working either. A certain regular expression substitution isn't doing what it's supposed to, and even xkas itself is apparently breaking...and the strangest thing of all is that it does so for only one patch. The other three insert okay, and the one that causes the errors inserts okay when patched normally.


I said it's going to be harder to bugfix or expand unless the code is structured better. The idea I always had is to completely isolate what patches do what, what patches require which other patches, and generally restructure the code into well defined modules, then move any special parsing perl code into special files for each module. Or something like that. Just making the main tool much simpler and more removed from the specific functions. Because once you do that, it seems to me it will be a lot easier to fiddle with patches without breaking stuff. But I have no idea how easy this will actually be to do. It just seems like if you don't do it, things are going to get much harder to add and much harder to fix when they break.

Also, I thought you were using perl not python, though I think using python might be much easier. But if you use python you should do the whole thing in python. I do know a bit of python, and I could take a look if you want, though I can't promise anything. My suggestion would be to try and use the regex substitution on the file and output the result to a file and look at it.
Last edited on 2011-09-23 10:03:36 AM by KilloZapit.
Originally posted by KilloZapit
Also, I thought you were using perl not python, though I think using python might be much easier. But if you use python you should do the whole thing in python.

The original is in perl, he's moving it to Python. The only thing that isn't is obviously xkas (Which, on the surface would be easy to rewrite in Python, but emulating all the little nuances of xkas06 would be pretty annoying), so xkas has to be called from the command line, within the program. Occasionally that causes issues (Like right now...).

Also: Imamelia, the main reason I don't know what's going on is because I don't have a good base for testing. If you just zip up your entire testing folder and send it to me I can help work it out much more effectively.
What kind of issues? Issues with piping and redirection? If that is the case maybe indirectly running xkas though a batch file/shell script would work better. I have done tons of stuff purely with xkas and a batch file. Of course this risks even more layers of code.

BTW is this still being done with linux support in mind? Personally I would just focus on windows. I mean, I use linux myself, but all my hacking is done on a windows virtual box, because almost every utility is made for windows anyway. It might not be worth supporting linux if there is not a linux xkas at least.
Originally posted by KilloZapit
BTW is this still being done with linux support in mind? Personally I would just focus on windows. I mean, I use linux myself, but all my hacking is done on a windows virtual box, because almost every utility is made for windows anyway. It might not be worth supporting linux if there is not a linux xkas at least.

There is a linux xkas. Also: There's no point in not supporting linux, since it's Python, anything you do for windows that doesn't use the win32 api should run just fine in linux.
You would think, but it's been my experience that it's never that simple. Especially when you start calling other programs.
I tried to insert MarioEdit's Huck-it Crab today and everything seemed to be correct (all I had to change was the Init and Main parts), but the game crashed when the crab started throwing the rock. I've inserted it like this:

211 huckitcrab.cfg 0
212 rock.cfg 0

and the spawning the rock looks like this:

LDA #$12
STA $7FAB9E,x

Alcaro said that sprite generation routine needs editing so I "reported" it. It would be great if I could use this sprite in my hack...

Also, has anyone been working on some more Tessera-only sprites? I'm eager to see Thwomp and Bro sprites with extra byte options. :)
Yeah, just using the same spawning routine won't work. There are two things different about spawning custom sprites in Tessera: first, you use JSL $01830B (or $81830B) for initialization instead of the combination JSL $07F7D2 and JSL $0187A7, and second, you need to set $7FAB10,x before said initialization. Here, the extra bit setting is in bits 0 and 1 of $7FAB10,x, and bit 7 should usually also be set. In your case, for example, that piece of code would look like this:

Code
LDA #$12
STA $7FAB9E,x
LDA #$82
STA $7FAB10,x
JSL $81830B


And as far as working on more sprites for Tessera goes, the main reason I personally haven't made any more is because I'm working on the next version of the tool itself. (The syntax of sprite code won't be any different, but a few other things will be. There will also be a couple more features.) I thought yoshicookiezeus was working on a Thwomp, but he probably put it on hold for other projects. You'd have to find out from him.
Last edited on 2011-09-27 04:27:23 PM by imamelia.
Uh, thanks, but it still crashes...it's okay if it can't throw the rock (when I jump on it earlier), but whenever it starts to throw the rock the game freezes. I'm pretty sure dsx.asm was patched correctly...
Huh. I'll have to look into it later, I guess, if you can't figure out the problem.

You know how I mentioned using something about using something other than .cfg files for sprites? What about XML files? Instead of this:

Code
1
36
80 2D 39 81 19 44
00 00
firebar.asm
1

We could have something like this:

Code
<configoptions
	ASMFile = "firebar.asm"
	AssemblerUsed = 1
	IsTweak = false
	ActsLike = 36
	TweakerByte1 = 80
	TweakerByte2 = 2D
	TweakerByte3 = 39
	TweakerByte4 = 81
	TweakerByte5 = 19
	TweakerByte6 = 44
	ExtraPropertyByte1 = 00
	ExtraPropertyByte2 = 00
	ExtraOptions = 00
/>

There might be a better layout for that, but I'm not all that familiar with XML files. Still, though...why not? It wouldn't be harder to edit than a .cfg file, especially if a tool were made for changing individual bits and such, and it would probably be more flexible. It might even be possible to edit each individual setting (palette, clipping indexes, boolean values, etc.) that way, although that would mean larger files and more work for the tool.

Of course, there are other ways I could do such a thing. If it would be worth it, I could even include the full list of config options as written in Tweaker and the .cfg editors in whatever file the sprite would use. There's nothing saying it has to be an XML file either, although at least they have a built-in parser. I could use some other kind of file and just read each line and split it at a " = ".
Last edited on 2011-09-30 01:05:22 AM by imamelia.
Why not call it config rather than configoptions, seems much less clunky.
Originally posted by imamelia
Huh. I'll have to look into it later, I guess, if you can't figure out the problem.

You know how I mentioned using something about using something other than .cfg files for sprites? What about XML files? Instead of this:

Code
1
36
80 2D 39 81 19 44
00 00
firebar.asm
1

We could have something like this:

Code
<configoptions
	ASMFile = "firebar.asm"
	AssemblerUsed = 1
	IsTweak = false
	ActsLike = 36
	TweakerByte1 = 80
	TweakerByte2 = 2D
	TweakerByte3 = 39
	TweakerByte4 = 81
	TweakerByte5 = 19
	TweakerByte6 = 44
	ExtraPropertyByte1 = 00
	ExtraPropertyByte2 = 00
	ExtraOptions = 00
/>

There might be a better layout for that, but I'm not all that familiar with XML files. Still, though...why not? It wouldn't be harder to edit than a .cfg file, especially if a tool were made for changing individual bits and such, and it would probably be more flexible. It might even be possible to edit each individual setting (palette, clipping indexes, boolean values, etc.) that way, although that would mean larger files and more work for the tool.

Of course, there are other ways I could do such a thing. If it would be worth it, I could even include the full list of config options as written in Tweaker and the .cfg editors in whatever file the sprite would use. There's nothing saying it has to be an XML file either, although at least they have a built-in parser. I could use some other kind of file and just read each line and split it at a " = ".


Didn't me and smalls talk about it before and you wanted to make the files binary? Anyway I have to say, I personally dislike the superfluous layout of XML and think ini-like key=value pairs are ideal. I also think naming things simply TweakerByteX is not very helpful. It would be more useful to have some options like in this post only with shorter names. But actually both options would be best.
Last edited on 2011-10-01 10:59:09 AM by KilloZapit.
Pages: « 1 2 3 4 5 6 7 8 »
Forum Index - SMW Hacking - Resource and Tool Releases - Discussion of Tessera, my new Sprite Tool (updated)

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2014 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 27

Menu

Affiliates

  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • ROMhacking.net
  • MFGG