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 - Lenophis

General Discussion / Re: Firefox users, dig this
« on: February 24, 2009, 09:26:25 PM »
I wasn't aware of this add-on. :blush:
* Lenophis gets

Pandora's Box / Re: Screenshots!
« on: February 23, 2009, 10:31:02 PM »
I don't have 7z. Besides, rar works just as well for something like this.

General Discussion / Re: Sorry for the absence
« on: February 21, 2009, 12:34:13 AM »
Whoo! Be glad to have you back. :happy:

Pandora's Box / Re: Screenshots!
« on: February 19, 2009, 02:32:34 AM »
Prepare to cry:

If the hack were to be released today, that would be the size of the patch. Using WinRAR to compress that down as best it can, the size is 807 KB as a rar, 861 KB as a zip. That's not including everything else that will be included with the patch. So yeah, this is a threshold most translations don't even cross. :eek:

Slick News / Re: Pandora's Box 3rd Anniversay
« on: February 19, 2009, 01:53:50 AM »
I tried tinkering with that a couple of weeks ago, and I had no better luck. It was then I personally decided to give up on any hope of new music.


Oh wait, nothing's broken yet.  :tongue:
Actually, I think SMF broke something. Over the past few days, posts being edited aren't showing up as new to other users over at RHDN and the Compendium.

Slick News / Re: Pandora's Box 3rd Anniversay
« on: February 17, 2009, 11:29:20 PM »
Because FF4, FF5, Secret of Mana, Mario RPG, etc, etc, all use different cores than FF6 does. Yes, I remember that tool you linked to a while ago, but none of us were able to get that to work.

So, there's nothing else we can do.

Slick News / Pandora's Box 3rd Anniversay
« on: February 14, 2009, 02:09:35 AM »

We're back, and we have news! Pandora's Box is now in its third year of development. During the past two years, there have been many features implemented. The list includes restoration of the game's button configuration screen, a music box, Strago learning magic the way he should have, and then some.

We've also dabbled into many engine tweaks, the first and most prominent of them being a complete overhaul of the physical damage formula. This change is part of the massive balance overhaul we are still doing. Other engine tweaks include some additions to the battle and engine cores, as well. To get an idea of those changes, you can view the playlist set up at Youtube.

With a balance overhaul also comes many bug fixes, and in fact many bug fixes. To keep some sanity, a complete list of bug fixes was put together at Mnrogar's Den. These bugs are being fixed to level the playing field on both sides. This will no doubt cause some gripes, but the only thing I can say to that is “if you want to play the broken system, play the broken game.”

But, enough about the past. We're here to stay positive, and talk about the future. And that future is now. So, what's new? To mark the occasion, we are proud to show another new feature recently implemented, a Doom Gaze radar (this is 60 megs!). This radar works like how you would expect a radar to work. If you get close to Doom Gaze, he will show up on the minimap. It will make finding him to be much easier than it ever was. Note, a Youtube version of this movie was made, but the quality of it turned out to be bad enough that the minimap was far too grainy to show off what this did. It has since been removed. Various and numerous attempts were also made to get the filesize of this movie down to a respectable level, but all attempts also made the minimap too grainy to show off this new feature.

“Use a screenshot, fool!”

That won't show you how or when it works, despite anybody's best efforts to do so. Either bite the bullet and download or simply ignore it. And yes, as a dialup user, this is a very hard thing for me to say, but I'm at wit's end about this.

Anyway, another new feature, though not nearly as flashy or even as fancy, is one that will make dialogue nice. For whatever reason, Final Fantasy 6 never had a center tag, it instead used a tab tag. Well, we decided that the tab tag needed to go. In its place, a center tag. Ok, crappy job of building that one up.

Those that have been in RHDN's IRC channel may have noticed me continuously bugging everybody for possible ideas that we could implement into the hack. Gemini did step forward with one, an item that will increase encounter rates. Specifically, this will double the encounter rate. A perfect gift for all of the masochistic grinders out there.

Finally, there's something we've been wanting to show off for a while now. Earlier in development we toyed with changing some of the character spritesheets. One such example was a revision to Mog. We have since expanded on that, giving some alterations to Celes and Edgar.

On a sad note, I am reluctant to announce that I do not believe we'll be able to get anymore new music into the hack. Those that have assisted in the past seemed to have moved on to bigger and better things. To counter this, some have suggested that we learn the inner workings of the SPC700 to get more songs in. However, we feel that delaying the project for another many months to learn the chip just to get a few more songs in is not worth it.

To wrap this up, I'll say that we hope that 2009 will be the final year of development. I won't put a date on when we'll be done, because adding pressure will not ensure quality. We thank those that have been patient with us during this project's development.

Can anybody say "highly abusive?" This could have some interesting uses, even if it was only situational.

General Discussion / Re: Gamefaqs + eternal stupidity
« on: January 29, 2009, 02:01:14 AM »
Do the moderators not even care anymore? I mean, come on. Both boards are falling from "abysmal" to  :omg: :wtf: :bah:

Code: [Select]
C2/239C: AD A8 11     LDA $11A8   (Hit Rate)
C2/239F: 85 E8        STA $E8     (save it for later)
C2/23A1: B9 40 3B     LDA $3B40,Y (Stamina)
C2/23A4: 20 61 28     JSR $2861   ( (255 - Stamina * 2) + 1 , capped at low of 1 and high of 255)
C2/23A7: EB           XBA
C2/23A8: B9 55 3B     LDA $3B55,Y (MBlock)
C2/23AB: 20 81 47     JSR $4781   (Multiplication Function)  (16-bit accumulator now holds your StaminaValue * BlockValue)
C2/23AE: 20 B7 47     JSR $47B7   (Multiplication Function 2: 24-bit $E8 = 16-bit Accumulator * 8-bit $E8)
C2/23B1: A5 EA        LDA $EA     (get 3rd byte of 24-bit $E8.  that's the same as dividing 24-bit $E8 by 65536, or as dividing it by 256, then dividing the quotient by 256.)
C2/23B3: 85 EE        STA $EE     (Save highest byte of StaminaValue * BlockValue * Hit Rate)
C2/23B5: A9 64        LDA #$64
C2/23B7: 20 65 4B     JSR $4B65   (Random Number 0 to 99)
C2/23BA: C5 EE        CMP $EE
C2/23BC: 60           RTS
C2/23BD: EA           NOP
C2/23BE: EA           NOP

^ i just noticed an easy way to shrink that code.  3 points to whoever can point it out first. ;)
Now that I've had another look at it, I'll guess that the LDA $EA STA $EE is completely unnecessary. If that's the case, simply change the CMP $EE at the end to CMP $EA. Correct?

Oh, and another question: say I have a 16-bit value in the accumulator, and set it to be 8-bit. Does the high byte simply disappear, or does it remain so it's still possible to swap the two bytes using XBA, even though I can't perform other operations on it?
The accumulator will remain intact. The X/Y register is different, though. If X/Y is set to be 8-bit, the higher byte of both will immediately become 0.

Stop me if you think this is turning into a beginners assembly class. I'm poking through the code and reading up on 6502 and 65816 assembly now and I have like a thousand questions!
I'll answer what I can. :happy:

So am I correct in my understanding that when using LDA to load an 8-bit value into the accumulator, it simply overwrites the low byte, leaving the high byte untouched? And if it's a 16-bit value, both bytes are overwritten?
That is exactly the case. :happy:

^ i just noticed an easy way to shrink that code.  3 points to whoever can point it out first. ;)
I don't see anything that could be shortened. At first I thought you could do some clever PHA/PLA, but I don't even see that now. That looks like a fairly solid routine though. :happy:

Right. So as far as my understanding goes, what this code does is:

(If attack checks for Stamina, jump here)
1. Get BlockValue for Mblock, previously determined to be (255 - Mblock * 2) + 1 in some other section of the code
2. Store it in the top byte of a two-byte something something? I don't really understand most of the comments. :P
XBA will swap the two bytes of the accumulator. It's useful for things where both bytes of A are used (such as the multiplication functions in C2).

3. Get Hit Rate
4. Multiply high byte by low byte (ie. BlockValue * Hit Rate)
5. Take the top byte again (effectively dividing by 256?)
6. Store as $EE?
7. Get 100
8. Get random number [0..(100-1)], ie. [0..99]
9. See if it's higher than $EE?
10. If it is, attack misses, so skip C bytes ahead, to exit
11. If it isn't, continue and get a random number [0..255]
12. modify it somehow to make it [0..127]? I don't know what this does.
The AND #$7F serves as a "take this result and top it off at 127." Stamina caps at 128, so this maximum makes sense.

13. Store it as $EE
14. Get Stamina
15. Is Stamina higher than $EE?
16. don't know what RTS is, but I'm guessing it's something like, "ok, got our value, now let's go back to where we were and continue on".
RTS = Return from subroutine. "Continue doing what was executing before calling this," essentially.

Short version:

1. Check for Mblock. Does attack miss?
2. If not, check for Stamina.
Accurate summary. :happy:

Okay, so what I tried to do was to modify the Stamina check to take the hit rate of the spell into account while also checking for Stamina and Mblock.

Basically this:
Code: [Select]
1. StaminaValue = (255 - Stamina * 2) + 1

2. BlockValue = (255 - MBlock * 2) + 1

3. BlockValue = StaminaValue * BlockValue / 256

   If BlockValue > 255 then BlockValue = 255
   If BlockValue < 1 then BlockValue = 1

4. If ((Hit Rate * BlockValue) / 256) > [0..99] then you hit, otherwise
      you miss.

And here is the block of code that I wrote/copypasted together:

Code: [Select]
C2/239C: B9 40 3B     LDA $3B40,Y (Stamina)
C2/239F: 20 61 28     JSR $2861   (255 - Stamina * 2) + 1 , capped at low of 1 and high of 255)
C2/23A2: EB           XBA
C2/23A3: B9 55 3B     LDA $3B55,Y (MBlock)
C2/23A6: 20 81 47     JSR $4781   (Multiplication Function)
C2/23A9: EB           XBA
C2/23AA: AD A8 11     LDA $11A8   (Hit Rate)
C2/23AD: 20 81 47     JSR $4781   (Multiplication Function)
C2/23B0: EB           XBA
C2/23B1: 85 EE        STA $EE     (High byte of Mblock * Hit Rate)
C2/23B3: A9 64        LDA #$64
C2/23B5: 20 65 4B     JSR $4B65   (Random Number 0 to 99)
C2/23B8: C5 EE        CMP $EE
C2/23BA: 60           RTS
C2/23BB: EA           NOP
C2/23BC: EA           NOP
C2/23BD: EA           NOP
C2/23BE: EA           NOP
If I'm following you correctly, you want stamina and magic evade to be factors in dodging. Does this mean adding the two together? You aren't really stating how both will be factors in this.

Sorry for the long post, but if you're still here reading this, I'd very much appreciate some help, comments or insights from more experienced hackers.


0. Is my code at all functional? ;)
Judging from your comments, not quite.

1. WHY is it working backwards?
2. Also, if you spot any misunderstandings I've made in trying to understand HOW this works, please comment.
3. Oh, and also, if Stamina > 128, what happens when (StaminaValue * BlockValue) < 1?
This must mean you have raised the stat cap to 256. Is this the case?