øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=339;area=showposts;start=45e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexedf1.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=339e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexedf1.html.zxÚ›h^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ …­Ù—OKtext/htmlISO-8859-1gzip0|ÖÙ—ÿÿÿÿÿÿÿÿWed, 11 Mar 2020 08:22:11 GMT0ó°° ®0®P®€§²ð®Ú›h^@Ù— Show Posts - avalanche

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - avalanche

Pages: « 1 2 3 4 5 6 7 8 9 »
46
Final Fantasy IV Research & Development / Re: Damage + Sap = Can't absorb??
« on: February 08, 2015, 12:01:43 PM »
Such an extensive rewrite of the code would be so much easier with a full assembly language.  Has anybody done coding for hacks using a bona fide assembler? 

47
Final Fantasy IV Research & Development / Re: Damage + Sap = Can't absorb??
« on: February 08, 2015, 10:35:49 AM »
Great!

I've been pondering about how there are several damage-based routines, and several status-inflicting routines.  As far as I can tell, the status inflicting ones are only separate because they deal with different status timers.  They also seem pretty specific in that if they were given an extra status bit that they weren't expecting, they would be buggy.  I wonder if it would be possible to merge them down to one or two, that are able to handle all the statuses and timers specified in the spell record, to make room for entirely new routines.

48
Final Fantasy IV Research & Development / Re: Graphics info
« on: February 08, 2015, 10:30:11 AM »
Uh oh.  Are there monsters that occur in both lunar-AI and non-lunar-AI places?  Do they "work"?

49
Final Fantasy IV Research & Development / Re: Damage + Sap = Can't absorb??
« on: February 07, 2015, 06:52:36 PM »
Well, I think the fix is going to require an assembly modification (just 1 byte changed).  Honestly, it seems like it would make sense to make this tweak anyway.  The Damage-only routine takes an absorbed element, and causes it to heal the target, regardless of whether they are undead.  But the Damage+Sap routine takes an absorbed element and causes it to damage the target when they are undead which seems like a bug to me; something that perhaps never normally occurs with the original spells, so they didn't fix it.  I would just change the absorb check instructions of Damage+Sap to match Damage's behavior as follows:

From:
Code: [Select]
03:D3CF   4C 1C D4    JMP $D41C

To:
Code: [Select]
03:D3CF   4C 26 D4    JMP $D426

That will make Damage+Sap's absorb mode skip over the undead check, too.

50
Final Fantasy IV Research & Development / Re: Damage + Sap = Can't absorb??
« on: February 07, 2015, 04:24:52 PM »
Any chance he's Undead?

I'll go with that working theory for the moment.  The normal damage routine when handling absorbed elements jumps a few instructions past the beginning of the healing routine, the part that converts healing-an-Undead back into the normal damage routine.  The Damage+Sap routine doesn't jump past that Undead check, so it might go from damage+sap -> healing -> damage.  If my guess is correct, and you didn't want to make the enemy not undead, then perhaps you could change Damage+Sap to jump to the same place that the normal damage routine does.  I can be more specific if you confirm my hypothesis.

51
Final Fantasy IV Research & Development / Re: Enemy Special/Magic Attacks
« on: February 07, 2015, 02:13:35 PM »
One quick thing to point out about the math routines.  I believe the division routine at 03:8407 takes two 16-bit parameters.  So if you are not explicitly writing to the second byte, I don't think you can be sure it's a zero which you need it to be.  I'd be worried that you might occasionally get an incorrect result because of whatever value happened to be there from the previous call to the routine.

52
Final Fantasy IV Research & Development / Re: Enemy Special/Magic Attacks
« on: February 05, 2015, 07:13:53 PM »
It is probably because the X register is 16 bits at that time, so it is loading 2 bytes; the power and the following byte.  If there is a non-zero value for that byte, then it would probably result in zero after the division.

There isn't enough room to switch register sizes around that, but you can make room by altering the instructions above that.  If you go up to the start of the routine (03:DD4E, or 1DF4E in the ROM)

From:
Code: [Select]
03:DD4E  AD 09 27    LDA $2709
03:DD51  8D 45 39    STA $3945
03:DD54  AD 0A 27    LDA $270A
03:DD57  8D 46 39    STA $3946
03:DD5A  A2 0A 00    LDX #$000A

To:
Code: [Select]
  AE 09 27  LDX $2709
  8E 45 39  STX $3945
  AD 9D 28  LDA $289D
  AA        TAX

  Then I think that leaves 5 bytes of extra room, so fill with no-ops?  (EA)


Full disclosure, I didn't test this, just scribbled it on paper.


53
Final Fantasy IV Research & Development / Re: Apropos of nothing (except of course FFIV)
« on: February 05, 2015, 06:36:24 PM »
Talk about "apropos of nothing" ...

Dark Knight Cecil using Dart, particularly throwing "item" 0, looks pretty sweet.  It's like he's shooting a red energy bolt from his sword.

54
Final Fantasy IV Research & Development / Re: Apropos of nothing (except of course FFIV)
« on: February 05, 2015, 09:05:54 AM »
Found it.  No separate table, it's just a more or less straight offset.  When the monster-in-the-chest bit (0x40) is on in the trigger data, here's the formula for what encounter is used:
   0x1C0 + (0x20 if current map is >= 256) + (bottom 5 bits of that byte)
Or worded differently:
   If map number is < 256:  0x1C0 + (bottom 5 bits of that byte)
   If map number is >= 256:  0x1E0 + (bottom 5 bits of that byte)

So that allows 1C0-1DF when in the first 256 maps, 1E0-1FF when on map 256+.

55
Final Fantasy IV Research & Development / Re: Apropos of nothing (except of course FFIV)
« on: February 04, 2015, 10:11:58 PM »
For the treasure chests with monsters inside, how are the encounters/monsters determined?

The 4th byte of the trigger data, where Phoenix wrote "total byte = enemy set in Underground/Moon set", even though the upper 2 bits have other meanings, then they all seem to point to a range of encounters that look to me like they only contain a single Imp.  What am I missing?

56
Final Fantasy IV Research & Development / Re: Graphics info
« on: February 04, 2015, 09:52:19 PM »
(I edited my post above before I saw your reply, just in case it doesn't show up as unread...)

57
Final Fantasy IV Research & Development / Re: Graphics info
« on: February 04, 2015, 08:34:31 PM »
Quote from: chillyfeez on February 04, 2015, 08:10:36 PM
Hey, avalanche... I have a quandary you might be able to help with, if you're so inclined...

Somehow, in my project, I seem to have accidentally altered the palette for the visual effect where the moon flies off away from earth (normally part of the ending, but in my hack it's part of the opening events) the visual effect was playing fine for most of the time I've been working on it, but I've been play testing the past week, and the change is noticeable. And horrible.

Now, I know that in most cases, the palettes the game uses are loaded into RAM at 00:0CDB, but I've toyed around with all of the data there to no avail. I've also looked through ALL of the rest of RAM and can't seem to find anything else that looks like a palette. I am therefore unable to trace back to the location in ROM of the palette(s) for this visual effect.

So... Any thoughts? If you happen to know where the palette is in ROM, well, that would be fantastic. If not, any idea where in RAM the elusive palette(s) might be loaded?

Well, not off hand.. Might be able to look into it with no guarantees  :)  Do you know which palettes are messed up? Is it one object in particular that is off?

 :edit:
Okay I got some info.  For that scene, it looks like the entire CGRAM that holds all palette colors is filled from 13:D200 (ROM 9D400) which is normally 256 bytes, but copied twice back-to-back.  Remember that scene has some Mode 7 going on too.

58
Final Fantasy IV Research & Development / Re: Graphics info
« on: February 04, 2015, 07:51:56 PM »
Quote from: Pinkpuff on February 04, 2015, 05:36:26 PM
Doing the best I can. There are some graphical oddities in the Ice Mines currently though. They're using the Feymarch/Sylvan tileset with a blue/white palette but for some reason it looks fine in FF4kster but in the actual game the walls glow red. Also the palette of the battle background is green like the Sylvan cave... is there a way to change that but still have the Feymarch and Sylvan caves keep their colors?

The tileset palette tricks are briefly described here: http://slickproductions.org/forum/index.php?topic=1713.msg22009#msg22009.  The glowing red is because the palette entry is reassigned continuously by the game from a color table elsewhere, and as such it disregards the tileset's palette for those color entries.  With some assembly hacking I'm sure you could make it glow a different color, but I understand that is generally out of bounds for your project.  Too bad, glowing a different color would be a neat effect.

Although, since that tileset has two palettes which are used by the game to control the glowing effects separately, IF you were willing to ditch one of them in the original game areas, then you could very easily modify the other one to the blue you want. 

59
Final Fantasy IV Research & Development / Re: Apropos of nothing (except of course FFIV)
« on: February 01, 2015, 04:46:40 PM »
Quote from: Grimoire LD on January 30, 2015, 09:52:43 PM
Hah! I was completely unaware. Good find indeed Avalanche.

Oh hey, Grimoire, didn't you run into this problem in your hack to change the party by reloading the Big Whale map?

60
Final Fantasy IV Research & Development / Re: Apropos of nothing (except of course FFIV)
« on: January 31, 2015, 12:45:20 PM »
Happy to help.

For what it's worth, here is a short list of those I noted slightly different from the ff4kster dat file.  Numbers in decimal.  Most aren't really useful outside of their current use, but a few might be.

There are exactly 65 of them total (0-64), and there's a table at 00:C195 (ROM at 4395) with routine pointers for each.

  • 5 - puts tent or cabin sprite on screen when using those items
  • 10 - Warp's mechanism (pop location and go there)
  • 11 - Exit's mechanism (go to bottom of stack)
  • 13 - Parks Ship at dock near Fabul
  • 25 - one of the Baron collapsing hallway; slides map under NPCs
  • 26 - one of the Baron collapsing hallway; slides map under NPCs
  • 27 - one of the Baron collapsing hallway; slides map under NPCs
  • 28 - parks Enterprise just outside of Baron (I think the remote control event)
  • 40 - parks enterprise outside of dwarven castle after entering the underground
  • 45 - fly the big whale (from its helm)
  • 46 - remove the parked Enterprise, wherever it is
  • 47 - whale's overworld/moon transition mechanism
  • 59 - I think where enterprise dips to catch you from falling out of Tower of Babil
  • 62 - fades music volume up (I think)
  • 63 - kill all of party, if Cecil (paladin) is in party he gets 1 HP instead (used in final sequence)



Pages: « 1 2 3 4 5 6 7 8 9 »