Banner
Views: 763,838,607
Time:
15 users online:  1UPdudes,  Atari2.0,  Dakras Hayashi, DanielGamer LegalBr132,  Eevee,  Erik, Falconpunch,  FPzero, Maxodex, MegaSonic1999, NGB, RioluIndiferent, ShootingStarr,  Sinc-X, Tattletale - Guests: 58 - Bots: 394Users: 40,149 (1,958 active)
Latest: DanielGamer LegalBr132
Not logged in.
Daiyousei, the unsanctioned sprite tool (v0.4.1)
Forum Index - SMW Hacking - Resource & Tool Releases - Daiyousei, the unsanctioned sprite tool (v0.4.1)
Pages: « 1 »
Now that I have returned to the site, Daiyousei has started coming up a bit seemingly just by proximity. The last real release thread was at C3, and before that was a thread in a subforum that doesn't exist, so I guess there should be a new thread now just to keep track of releases.

Daiyousei is a spritetool replacement. It is actually older than PIXI but I disappeared and there was a whole thing, and now PIXI is "official". So if you aren't like, into ASM, PIXI is probably what you want.

Daiyousei is backward compatible with Romi's spritetool, and additionally offers:
  • Support for extra bytes. Sprites can have up to 4 bytes of extra data, specified each time a sprite is placed. This is useful for sprites like doors, which have settings that might change for each one.
  • Support for inserting cluster sprites. (Note that Daiyousei's cluster sprites aren't backward compatible with previous cluster sprites.)
  • Automatic generation of sprite lists. Run "daiyousei -cd romname spritelist" instead of "daiyousei romname spritelist" and it will generate files Lunar Magic can use to display sprites more nicely. This feature is planned to be enhanced in the future, pending some additions to the CFG format.
  • An improved No More Sprite Tile Limits patch. Daiyousei's is included in the tool and substantially better optimized than the original. (Daiyousei reduces an O(nē) workload to an O(n) workload.)
  • Shared subroutines. Daiyousei includes support for shared subroutines. Daiyousei includes several shared subroutines, some taken from common sprite subroutines (like !ssr_GetDrawInfo) and others anew (like the !ssr_GenericGfx subroutines.)
  • Support for some wacky crazy future stuff you probably won't be able to use for a while wow what.


Daiyousei's features have significant overlap with PIXI's. whatcha gonna do.

The latest daiyousei is version 0.4.1.

0.4.1 is mostly a bugfix release in comparison to 0.4.0.
Its changes include:
  • Fixes a major bug where using Daiyousei on a spritetool ROM would basically kill everything. (This was caused by a few bad pointers inside the tool itself).
  • Fixes !ssr_Offscreen, which previously did not work correctly in vertical levels.
  • Adds !ssr_Offscreen_A, which uses a dimension table selected by A instead of a constant. Added to assist in converting sprites from PIXI.


SubconsciousEye also took the time to make a Daiyousei-specific discord server, which you can use if you are into this tool or my other weird ASM projects. You can use this invite: https://discord.gg/3SXJzG3 to join.

Also, the code-inclined may want to visit the Github repo.


but srsly grats on getting this out

edit: dedicated to namles
#smw{:TUP:}
Okay, I'm currently working on overworld sprites.
There's basically a lot of blank canvas in terms of how to implement them so I've written up a pretty big ol' document on how I currently intend to implement things:

http://bin.smwcentral.net/u/8006/owc.txt

This design requires a bit of different coding technique than SMW's sprites usually use which i'm fine because smw is written like a cruddy NES game


I've posted about this in the Daiyousei discord, and so far Ladida likes Proposal 2 and imamelia really doesn't like Proposal 2. Since I like Proposal 2, that leaves us 2:1 in favor, but if you don't count me its a tie

programmers feel free to share your opinions on my thing before I just shove a testing version out



edit:


The leaves in this image are controlled by one sprite.
Each of the weird floating orbs is a separate sprite.

I have moved around the fields a bit since I posted the proposal but nothing substantial has changed.

There's still a lot missing. There currently aren't any subroutines, so before I ship anything I'll want to write at least a few. The sprites also don't reload when changing maps using a red path tile.


There are a few important questions still to resolve - most notable in my opinion is that some sprites will need to save some data to SRAM and I'm not sure what the plan for that should be. I think it might be a bit wild for Daiyousei to also include something like an SRAM expansion patch...
Proposal 1 seems very reasonable to me. Proposal 2, I'm not so sure, it seems very unintuitive. Don't even quite agree with that high level example. To me, that really looks more like a
Code
*(0 + sprite + offsetof(sprite, posX))

which seems just as unituitive and needlessly complicated to me. If (*sprite).posX is what you want, something like
Code
lda $14c8+sprite+offsetof(sprite, posX)

or
Code
lda $14c8+sprite,x	; x = offsetof(sprite, posX)

or
Code
lda offsetof(sprite, posX),x	; x = $14c8

seems closer to that in my eyes (although I don't like that third one, since it kinda feels "backwards" and thus kinda uintuitive again). Or, if you want to index it at run-time rather than compile-time, even something like
Code
lda ($00),y		; $00 = $14c8, y = offsetof(sprite, posX)

or
Code
lda ($00)		; $00 = $14c8 + offsetof(sprite, posX)

of which none require 16-bit x/y registers and which both seem more intuitive. "lda $00,x" really seems as though you were indexing a table at $00, that doesn't seem like a good coding style to me.

Can you explan what the benefits of proposal 2 are in your eyes? They really aren't self-explanatory to me. So right now I'd say my vote is against proposal 2, but maybe if you can explain the benefits of that method this could change?

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I very like the design proposal 2 because it's can easily multiple byte process, it has memory relocatability than proposal 1 and can faster process.

why we don't use $00,x and $0000,x as indirect addressing mode
I don't like #2. Partially because, as RPG Hacker said, $00,x looks like there's something at $00; partially because it sounds like a massive slowdown to me. While $00,x is faster than $0000,x, it limits your ability to switch between tables without a massive performance penalty. You could use $42,x if the tables are near each other, but at 33 bytes per sprite, that limits you to 7 sprites before you have to switch to $0100,x. It also seems likely to confuse the SA-1; it's doable, but it'd require some funky math, especially around the two-four digit boundary. It also means an extra CPX if iterating all sprites.

But I'm not convinced about #1 either. While there are a few advantages to having the sprite contiguous, there are also advantages to interleaving them; for example, you can put common tables on the direct page while the less common ones go in the four-digit area, and it's a lot easier to add (or subtract) 1 than 33 if you want to iterate over all sprites.

And most importantly, being different is a drawback, not a virtue. Programmer convenience is maximized by minimizing the amount of things to learn, which means sticking to what we're already doing. Addresses and max number already varies between our ~6 sprite types, but having one of them be even more different requires massive performance or code size benefits to make up for the increased confusion.

Without the difference drawback (for example if you rewrite all other sprite types too), I'd consider that #1 about as good as as the original scheme, and #2 a bit worse. Both combined, anything except sticking to the original scheme is absurd.

--------------------
<blm> zsnes users are the flatearthers of emulation
Right now it seems like opinions are surprisingly evenly divided on Proposal 2 but the against side has better (or at least longer) rationale. Proposal 1 seems to be doing better. I might go for P1-only.



Originally posted by RPG Hacker
offsetof business

I really didn't mean for the high-level example bit to be super-literal actually-compileable C code where all the types match up and everything, just an example of the spirit of the thing. (But I do think a good C compiler would probably generate lda #bla,x for p->m as long as p was in X)

It's not that I started with (*sprite).posX and wanted to work that into ASM, I started with lda.b !owc_posX,x and came up with the high-level thing to try to explain how it worked. Something like lda ($00),y only makes sense going the other direction.

As for what I'm looking for with Proposal 2, it's mainly speed; any alternate proposal needs to either benefit in speed or familiarity (so ($xx),y is right out). I do have a personal preference for using X/Y as pointers rather than offsets, but that comes from time spent optimizing ASM.

Originally posted by RPG Hacker, Alcaro (in paraphrase)
lda $00,x looks like there is something at $00


I think this is kind of an unfortunate side-effect of the 65816 syntax. On ARM this would look something like ldr r1, [r0, #posX], which I think gives a better impression of what's going on. Being able to write something like lda (x) and just have it mean the same thing as lda $00,x would be nice, but regrettably I made that up and it's not real.


Also, I'm not sure how relevant the syntactic concern here is. Although I used numbers in the examples, that was mainly because I hadn't listed the tables anywhere and didn't want to bog them down with that. In practice loading $00,x will look like lda !owc_num,x and I'm not sure how damaging it is to believe that !owc_num points to a place with data. You can work with it pretty well without understanding it. If all you know is that you have a good sprite index/pointer in X, you write lda !owc_posX,x to get the X position regardless of how the math between x and !owc_posX shakes out.

The main time it really changes anything is when you're iterating over sprites, and the main uses I can think of for that are to dispatch them (handled by the patch and not something you need to think about), finding a free slot to spawn a sprite (which will probably just get shoved into a subroutine), and collision with other sprites (which can probably be put into a subroutine and doesn't seem like something most overworld sprites would be interested in anyway).

Originally posted by Alcaro
I don't like #2 [...] it sounds like a massive slowdown to me. While $00,x is faster than $0000,x, it limits your ability to switch between tables without a massive performance penalty. You could use $42,x if the tables are near each other, but at 33 bytes per sprite, that limits you to 7 sprites before you have to switch to $0100,x. It also seems likely to confuse the SA-1; it's doable, but it'd require some funky math, especially around the two-four digit boundary. It also means an extra CPX if iterating all sprites.

[...]
Both combined, anything except sticking to the original scheme is absurd.


To be completely honest, I don't understand what you mean by "switch between tables" or why you would want to do it. Do you mean like how the movement routines change X so they can use the same code for horizontal and vertical movement? Do you mean having a sprite poke around in another sprite's fields?

As for the CPX on iterating, the more relevant concern is
Code
rep #$21 : txa : adc #size : tax : sep #$20

which also affects us if we go exclusively Proposal 1. I honestly think iterating (once-twice per sprite call) is rare enough compared to accessing fields (dozens of times per sprite call) that a speedup on field access is worth it, but I'll have to do some actual measurement and math once I've got a few of Lui's sprites converted.

Also pertinent is whether by "the original scheme" you mean the original SMW scheme, which suffers from its 8-bit tables (all those adc's and xba's), or the scheme from Lui37's patch, which has 16-bit tables. I think that Lui37's is like, the furthest back we can reasonably walk this.


Also, I've noticed that the proposal doc might make it sound like Proposal 1 can go with 8-bit X, but it can only do ~7 sprites that way, so practically speaking Proposal 1 implies 16-bit X as well. I might update the doc with that correction.
Originally posted by Katrina
But I do think a good C compiler would probably generate lda #bla,x for p->m as long as p was in X


That's very possible, although compiler-generated code isn't really meant to be human-readable in the first place, unlike code written by humans. That's something to consider. I'm not really saying "don't go with proposal 2" (since you've made your reasons more clear now and I don't think they're bad reasons), just saying that sometimes it's worth sacrificing some performance for readability (though again: not saying that his is necessarily one of those cases). Which brings me to

Originally posted by Katrina
In practice loading $00,x will look like lda !owc_num,x and I'm not sure how damaging it is to believe that !owc_num points to a place with data. You can work with it pretty well without understanding it. If all you know is that you have a good sprite index/pointer in X, you write lda !owc_posX,x to get the X position regardless of how the math between x and !owc_posX shakes out.


Yeah, that sounds more reasonable. As a rule of thumb: writing "ugly" code is fine (and necessary) sometimes, but when that's the case, it's usually a good idea to make it as pretty and readable as possible to end users still. One major reason why modern C++ code is so unintuitive and beginner-unfriendly, for example, is the fact that it compromises readability for performance in many, many places (with templates that are resolved at compile-time all over the place, some of them insanely intimidating). It's a major difference from, let's say, Pascal, which is syntactically very clean and intuitive and thus is a programming language that beginners can wrap their heads around more easily. Since SMW Central, in some sense, can really be considered a community of "beginners" and "hobbyists", making sprite coding as intuitve as possible isn't a bad idea (even if overworld sprites are probably going to be coded rarely, anyways). Because of that, yeah, defines that hide the "ugly" code in the background and make the sprites more human-readable are certainly a good idea. Alternatively, macros could also be an option. Thinking of something like

Code
%load_sprite_prop_a(!spriteXPos)


Just as an example, although in this case the define solution is probably just as good (if not better). In any case, yeah, I agree with proposal 2 if it's done in a way that keeps sprite code intuitive and human-readable by hiding ugly stuff in the background.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
You're considering changing several different parameters from SMW's scheme simultaneously, yielding multiple different possible schemes, then naming two of them and ignoring the others.

(A) You are changing X from 8 to 16 bits.
(B) You are rearranging the sprite data from struct-of-arrays to array-of-structs. (Okay, the original isn't a contiguous struct, but I'll call it SoA anyways.)
(C) You are changing X from offset to pointer.

Using lowercase for 'change not made' and uppercase for 'change made',
abc is the original SMW scheme
abC and aBC are impossible, you can't fit a useful pointer in 8 bits
aBc is too limiting to be useful with 33 byte sprites
Abc doesn't accomplish anything (except allowing using the entire OAM, rather than just half, I guess?)
AbC is, I believe, your option 2
ABc is, I believe, your option 1
ABC is another possibility

If that is incorrect, misunderstandings are bound to happen.

(It's also possible to do struct-of-arrays-of-twobyte-fields, which yields a mix of their advantages and drawbacks.)

Quote
I do have a personal preference for using X/Y as pointers rather than offsets, but that comes from time spent optimizing ASM.

As far as I know, nobody else prefers it that way, at least on 65816.

The entire instruction set seems designed for offsets rather than pointers; there's no register-to-register compare instruction (while CPX #$1234 isn't too bad at 3 cycles, it is more than the 0 needed for the usual DEX BPL loop). There's no LDA ,x instruction, you have to add a $00. You can't even use X/Y as pointers without hardcoding the bank somewhere.

Similarly, the lack of a 'add 42 to X' instruction makes struct of arrays a fair bit more convenient than array of structs.

Pointers work fine on many architectures, but they're uncomfortable at best on this one.

Quote
Although I used numbers in the examples, that was mainly because I hadn't listed the tables anywhere and didn't want to bog them down with that.

Source code terseness is a good thing, but terseness at the expense of clarity is never worth it. Removing the unused defines is fine, but using numbers instead of defines is oversimplifying to the point of distracting from whatever actual argument you're trying to make.

Quote
To be completely honest, I don't understand what you mean by "switch between tables" or why you would want to do it.

Touching two tables, 'LDA $D8,x : LDA $E4,x'. If X is $9E+1, grabbing anything from the table at $14D4 would be annoying; while those exact addresses won't happen, struct-of-arrays with pointers (AbC) would require 16bit base offsets at some point.

If your option 2 is ABC, that specific complaint does indeed not make sense.

Quote
I honestly think iterating (once-twice per sprite call) is rare enough compared to accessing fields (dozens of times per sprite call) that a speedup on field access is worth it, but I'll have to do some actual measurement and math once I've got a few of Lui's sprites converted.

That number is going to come out way different depending on how many slots exist, how many slots are used, whether we're comparing abc vs AbC vs ABc vs ABC, how complex the sprites are, how many sprites access each other, and how many sprites iterate over the others. Every possible number would be accurate for some hacks and way off for others. No matter what numbers we stick in, neither of us can conclusively prove that one option is objectively faster than all others.

But I believe that question is ultimately unimportant. Instead, I believe the correct question is:

Does it matter?

Even if you save 1000 cycles per frame, what are you going to use them for? The overworld doesn't have much going on. Levels are perfectly happy the way they are, and levels are way more demanding than any plausible overworld I can think of. You're just moving the cycles from the sprite handlers to the wait-for-next-frame loop.

I remain convinced that the only parameter where this choice gives a noticable impact is programmer convenince, and that programmer convenience is maximized by sticking to the tried and true scheme of exactly the same as the every other sprite type. Overworld sprites are not special enough to warrant a unique coding style. Your system may be better in isolation, but combined with our other tools and current coders, it is not worthwhile.

Being different is a bad thing.

--------------------
<blm> zsnes users are the flatearthers of emulation
Originally posted by RPG Hacker
Yeah, that sounds more reasonable. As a rule of thumb: writing "ugly" code is fine (and necessary) sometimes, but when that's the case, it's usually a good idea to make it as pretty and readable as possible to end users still. One major reason why modern C++ code is so unintuitive and beginner-unfriendly, for example, is the fact that it compromises readability for performance in many, many places (with templates that are resolved at compile-time all over the place, some of them insanely intimidating). It's a major difference from, let's say, Pascal, which is syntactically very clean and intuitive and thus is a programming language that beginners can wrap their heads around more easily. Since SMW Central, in some sense, can really be considered a community of "beginners" and "hobbyists", making sprite coding as intuitve as possible isn't a bad idea (even if overworld sprites are probably going to be coded rarely, anyways). Because of that, yeah, defines that hide the "ugly" code in the background and make the sprites more human-readable are certainly a good idea. Alternatively, macros could also be an option.

Daiyousei exports a bunch of defines for basically everything, so I guess I've started to take it for granted that you would use defines instead of raw hex in actual code, but I keep forgetting that Daiyousei never got a proper release yet so nobody else is living in Daiyousei-world like me.

Macros aren't a great option because they are less familiar than defines, and because stuff like ora !someWeirdFlag,x is pretty useful, so you'd either need a lot of macros to match up all the possible uses or a suboptimal subset of them.

One point of uncertainty here is whether I'm hiding the "ugly bits" well enough. The place that changes most is iterating-over-sprites, which is rare, but is already a kind of hard thing to write code for, so adding another layer of confusion to it seems like it might be almost a showstopper for the rare person who really does need to do it, and not just do something like spawn a sprite or handle some default collision thing that can be put into one of Daiyousei's subroutines.

I have actually thought about providing a subroutine with the sole purpose of making it easier, which would be something like

Code
SomewhereInTheMainRoutine:
	; !ssr_owc_Iterate takes a callback in Y,
	; then calls it once for every sprite, with a pointer to that sprite in Y
	ldy.w #Callback
	jsl !ssr_owc_Iterate
	; ... the rest of the main routine

Callback:
	; let's say our sprite wants to shove every other sprite onto the floor for some reason
	stz !owc_posZ,y
	stz !owc_posZ+1,y
	rtl

This is obviously not optimal for performance, but it should work well for people who don't care about performance, and people who do care are hopefully experienced enough with ASM to understand the iteration on their own. But it relies on using a callback, which is a really uncommon thing in ASM, so I'm not sure how much easier it will be to explain. It also makes it difficult to do things like exit the loop early, and trying to add those things to the subroutine turns it complicated fast.




Originally posted by Alcaro
(A) You are changing X from 8 to 16 bits.
(B) You are rearranging the sprite data from struct-of-arrays to array-of-structs. (Okay, the original isn't a contiguous struct, but I'll call it SoA anyways.)
(C) You are changing X from offset to pointer.

Using lowercase for 'change not made' and uppercase for 'change made'

My Prop. 1 is ABc, and Prop 2. is ABC. I had intended for P2 to build on P1 - a close reading will note that it starts with "also" - but I guess I didn't make it clear enough; imamelia, I think, had a similar misreading.

I think my explanatory document is deeply bad. I am not sure I would be able to rewrite it without making some other thing confusing, though. The fact that it is apparently pretty hard to understand is a real strong argument against its proposals - if I can't write a good explanation, nobody else will ever get this figured out, and it will never get anywhere.

Quote
That number is going to come out way different depending on how many slots exist, how many slots are used, whether we're comparing abc vs AbC vs ABc vs ABC, how complex the sprites are, how many sprites access each other, and how many sprites iterate over the others. Every possible number would be accurate for some hacks and way off for others. No matter what numbers we stick in, neither of us can conclusively prove that one option is objectively faster than all others.

This argument could be applied to most optimizations and is wrong for most optimizations. Even code that is very different in purpose tends to be broadly similar in structure. Even if it weren't, I suspect that most sprites will have a small set of broadly similar things they want to do (mainly variations of "thing moves around on the map"), and I suspect that set of things will not include much of "iterate over all the other sprites" (outside of the spawn routine which will be written by me, once, and even then not many sprites need it).

Quote
Does it matter?

Now this argument is getting somewhere. After goofing around a bit with ~10 overworld sprites I didn't manage to cause any slowdown. In the near future I will be trying to figure how many leaves the S-CPU can handle - I suspect it is a lot more leaves than anybody needs.

I would strongly prefer having performant overworld sprites to having to support some eventual nonsense like overworld extended sprites or overworld cluster sprites, but I don't think enough people want weird things on their overworld to invent those. I might very well just be trying to min-max performance here out of habit rather than necessity.

Originally posted by Alcaro
Being different is a bad thing.

Congratulations, I also saw Tessera not get adopted. However, I am trying to decide how many changes to make, not whether or not to make changes, so "different is bad" is not a useful decision-making tool here all by itself.

I should say that before Lui37's patch got basically canonized by having its table format included in LM I had no interest in writing a parallel overworld sprite system and I would not have started on my own. I would have just shoved everything into the original game's overworld sprite system, the way every other sprite type does.

But since it did get put into LM we kinda have to deal with that. And I mean, it's obviously a pretty massive improvement, in terms of the UI that happens in LM and elsewhere. No more of the weird bitwise filters from the other overworld spritetools, no more "slot 4 should be left as nothing", etc, you just pick a sprite number and plop it down.

But it's also obviously not going to squish back into the old sprite system with any degree of comfort. For one thing, they're stored in a completely different table, so a routine to load them would need to load them around the original sprites. Then you'd need a routine that would unload only the custom sprites when the map goes away, to make room for the sprites on other submaps if the player loads another submap. And then the reward you get for that is a system where some sprites are immortal but some aren't and they all interact with each other and share tables. And then if you don't move the tables to make room for more sprites, you have a whopping 4 slots free by default on the overworld, 5 if you delete the koopa kids, which gets eaten up instantly by that Lava Lotus sprite. But you can't just move the tables into a bigger spot, either, on account of how some of the sprites are immortal and if you move their tables they'll get killed between levels loading!

So I think that rather than trying to graft a bunch of weird backward-compatibility business onto Lui37's patch, it makes most sense to at the very least start with Lui37's patch, which makes lots of changes and which not only haven't I seen any complaints about but that FuSoYa thought was good and accessible enough to add a major piece of to LM.

I am trying to discern what is the optimum amount of changes to make and you are coming at me with "actually, changes are bad", even though the person who went ahead and made a bunch of crazy changes is doing so much better than everyone else that we practically have no choice but to implement their thing at minimum.

Please stop dropping "Being different is bad" in your posts like it's the last word of every argument you could possibly make on the matter.



You also didn't say whether by "different" you mean different from SMW or Lui37, which is pretty important still
Quote
I guess I've started to take it for granted that you would use defines instead of raw hex in actual code

I prefer hex. I can't keep track of whether it's named !spr_Xlo or !sprXlo or !sprite_x_low or whatever else. $E4 (or !E4) is the only name that's not up for debate.

But that doesn't really apply if you make up your own sprite tables that don't show up in the RAM map. I'm not sure how I'd deal with those.

Quote
ldy.w #Callback
jsl !ssr_owc_Iterate

I'd put that in a macro, they're more commonly understood than callbacks. They optimize better, too, assuming you don't mind the increased code size.

Actually, you could even create a define that swaps the implementation depending on how space-starved you are. How entertaining!

Quote
Even code that is very different in purpose tends to be broadly similar in structure.

That does not affect my conclusion: the ratio of sprite iterations vs sprite field accesses will affect which option is faster, and as such, no option can be said to be faster.

Quote
After goofing around a bit with ~10 overworld sprites I didn't manage to cause any slowdown.

The clean ROM doesn't mind 20 cluster sprites. While OW sprites are probably a bit more sophisticated than the clusters, OWs don't have to compete with standard, extended and minor extended. 10 is trivial. You'll need at least 20, or have them do something silly, if you want slowdown. (I don't know if that fits in your RAM if they're 33 bytes each, but 33 sounds like way more than needed. But I have no strong feelings here, do whatever you want.)

On a totally related note, this one may reveal some interesting information.

Quote
I would strongly prefer having performant overworld sprites to having to support some eventual nonsense like overworld extended sprites or overworld cluster sprites

Worst case, you can just merge some sprites into a single controller. There's no need for more sprite kinds.

Quote
I might very well just be trying to min-max performance here out of habit rather than necessity.

That is consistent with my observations. Can't say I'm innocent of pointless optimizations myself.

But clean and consistent APIs trump performance.

Quote
I am trying to decide how many changes to make, not whether or not to make changes

Change in itself is bad, but if it brings enough benefits, it's worth it. More OW sprite slots counts as a big benefit, and the cost of swapping the addresses is fairly low. SA-1 extends and moves the normal sprite tables; if you do the same, I have no objections.

I don't know the exact details about Lui's scheme (is it abcD where D is struct-of-arrays-of-twobyte-fields? Is it abcd, just expanding and moving the tables? Is it just some tables in the ROM that the tool can deinterleave however it wants?), but it's possible that it's worth it.

While I don't think the benefits of abcD outweigh the drawbacks (assuming it's just ROM tables and the cost of having the tool translate it is negligible), I believe it would be tolerated. If this was a more common sprite type, I'd vote yes to abcD, but OW sprites aren't THAT important.

And all other sprite types already have an insertion tool and would insta-veto any format changes. Backwards compatibility, fun for the entire family...

Quote
Please stop dropping "Being different is bad" in your posts like it's the last word of every argument you could possibly make on the matter.

As far as I could see, you ignored that one last time.

But okay, I'll end this post with a Muncher instead.

Quote
You also didn't say whether by "different" you mean different from SMW or Lui37, which is pretty important still

The one I care about is differences from the other sprite types, which all act like SMW. But as mentioned, using Lui's scheme may be worth it.

Only one way to find out.



--------------------
<blm> zsnes users are the flatearthers of emulation
Pages: « 1 »
Forum Index - SMW Hacking - Resource & Tool Releases - Daiyousei, the unsanctioned sprite tool (v0.4.1)

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

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


Total queries: 23

Menu

Follow Us On

  • Facebook
  • Twitter
  • YouTube

Affiliates

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