 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in SMW Hacking. |
| Acmlm's Board - I3 Archive - SMW Hacking - ASM hack idea. (Sprite graphics related) |
New poll |  |  |
| Pages: 1 2 3 | Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
| Note: This is not a request, nor am I saying that I will make it. It's just an idea I had.
A few months ago when playing Donkey Kong Country, I got curious and wondered in what order the graphics were stored in VRAM. I opened a savestate in YY-CHR and noticed something interesting. The sprite graphics files in DKC are dynamic, meaning that when a sprite is created, it loads its graphics into a free space in the graphics file. When the sprite is removed, the graphics are unloaded and some other sprite could use that space. I'm pretty sure that the palettes works in the same way as well. My first thought was "Brilliant!". My second thought was "Would it be possible to make such a system for SMW?". Now, if we assume that the first graphics file is used for extra sprites, we've got 3 graphics files left for the dynamic sprite graphics, which is 384 tiles. The maximum amount of active sprites at once is 12, giving each sprite 32 tiles of graphics space, which is enough for 8 16x16 tiles, which is more than enough for most sprites. So... What about the palettes? Well, there's 8 palettes of 16 colors... And that's not enough for 12 sprites, Mario and extra sprites. So... What about 16 palettes of 8 colors instead? Each sprite would get 7 colors each + transparency. That would leave 4 8-color palettes for Mario and extra sprites or 2 16-color palettes, whichever is better. ...probably the latter one. Now, you'll probably think "What's the point?". Well... Here's some Pos and Cons: + No need to fit all sprites that may be in the same level into the same (Ex)GFX file. + Same thing goes for palettes. - Would require tons of coding: Checking for free graphics space, load graphics, make sprites use upper colors if they use the second half of a palette, removing graphics when sprite is removed, load/unload palette, and so on. - The sprite graphics would probably have to be stored uncompressed somewhere in the ROM. - No Lunar Magic support. - Probably tons of other work. Now that I think about it, it's more trouble than it's worth. Oh, well... It would be nice to see anyway. (edited by Smallhacker on 08-16-06 07:52 AM) |
|||
Ice Man Panser                   Since: 11-18-05 From: Germany Last post: 6392 days Last view: 6329 days |
| ||
| Awesome idea, really. It would be worth working on though, since it'll make SMW hacking better again and using more and different sprites = awesomeness.
Just my opinion. |
|||
|
Kyoufu Kawa Intends to keep Rom Hacking in one piece until the end   Since: 11-18-05 From: Catgirl Central Station Last post: 6293 days Last view: 6293 days |
| ||
| Funny. I had something like that in Catnip Dreams.
I therefore approve of your idea by experience. |
|||
Squash Monster Bouncy Since: 11-18-05 From: Right next to myself. Last post: 6301 days Last view: 6295 days |
| ||
| I like it.
I think the actual modifications that would make the game use this system wouldn't be terribly hard, either. Well, assuming there is some decent amount of free memory and thre are universal sprite loading, unloading, and step functions that we could add some code to. Presumably, you'd store the starting location of each sprite's graphics and a count of how many of each sprite is in use in RAM, and a list of how long each sprite's graphics are in ROM. The part that would actually be difficult would be hacking each of the individual sprite routines to get the starting location of its graphics from the new, changing location. But there might be some hackish way around that. If we stored something that said where the start of the original sprite graphics was for each sprite, could we subtract that amount from all the tile indexes it uses and add the amount the new system gave it after each sprite call? And then there's the question of things like parakoopas. They shouldn't need their own graphics if koopas are already loaded. I know you could hack the sprite routines to manually add one to the koopa count and have the actually parakoopa graphics just be wings. But it seems like there should be a better way. And I disagree with the idea of shrinking the palettes. It should be possible to try to get things to re-use palettes, and if we end up needing more than we can handle we can stop letting new sprites load. It's completely graceless, but we're going to have to do it when we run out of room for sprites already, so we might as well. (edited by Squash Monster on 08-16-06 01:27 PM) |
|||
Sukasa Birdo Not quite as active as before. Xkeeper supporter Xk > ||bass I IP Banned myself! Twice!  Since: 11-17-05 From: Somewhere over there Last post: 6294 days Last view: 6293 days |
| ||
| Actually, the sprites all store their tile numbers into a buffer starting at $7E0300 in RAM, what what I've seen in all of MikeyK's custom sprites. Just hack in another RAM table to the routine that the sprites call after adding tiles to the SMW OAM buffer, and then hacker the buffering code to re-write the tile numbers as needed perhaps. Then you wouldn't even need to touch the sprites. | |||
|
Alastor Fearless Moderator Hero  Since: 11-17-05 From: An apartment by DigiPen, Redmond, Washington Last post: 6293 days Last view: 6293 days |
| ||
| Wouldn't this mean you couldn't use the same sprite but dress it up a bit differently in different areas? A system like this would be a nightmare for me, as I screwed around with a lot of palettes for enemies in different levels, and I'm sure many people do the same for graphifcs. (edited by Alastor the Stylish on 08-16-06 11:24 PM) |
|||
Disruptive Idiot Red Paragoomba Since: 11-17-05 From: Syosset Last post: 6421 days Last view: 6293 days |
| ||
| Would this system have much overhead? I mean, SMW isn't exactly a performance critical game, but what's the cost of executing these operations? I'd assume minimal if other games use it, but any hackish implementation is bound to be severely unoptimized. | |||
BMF54123 Since: 11-18-05 From: MOOGLES Last post: 6294 days Last view: 6293 days |
| ||
| FuSoYa's code already swaps in new tiles every x frames for custom animations. However, these tiles are decompressed to RAM at level load and copied to VRAM via DMA when needed. The SNES is simply not fast enough to decompress graphics on-the-fly without introducing graphical glitches and/or slowdown (even comparatively speedy Genesis games almost always store "hot-swapped" tiles uncompressed in the ROM).
Thus, for this system to work efficiently, you'd need to decompress ALL the necessary sprite tiles to RAM (not a problem, there's plenty of free space) during the level load routines, and then do a quick RAM->VRAM DMA whenever one of the sprites enters the screen. This shouldn't cause any problems unless you have too many custom animations and/or new sprites appearing on-screen all at once (there's only so much V-blank time in which to DMA). The hardest part would definitely be keeping track of which sprites use which tiles and selectively decompressing their graphics, since the game does not natively support such a system. |
|||
|
Glyphodon Since: 11-18-05 Last post: 6334 days Last view: 6315 days |
| ||
| Naturally, the game should have a table of what graphics are loaded. If the koopa section is loaded, then when another koopa appears the table will be read and no new graphics will be loaded because the needed one is already there.
For concerns like the Paratroopa, keep in mind that one sprite doesn't have to load one graphic... A paratroopa could load both the wings and the koopa graphics into RAM. If Winged Goombas, Koopas, or other Paratroopas haven't forced the game to load said graphics already, anyway... that's what the table would be for. For palette manipulation, you could just live with the fact that you can't use two sprites that use different palettes that share the same space. Alternately, the last two palettes could be loaded dynamically when a sprite that uses one of those two palettes appears... those are the only ones that could possibly cause a clash, right? Using this idea of yours, you might not ever have to check to see what graphics you have loaded again. It's a nice idea, but does anyone really want to code all this for what often can be done with ExGFX anyway? |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6294 days Last view: 6294 days |
| ||
| Mario Kart Super Circuit does this too. It's certainly a nice idea. Shrinking palettes isn't such a good idea, though. You'd want to do a similar allocation system for palettes, where each sprite loads whatever one it needs only if such a palette isn't already loaded. If you wanted to get really advanced, you could designate a given sprite as only using X colours, then if a second sprite only needs Y colours, and X and Y can both fit into one palette, you recolour the graphics as they're decompressed so that both sprites are actually using one palette.
Or do it like Pokémon G/S, and just load one set of colours for the level for all sprites to use.  G/S actually uses the same palette (swapping a few colours here and there) for every level, and just switches palettes for morning/day/night. It works very well; having one palette per level (and four times as many colours per palette) should be plenty for SMW.(edited by HyperHacker on 08-17-06 02:33 PM) |
|||
|
Disruptive Idiot Red Paragoomba Since: 11-17-05 From: Syosset Last post: 6421 days Last view: 6293 days |
| ||
| So the procedure would be like this:
1. When the level loads, the game determines which sprites are going to be used in the level and loads those graphics into RAM. 2. When a sprite gets on screen, the game checks to see whether its graphics are loaded in VRAM. A.If they are, then the sprite's data is overwritten so that the graphics it uses are the ones already loaded into VRAM. B. If they aren't, then the game finds free space and DMA's the graphics to that location, it marks this area as used and which sprite uses it in some sort of table. Then A occurs. 3. When a sprite ceases to be processed the game checks to see whether its graphics are still in use. (Alternatively, as I doubt the game keeps track of sprites that stop being processed, this can be done every frame or something) A. If another sprite is still using them, the game does nothing. B. If no other sprite was using the graphics, the game frees the memory for use by a new sprite and updates a table to take note. Is that how it goes? |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6294 days Last view: 6294 days |
| ||
| That sounds right. It might be better to store the sprite graphics uncompressed in ROM though (or use a weak compression that won't take too long to decode) so they don't need to be copied to RAM. Graphics are big, especially since sprites tend to be animated, and using enough sprites would quickly eat up all that RAM.
(Or add an expansion chip such as SA-1 to do the decompression.  ) |
|||
|
Disruptive Idiot Red Paragoomba Since: 11-17-05 From: Syosset Last post: 6421 days Last view: 6293 days |
| ||
| It might eat up all the RAM, hell it definitely would, but storing the graphics in rom uncompressed would make the file bigger, 56kers may not be amused. If you store them uncompressed then you'd make it impossible to use Lunar Magic to insert sprite exGFX. Plus, it would be faster to transfer from RAM to VRAM than ROM to VRAM, at least if conventional hardware wisdom holds.
So some of the data required for this to work: 1. Either a routine that reads the level and determines which sprites are in it, or a ROM area that stores this data already for each level. I'd go with the second idea and determine the data at compile time than in real-time because the level load routine would be long enough decompressing graphics. Plus, it'd probably be easier to store the data in the ROM than figure it out on the fly This data would then be used to determine which graphics to decompress and load into RAM.
2. A table that keeps track of the graphics loaded in RAM. Which sprite uses the graphics and where exactly they're located. This would be used to determine what to DMA into VRAM when a sprite comes up. 3. A table that keeps track of the graphics loaded in VRAM. Same as for the RAM except this would be used to determine which tiles the sprite uses. I'm doing this because I find it MUCH easier to code something when it's broken up into pieces and then put together after each piece is created. Right now, I don't think it looks as difficult than in the original post |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6294 days Last view: 6294 days |
| ||
Originally posted by Disruptive Idiot That's why you compress the patch (zip, or better, 7zip).
I think trying to keep everything compatible with a closed-source, non-updated editor is a lost cause...  It's getting to where it'd almost be easier to make another, open-source editor than to try to keep all our hacks compatible with it.
If it must be done, though, how much SRAM can a SNES game have? SMW only uses like 2K, so if more is available, graphics could be decompressed to it when the level loads and copied to VRAM as necessary. SRAM->VRAM access might even be a tiny bit faster than ROM->VRAM.
Probably, but if ROM->VRAM is fast enough (note that we can use FastROM), does it really matter? |
|||
|
Disruptive Idiot Red Paragoomba Since: 11-17-05 From: Syosset Last post: 6421 days Last view: 6293 days |
| ||
| Yeah, I guess you're right on all points, especially the Lunar Magic one.I guess given time somebody is bound to have the same dedication Fu So Ya had and an open source alternative will be born. | |||
|
Glyphodon Since: 11-18-05 Last post: 6334 days Last view: 6315 days |
| ||
| This sentiment that Lunar Magic is doomed just because it isn't open source is downright ridiculous. You think powerful, user-friendly hacker tools like LM just pop out of the sky?
Nobody has both the talent and the drive to create a new Lunar Magic just to appease you open-source fanatics. Lunar Magic is going to be the best hacking tool for SMW, or perhaps any game, that we are going to see for many years, if ever. Deal with it. Really, now... how many people make grandiose super-hacks that can't be compatible with LM, anyway? None or next-to-none, because few have the talent and none want to make a full SMW hack without a decent level/graphics/overworld/everything editor. It's not like LM's restrictive, anyway. I've practically poked holes in my ROMS with my little hacks everywhere and LM never complains... Mikeyk's sprite tool, Jonwil's blocktool, and d4s' HDMA patch radically change the game, too, and yet manage--or even demand--Lunar Magic compatibility. (edited by Glyph Phoenix on 08-18-06 02:46 PM) |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6294 days Last view: 6294 days |
| ||
Originally posted by Glyph Phoenix Really? You've read everybody's mind and none of them think they could/want to make a new editor? That's amazing. But what makes Super Mario World so different than other games, and FuSoYa so different than other people, that while anyone with decent programming skills can make an editor for, say, Super Mario Bros 3, only he can make one for SMW? |
|||
|
Disruptive Idiot Red Paragoomba Since: 11-17-05 From: Syosset Last post: 6421 days Last view: 6293 days |
| ||
Originally posted by Glyph Phoenix Yes, yes, but some things, like overhauling how the game handles sprite graphics for this case, simply can't be compatible with Lunar Magic without creating yet another utility that makes sure LM's gfx and the uncompressed GFX in the ROM (as per Hyper Hacker's proposal) are identical in content. Noones criticizing LM, it's a wonderful tool with a degree of professionalism Fu So Ya has bragging rights about. However the fact of the matter is, there will be things that will break Lunar Magic if they change the way the game handles data, and since Lunar Magic isn't open source, nothing can be done about it. In other cases, I'm not a very open-source kind of guy, thanks for being presumptuous. For example, I don't support Linux or lololol any more than I support Windows and IE, much less because they're open source. However, there are clear merits to a utility the community can work on together, and Lunar Magic isn't that. At least a plug-in system would be nice, so instead of one utility and optional plug-ins, we have dozens of utilities. Not very elegant IMO. Back on topic, I don't see much pay-off for implementing this idea, unless someone's a wizard at ASM and can do it with impunity. I'd try it, but I'm a novice at SNES programming and this seems a little out of my scope (programming joke, get it? ). |
|||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6295 days Last view: 6293 days |
| ||
| Considering how ridiculously popular SMW hacking is, if FuSoYa really doesn't update his editor or release the sources (which is, from what I gathered, just not gonna happen), I'd say there are strong chances someone will end up taking over and make an even greater editor.
FuSoYa is a quite cool guy and has really brought a lot of to the ROM hacking community, but a program that doesn't get updated to answer the new needs of its users just won't do... at least for the most ambitious hackers. And there's a fair load of other talented programmers out there... One of them just needs time and a lot of motivation. |
|||
|
Sukasa Birdo Not quite as active as before. Xkeeper supporter Xk > ||bass I IP Banned myself! Twice! Since: 11-17-05 From: Somewhere over there Last post: 6294 days Last view: 6293 days |
| ||
| I think FuSoYa once sad that he'd continue development on LM if we could just find enough bugs or anything... and I have a glitch in LM as well, albeit a small one: The wave tile for the overworld is animated in the wrong direction. While it appears to move one direction in Lm, it actually moves the other way in SMW.
Anyways, yeah- just have a program allow you to copy the compressed version of the sprite GFX to their uncompressed versions in the ROM - not quite instant compatibility, and it'd look wrogn in LM, but it's realy as close as you're gonna get. |
| Pages: 1 2 3 | Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - SMW Hacking - ASM hack idea. (Sprite graphics related) |
| |
