(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
04-27-24 08:02 AM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - Zelda 3 ASM hacks New poll | |
Pages: 1 2Add to favorites | Next newer thread | Next older thread
User Post
Gideon Zhi

Keese








Since: 12-05-05
From: ...behind you! Boo!

Last post: 6279 days
Last view: 6277 days
Posted on 11-08-06 02:18 PM Link | Quote
I just thought I'd use this thread to mention my own intention to work on a Zelda 3 hack once MoN's editor is complete. We've spoken back and forth some months ago about it, and while I'm by no means lazy or unwilling to learn, I've found Hyrule Magic to be obtuse in design and overly inflexible in its capabilities. I've got too much other stuff on my plate to devote to learning it, so in the meantime I'm waiting for MoN's editor.

We'll see what it looks like, but I think I'll be able to do some really, really nice things with it when it's available

Edit: Which reminds me. Math, what sort of solution have you got in place for editing the event script assembly? Changing that will certainly be a big part of my hack, and while I can do it manually (in xkas) it'd be nice to have something built into the editor


(edited by Gideon Zhi on 11-08-06 01:20 PM)
JaSp

Shyguy








Since: 11-18-05
From: Paris, France

Last post: 6278 days
Last view: 6278 days
Posted on 11-08-06 03:17 PM Link | Quote
I'm also really looking forward to your editor, MoN. I will probably get back into working on my Z3 hack once it is available. Anyway, keep up the good work; I'm sure it will be amazing
So far I've only enhanced/fixed my day-night asm hack (with different sprites in overworld wether it's night or day time!), but I didn't really work on the hack itself (though I have some ideas hanging in my head )
Gideon Zhi

Keese








Since: 12-05-05
From: ...behind you! Boo!

Last post: 6279 days
Last view: 6277 days
Posted on 11-08-06 03:21 PM Link | Quote
I'd actually really like to see that day/night code. I was hoping to have semirandom weather effects built into my hack; day-night stuff would be neat too! So long as I can tweak it to be enabled on a per-world basis - the concept of my hack casts the dark world/golden realm simply as another region of the world where the sun never sets, at least initially.
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6277 days
Last view: 6277 days
Posted on 11-08-06 07:38 PM Link | Quote
Originally posted by Gideon Zhi
Edit: Which reminds me. Math, what sort of solution have you got in place for editing the event script assembly? Changing that will certainly be a big part of my hack, and while I can do it manually (in xkas) it'd be nice to have something built into the editor


There are certain things that I'm going to contemplate editing as far as scripts go. But there really is no unified mechanism in the game that handles "scripts" universally, other than a couple main game modes. e.g. When Ganon pops out of Agahnim, the main game mode variable ($7E0010) changes during that time, and you see a cinema scene. I have already looked at the ending sequence to see how that works (you know, where Link is running away after replacing the Master Sword in the Lost Woods.) So that might be a good place to start, but as for doing most scripting, I think the majority of that will involve doing small trivial asm hacks. The engine of the game just isn't built to handle generalized events.
Googie

390








Since: 11-22-05
From: Corona Queens New York

Last post: 6280 days
Last view: 6280 days
Posted on 11-09-06 02:15 AM Link | Quote
MathOnNapkins: Holy crap, that editor looks fuggin sweet. I'll be sure to try this puppy out when it's released. Straight up, awsome.
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6277 days
Last view: 6277 days
Posted on 11-09-06 02:40 AM Link | Quote
@Googie: I hope you realize that Hyrule Magic is also open in that picture. Don't confuse my limited editor with the fully featured HM. Having HM open was not to mislead, but rather to show that it produces the same results as Hyrule Magic when dealing with dungeon headers.

Originally posted by Reshaper256
On that note, I'll mention that I've created an ASM patch that allows you to individually define which three sprite palettes are loaded to each dungeon room. It effectively separates them from the normal "palette" value used to determine the rest of the room's palettes. I think you might want to include this option in your editor, so I can show you what I did, if you'd like to see.


There are four sprite palettes loaded per dungeon room, I thought . Each 4bpp palette is $20 bytes, and there are $80 bytes of CGRAM for sprites on the SNES. So.... as far as the ASM hack goes, sure feel free to provide it as long as it has a nice clean hook that can operate outside of the original rom's banks.

I can't imagine it would be incredibly difficult to do, but it'd be nice to have something to base it off of. My main guiding principle of adding ASM hacks into the game is to encourage expansion of existing data structures, and as long as the ASM doesn't seem too "niche", I'll probably include it.

The next big step is figuring out how to draw all this messy object business in a clean coded way. Believe me, in ASM this stuff doesn't look pretty. There is an array of routines used drawing each particular object, and while some of them overlap many of them are unique to that object. The object format is also a cluttered mess with 3 main types, each of which can have different subtypes. Function pointers (in C) seem to be the best way to imitate that at this point.


(edited by MathOnNapkins on 11-09-06 01:44 AM)
Googie

390








Since: 11-22-05
From: Corona Queens New York

Last post: 6280 days
Last view: 6280 days
Posted on 11-09-06 11:30 AM Link | Quote
Oh okay, my bad. I hadda been really sleepy last night not to notice that Hyrule Magic was open in the pic, all I remember seeing was just the room & the word Black Magic in the upper left corner.
NEONswift

Bee








Since: 11-18-05

Last post: 6278 days
Last view: 6277 days
Posted on 11-09-06 02:45 PM Link | Quote
Nice to see what youre programming MON. Even if you do call it limited its still something very much needed in zelda. Im sure Black Magic will be awesome to behold once its released.

Being more appreciative of just how complex asm/programming is I find it amazing weve got as far as we have with being able to edit Zelda.

As for an asm hack im working on at the moment...I have a question regarding the custom build HM...Was it you who made it Im having trouble remembering?
Reshaper256

190


 





Since: 11-17-05
From: United States

Last post: 6320 days
Last view: 6277 days
Posted on 11-09-06 03:29 PM Link | Quote
Originally posted by MathOnNapkins
There are four sprite palettes loaded per dungeon room, I thought . Each 4bpp palette is $20 bytes, and there are $80 bytes of CGRAM for sprites on the SNES.
Are you sure there's not $100 bytes (half) of CGRAM designated for sprites, giving you eight 16-color sprite palettes total? I didn't mean that the patch would define all the 16-color sprite palettes for each room, just the three 8-color enemy sprite palettes that change depending on the "Palette" value in the dungeon editor.

As far as I can tell, the sprite palettes you'll find in "Enemies 1" and "Enemies 2" (in HM) are only $10 bytes (8 colors) long, and they only get loaded into three specific spots in CGRAM. (Just for clarification, when I say "enemy" graphics or sprites, I'm referring to sprites such as enemies, pull-switches, townsfolk, etc.) Most "enemy" sprite graphics seem to be drawn by the programmers using only the first 8 of the available 16 colors (although some common enemy graphics were drawn to use the second 8 of those 16 colors instead, like peg-switches). For my own understanding, I've named the first half of each of the eight 16-color sprite palettes in CGRAM "SP-0" through "SP-7." The only "SP slots" that I've ever seen changing depending on the "Palette" value in the dungeon editor are SP-0, SP-5, and SP-6.

Here's a quick description of each 8-color slot:

SP-0 = A palette from "Enemies 2" in HM. Changes depending on the "Palette" value in the dungeon editor. *
SP-1 = The non-changing palette that's the first 8 of the 16 colors used for secondary weapons and stuff.
SP-2 = The non-changing palette also used for frozen enemies and stuff.
SP-3 = The non-changing generic "red" palette, used by a LOT of enemy sprites.
SP-4 = The non-changing generic "blue" palette, used by a LOT of enemy sprites.
SP-5 = A palette from "Enemies 1" in HM. Changes depending on the "Palette" value in the dungeon editor. *
SP-6 = A palette from "Enemies 1" in HM. Changes depending on the "Palette" value in the dungeon editor. *
SP-7 = The non-changing palette that's the first 8 of the 16 colors used for Link.

* The three palette slots my patch allows you to customize for each room.

I don't know if this'll help my explanation or not, but here's a pic to help visualize: paletteinfo.gif

Anyway, values corresponding to the "Enemies 1" and "Enemies 2" palettes in HM get written to $0AAC, $0AAD, and $0AAE in RAM, which cause the corresponding palettes to be written to SP-0, SP-5, and SP-6 in CGRAM. These values are usually determined by the "Palette" value in the dungeon editor, but I've created a new hook to base these three off of a separate table entirely. Right now the new code starts at $21:8000 in RAM, but I know you can easily alter where this is located, so no problem.

Here's the ASM patch: spbr.asm

The table in the patch labeled SPRITE_PALETTE_TABLE contains values for SP-0, SP-5, and SP-6, which can now be defined for each room individually, instead of being tied to the "Palette" value in the dungeon editor. You can edit this table to load whatever palettes you want to SP-0, SP-5, and SP-6. The numbers already in the table are suited for the rooms in a fresh Zelda 3 ROM. For column "0", the values $00 - $0F correspond to the "Enemies 2" palettes in HM. For columns "5" and "6", the numbers $00 - $17 correspond to the "Enemies 1" palettes in HM.


(edited by Reshaper256 on 11-09-06 03:21 PM)
(edited by Reshaper256 on 11-11-06 11:26 PM)
(edited by Reshaper256 on 11-11-06 11:27 PM)
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6277 days
Last view: 6277 days
Posted on 11-09-06 09:25 PM Link | Quote
LDA $A0 : CLC : ADC $A0 : CLC : ADC $A0

The above code is basically LDA $A0 and multiply by three. Just as a hint, it's easier to do this:

LDA $A0 : ASL A : CLC : ADC $A0

Saves two bytes and probably 4-5 cyles.

And yeah... your patch looks pretty straightforward and we're going to have to see what kind of mileage we can get out of the limited $100 bytes of sprite CGRAM. Looking into that in the near future.
Reshaper256

190


 





Since: 11-17-05
From: United States

Last post: 6320 days
Last view: 6277 days
Posted on 11-10-06 12:09 PM Link | Quote
Yeah, I thought there was probably a better way of doing that. Thanks for the advice again.

By the way, I've been thinking that if this patch is included in your program, you might want to make it automatically fill the SPRITE_PALETTE_TABLE with palette values equivalent to what the rooms *would* be according to all the old "Palette" values in the dungeon editor, when you boot an *edited* ROM up for the first time in Black Magic. The current patch is filled with values for an unedited, fresh ROM, but what if you've already edited your ROM with Hyrule Magic? The values in the table wouldn't be right.

The chart below would allow you to convert these values accurately from being based on the "Palette" values for each room in the dungeon editor, to being based on the values in the ASM patch's table. From what I remember, values after 40 for the "Palette" value were really complete gibrish, the values that are read if you go beyond 40 weren't even in the bounds of giving you real values corresponding to actual palettes.

-----------------------------------------
Left column = "Palette" value for room in HM.

(Please ignore the db's, it would've been a hassle to remove them.)

1st hex column = Value to be placed in SP-0 for that room in the table.
2nd hex column = Value to be placed in SP-5 for that room in the table.
3rd hex column = Value to be placed in SP-6 for that room in the table.
-----------------------------------------
00 - db $00, $03, $01
01 - db $00, $03, $01
02 - db $00, $0A, $01
03 - db $00, $01, $07
04 - db $02, $02, $07
05 - db $04, $03, $0A
06 - db $05, $08, $14
07 - db $00, $03, $0A
08 - db $00, $0F, $14
09 - db $02, $00, $07
10 - db $00, $0F, $0C
11 - db $00, $06, $07
12 - db $00, $00, $00
13 - db $05, $05, $0B
14 - db $00, $02, $0C
15 - db $05, $0A, $07
16 - db $00, $10, $0C
17 - db $07, $02, $07
18 - db $00, $07, $0F
19 - db $00, $04, $0C
20 - db $00, $04, $09
21 - db $00, $03, $01
22 - db $00, $04, $04
23 - db $00, $14, $0C
24 - db $05, $07, $0B
25 - db $06, $10, $0C
26 - db $05, $08, $14
27 - db $02, $00, $07
28 - db $00, $03, $0A
29 - db $00, $03, $0A
30 - db $00, $0B, $11
31 - db $00, $0B, $11
32 - db $00, $00, $02
33 - db $08, $13, $0D
34 - db $00, $03, $0A
35 - db $00, $04, $04
36 - db $02, $02, $07
37 - db $0A, $00, $00
38 - db $00, $03, $02
39 - db $00, $03, $07
40 - db $05, $05, $0B

Of course, if there's anything I can do to help with the process of implementing any of this, I'd be happy to help. I don't know C or C++ or whatever you're using to write the editor, however, so I don't know if there's really anything more I could do. Good luck with Black Magic anyway, I'm looking forward to it!


(edited by Reshaper256 on 11-10-06 11:11 AM)
(edited by Reshaper256 on 11-10-06 11:11 AM)
(edited by Reshaper256 on 11-11-06 11:24 PM)
Orochimaru









Since: 11-18-05

Last post: 6293 days
Last view: 6277 days
Posted on 11-10-06 10:11 PM Link | Quote
Awesome stuff Reshaper256!

I already fixed many sprites in many rooms of my hack, it works pretty well and quite easy.

All I did was to test many dungeon rooms and take screenshots where the sprite palettes were obliviously bad, then check their room numbers in HM and batch process them in xkas with your patch.

Bad sprite palettes were about the only graphical thing left to fix in euclid's dungeons so I'm really thankfull you made this public.

Greets!
Reshaper256

190


 





Since: 11-17-05
From: United States

Last post: 6320 days
Last view: 6277 days
Posted on 11-11-06 02:16 PM Link | Quote
Great, glad it helped you already. Be careful to "buffer" your palettes for room transitions, though - if you can leave a room without killing all the enemies, and the screen starts to scroll, you'll see the palettes of your enemies change in the room you're leaving, if they're also not availible in the room you're walking into. It's easy to forget.

I'll eventually get around to extending the patch to include overworld enemy palettes. I'll probably have 3 sets of them for each area, one for the Rain, Pre-Agahnim, and Post-Agahnim stages of the game.


(edited by Reshaper256 on 11-11-06 01:20 PM)
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6277 days
Last view: 6277 days
Posted on 11-11-06 09:44 PM Link | Quote
If we're going to alter those three (8 color) palettes why not also find a way to change the red and blue palettes that don't seem to change? I mean, enough with Red and Blue enemies, they look stale after so long . Also, changing the palettes that the enemies use is not difficult. I think we can get a lot more mileage out of this.

I'm not able to confirm this at the moment, but does anyone know if sprites disappear on a normal room transition? I know they disappear on a "warp" type room transition. And by that I mean anything that uses "Staircase 3 / door" and "Staircase 4 / door" while using a door, not a staircase. Good example is room 1, which exists in Hyrule Castle. It exits to the left and right to rooms 80 and 82. The point of me mentioning this is that I think it might eliminate some worry over sprites changing palettes on room transition. On the other hand, it looks less realistic when your sprites disappear on a room transition . One solution is to use a dark room transition, maybe that would work.

Also, Reshaper, do you realize that the graphics that exist in the rom are preset to use certain color indices? E.g. The red and blue octopi in dungeons have graphics such that they only use certain color indices. (0 through 7). If they were redrawn with more detail and inserted back into the rom, they could use indices 0 through 15. The catch is that you have to fill the second half of those rows in your picture with the necessary palette data. The other, less sinister catch is that graphics that use a full 15 colors will not compress very well. (Which is obviously why they used 8 color sprites, they needed room.) Probably hardly at all compared to the 3bpp versions. Also, if other graphics are already intent on using those colors, this creates a conflict for which sprite gets to use those colors. P.S. I think you should rename your palettes to SP-0 through SP-7 b/c it correlates better with most ways people program.
Reshaper256

190


 





Since: 11-17-05
From: United States

Last post: 6320 days
Last view: 6277 days
Posted on 11-12-06 12:21 AM Link | Quote
Originally posted by MathOnNapkins
If we're going to alter those three (8 color) palettes why not also find a way to change the red and blue palettes that don't seem to change? I mean, enough with Red and Blue enemies, they look stale after so long . Also, changing the palettes that the enemies use is not difficult. I think we can get a lot more mileage out of this.
I agree, although you'll probably find that you'll have to keep some palettes the same practically all the time anyway. For example, fairies use the blue palette, and bees use the red palette, so unless something else drastic is done, it wouldn't be practical for these palettes to ever change since some sprites can appear anywhere. It would still be nice to be *able* to change them, though, so it may be something to look into, especially if we could keep such sprites that can appear anywhere from using them. Concerning actually adding the code to change them, I could add that in the future, unless you beat me to it.

Originally posted by MathOnNapkins
I'm not able to confirm this at the moment, but does anyone know if sprites disappear on a normal room transition? I know they disappear on a "warp" type room transition. And by that I mean anything that uses "Staircase 3 / door" and "Staircase 4 / door" while using a door, not a staircase. Good example is room 1, which exists in Hyrule Castle. It exits to the left and right to rooms 80 and 82. The point of me mentioning this is that I think it might eliminate some worry over sprites changing palettes on room transition. On the other hand, it looks less realistic when your sprites disappear on a room transition . One solution is to use a dark room transition, maybe that would work.
I don't recall sprites disappearing on a normal room transition. Dark room transitions would be an option, as well as closing all such doors and having a "Kill all enemies to open" tag active. I agree that'd look wrong for them to "disappear" when you stepped through a door. I think the palette changing room transition problem is just something a dungeon designer needs to be aware of when placing sprites, but not so big of a problem that it couldn't be avoided fairly easily.

Originally posted by MathOnNapkins
Also, Reshaper, do you realize that the graphics that exist in the rom are preset to use certain color indices? E.g. The red and blue octopi in dungeons have graphics such that they only use certain color indices. (0 through 7). If they were redrawn with more detail and inserted back into the rom, they could use indices 0 through 15. The catch is that you have to fill the second half of those rows in your picture with the necessary palette data. The other, less sinister catch is that graphics that use a full 15 colors will not compress very well. (Which is obviously why they used 8 color sprites, they needed room.) Probably hardly at all compared to the 3bpp versions. Also, if other graphics are already intent on using those colors, this creates a conflict for which sprite gets to use those colors.
Yeah, it's crossed my mind. My biggest hang up with actually trying to make use of this is actually the last thing you mentioned: the fact that those other colors *are* being used by something else. I know that some are used by Link's outfit, his sword and shield, pots and bushes, secondary weapons, peg-switches, etc. I haven't looked into them as much as the other colors generally used by enemy sprites. It certainly would be interesting if we could think of a way to handle these conflicts and harness the extra 8 colors, though.

Originally posted by MathOnNapkins
P.S. I think you should rename your palettes to SP-0 through SP-7 b/c it correlates better with most ways people program.
Actually I was sort of deliberating on doing that, lol, so now that you've brought it up I'll go ahead and change those numbers...


(edited by Reshaper256 on 11-11-06 11:29 PM)
Pages: 1 2Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - Zelda 3 ASM hacks |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.021 seconds; used 447.59 kB (max 573.33 kB)