News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

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.

Topics - justin3009

Pages: [1] 2 3 4
ROM Hacking Discussion / Tales of Phantasia SNES [Script?]
« on: June 03, 2018, 05:31:19 pm »
I'm not entirely sure where to post this but I guess here might be a good choice since it's just a general bit.

How did any of the others figure out exactly how the script works in TOP? Was the original game a lot easier to dump and edit compared to DeJap or any of the other various translations? How difficult was it to do this?

I'm working on TOP right now and the script is something I'd 'hope' to edit way into the future mainly because of adding Brambard/Brambert/Brambald/Rambard as a playable character. Using DeJap's as a base is good for an English translation off the bat, but how the text is handled is confusing the heck out of me. It looks like it may use two tables. One is for the general data and one is for 'after' a capital letter or something. The second table is #$1A less than the first one exactly but still has the same data inside of it.  I'd even work off the JP version if I'm able to properly dump and/or edit the script truthfully. Looks like the JP's data is still pretty complicated to understand as well so this is making it really difficult to work with.

As for DeJap's script:
I'll look at say: 'No'
N = 37
o = 52

So 37 52 would be 'No' in a general table.

But when it's a capital letter first it then looks like this:
N = 37
o = 38

So 37 38 would be 'No' with the 'other' table. It seems after there's a capital letter, it ends up subtract #$1A to get other values or possible even another table.

Any tips on this? I'm pretty baffled at how to even begin modifying or dumping this script.

Programming / Sprite Priority Issues (Mega Man X3) *SOLVED*
« on: September 28, 2017, 04:17:37 pm »
Trying to finalize the armor code for it to display on the NPC version of X, and it works pretty well.. until NPC X walks in front of another character with Armor on.

Right now, NPC X's sprite priority value is set so he'd be placed BEHIND every other character, INCLUDING the Armor pieces that display over top. Altering his priority values doesn't help at all in fixing the issue as if it's not behind everything, he'll be in front of the armor!

With him being behind the armor and walking over, he'll work just fine by walking behind the object because of the priority.. except the Armor is ABOVE everything.

I have absolutely zero idea how to even trace this or figure out what's setting the priority. I'm very baffled on how to fix this. If I was able to find the source this wouldn't be a problem but just trying to figure out exactly how the heck it's doing this is beyond me and the only 'real' bug left with having the NPC's wear Armor.

Edit: The issue. It looks like the only thing going BEHIND is X's head.. for whatever reason.

Edit 2: Aaaaaaaaaaand I just figure it out as I post this. This seems to be a recurring trend every time I have a problem.

Programming / Mega Man X3 FastRom Issues
« on: July 23, 2017, 06:56:07 pm »
So THIS might be one of those cases where I believe it's actually an incompatibility with the game and the CX4 chip, it's what I'm assuming anyway.

Setting the header at 00:FFD5 to be 30 instead of 20 will set the game to be 'FastROM'. Upon doing so, it seems that HDMA and sprites all just break in every possible way. Mainly because the sprites, HDMA and various other wireframe objects all use the CX4 chip to operate. Though I'm entirely unsure why the header change would completely destroy the entire thing since it's still loading the same locations technically at this point, but it seems anything CX4 wise is just broken.

There's not much research on the CX4 chip, and whatever there is is way beyond my head at the moment as I don't think I can really trace anything that's really going on with it. It's all very strange at this point. There could be a feasible work around with sprites by having an actual OAM table in RAM like other games but no clue how to work around it with HDMA and such though.

Anyone have an idea on this area? I'm willing to bet it's a chip compatibility issue but I can't be absolutely sure.

Edit: I've noticed something odd when it's set to FastROM.

Code: [Select]
$05/F8C3 AD 52 7F    LDA $7F52  [$06:7F52]   A:0101 X:0000 Y:0010 P:envMxdIzC
$05/F8C6 CD 8F 08    CMP $088F  [$06:088F]   A:0100 X:0000 Y:0010 P:envMxdIZC
- Good set of code when it's NOT FastROM.

Code: [Select]
$05/F8C3 AD 52 7F    LDA $7F52  [$06:7F52]   A:0101 X:0000 Y:0010 P:envMxdIzC
$05/F8C6 CD 8F 08    CMP $088F  [$06:088F]   A:017F X:0000 Y:0010 P:envMxdIzC
- Bad set of code when it IS FastROM. It seems like whenever it's set to FastROM, it will read that last byte in the LDA as the value it needs to load.. for some reason. It's strange as heck.

Edit: Able to view the CX4 RAM in BSNES. Once it's switched to FastROM, it definitely freaks the hell out horrendously in the CX4 chip RAM. I have NO idea why this would even occur. This is really strange.

Script Help and Language Discussion / Cutting down descriptions
« on: July 03, 2017, 06:04:17 pm »
Kind of a vague topic title but I'm working on a side project with someone to retranslate the Dragon Ball Z - Super Saiya Densetsu SNES RPG.  Item names and descriptions are translated but we're having a tough time cutting down some of the description lengths as they are incredibly specific.

バトルカードのどれか 1まいの[LINE]
ホシのかずを [Z]にしてくれるぞ![END]
Changes 1 Battle Card's <stars> to "Z"!

Changes one[LINE]
battle card's[LINE]
attack to "Z"![END]

テキをさきに みつけることができ[LINE]
のうりょくや バトルカードも[LINE]
Allows you to be able to view opponent's stats and Battle Cards!

Allows you to[LINE]
view enemy's[LINE]
stats and[LINE]
battle cards![END]

Changes all Battle Cards' Attack and Defense power!

Changes all[LINE]
battle cards[LINE]

バトルカードのどれか 1まいの[LINE]
りゅうはを キに ホシ・カンジの[LINE]
かずを [Z]にしてくれるぞ![END]
Changes 1 Battle Card's <school> to KI and sets the <star> and <kanji number> to "Z"!

Changes one[LINE]
battle card to[LINE]
KI and sets[LINE]
attack to "Z"![END]

バトルカードのどれか 1まいの[LINE]
りゅうはを キに ホシ・カンジの[LINE]
かずを [Z]にしてくれるぞ![END]
Changes 1 Battle Card's <school> to KI and sets the <star> and <kanji number> to "Z"!

Changes one[LINE]
battle card to[LINE]
KI and sets[LINE]
to "Z"![END]

The attack/defense on the cards are the corners.  Top left is the attack, bottom right is the defense, just for clarifications sake.

The main goal is to cut all item descriptions down to three lines if possible while still retaining the idea of what they do, but we're struggling like hell to figure out a way to do it with these few descriptions.  This is mainly due to wanting to add a VWF with a 'bolder' font all around but it doesn't allow more than 3 lines of text unfortunately since the text box can't be any taller.

- This image is mainly a mock-up of what it'll be.  However, the layout that is shown is what I have currently.  There is no VWF in-game yet but it's just to show what kind of font that might be used.
Any help would be appreciated!

Programming / Sprite Disappearing Issue
« on: January 07, 2017, 08:25:51 pm »
Going back to test the bigger Peach sprite in SMB2 and I noticed a rather fun oddity.  When you're on the edge of the screen apparently chunks of her sprites disappear because they're hitting, I guess, an odd section of the screen causing it to not loop properly or something.  It has to do with my code, just not entirely sure 'why' it's doing it.

- Here's the image to show what's happening.

Code: [Select]
$94/E1C8 A7 00       LDA [$00]  [$BE:9109]   A:0002 X:0098 Y:0A46 P:envMxdizc ;Load X coordinate of Sprite Assembly
$94/E1CA 09 00       ORA #$00                A:0008 X:0098 Y:0A46 P:envMxdizc
$94/E1CC 85 0E       STA $0E    [$00:000E]   A:0008 X:0098 Y:0A46 P:envMxdizc ;Store temp X coordinate value to 7E:000E
$94/E1CE A5 9D       LDA $9D    [$00:009D]   A:0008 X:0098 Y:0A46 P:envMxdizc ;Load current direction of PC
$94/E1D0 D0 07       BNE $07    [$E1D9]      A:0000 X:0098 Y:0A46 P:envMxdiZc ;If > 0, break to $94/E1D9
$94/E1D2 A5 0E       LDA $0E    [$00:000E]   A:0000 X:0098 Y:0A46 P:envMxdiZc ;Load temp X coordinate value from 7E:000E
$94/E1D4 38          SEC                     A:0008 X:0098 Y:0A46 P:envMxdizc
$94/E1D5 49 FF       EOR #$FF                A:0008 X:0098 Y:0A46 P:envMxdizC ;EOR FF
$94/E1D7 80 02       BRA $02    [$E1DB]      A:00F7 X:0098 Y:0A46 P:eNvMxdizC
$94/E1DB 18          CLC                     A:00F7 X:0098 Y:0A46 P:eNvMxdizC ;Set carry flag
$94/E1DC 6D 28 04    ADC $0428  [$91:0428]   A:00F7 X:0098 Y:0A46 P:eNvMxdizc ;Add PC's screen X coordinates
$94/E1DF 9F 00 08 7E STA $7E0800,x[$7E:0898] A:00FE X:0098 Y:0A46 P:eNvMxdizc ;Store to OAM

It seems odd that they just completely poof off screen.  There's no other code that messes with any of the data either as this is all from scratch.  So what's here is exactly what's here.

Programming / Locking HUD Movement on BG3?
« on: November 13, 2016, 08:09:18 am »
Kind of hard to shorten the title but I think the basic idea of it is there.

What I'm trying to do now is implement a HUD in Super Mario Brothers 2 similar to SMW.  Not really similar per se, but at LEAST have an HUD on screen that can display score, current lives, etc.. without having to use the pause menu for that.

Obviously the only available BG for that kind of data is BG3.  The problem with that is that BG3 is used quite consistently throughout the whole game and it moves around quite a bit so I'm not sure how to go about this.

I've been told before, awhile back I believe, that Super Mario World uses BG3 for the HUD and background stuff as well but the HUD is 'locked' in place.  I'm not entirely sure how to do that or how to go about making that work in all honesty.  All I know is having an HUD would be greatly beneficial and I'm just not sure how to go about adding it in without it deciding to scroll off screen.  There's also the issue of having it appear ABOVE both Layer 1 AND 2.

Programming / Super Mario All-Stars FastROM Issue *SOLVED*
« on: October 29, 2016, 07:45:29 pm »
I'm having an absolute bastard of a time trying to figure this issue out.

So the basic sum up of the project I've done before and now was that I modified Super Mario All-Stars to load SMB2 right away.  All data that I could find relating to the other games in All-Stars has been completely removed pretty much leaving the entirety of the ROM to be for SMB2 only.  After that, I altered how the PC graphics are done so they are specifically their own thing now with Sprite Assembly, Animation Data and graphic pointers and such.  This worked just fine before in bSNES and SNES9X.  ZSNES, ignoring that mainly just fails on start-up after the coin logo but that's not important.

I've converted the ROM to FastROM to allow more sprites on screen without as much lag, thankfully, that works flawlessly in SNES9X and it really shows how much it's improved this way.  The problem comes now with more accurate emulators like BSNES.  I've also made sure 420D is set to 01 so that's not a problem either.

Everything loads up just fine in-game when you start up, select your character and the map loads.  The first frame of the only character I have in thus far, Peach, loads up flawlessly and just fine.  The moment when it has to change frames, however, the entire game bugs the hell out and essentially crashes.

I've searched my code forwards and backwards and I cannot find ANY reason on why this would happen.  Everything loads just fine, everything stores just fine from what I see.  It just.. breaks and seemingly only breaks when the sprite is NOT her single Idle Frame sprite.  I can change that value to anything and it'll just instantly break.

I am absolutely baffled as all the pointers are correct, all banks are correct, all information from what I can tell is correct.  Tracing in BSNES doesn't even help at all either as it leads to the same conclusion so I'm just confused as hell.

Programming / bSNES Issue *SOLVED*
« on: September 16, 2016, 02:24:48 pm »
Code: [Select]
c0f420 jsr $f430     [c0f430] A:0000 X:f6d8 Y:0420 S:01e9 D:0000 DB:83 nvmxdIZC V: 15 H: 800 F: 7
c0f430 ldx #$7000             A:0000 X:f6d8 Y:0420 S:01e7 D:0000 DB:83 nvmxdIZC V: 15 H: 840 F: 7
c0f433 stx $0002     [830002] A:0000 X:7000 Y:0420 S:01e7 D:0000 DB:83 nvmxdIzC V: 15 H: 858 F: 7
c0f436 sep #$20               A:0000 X:7000 Y:0420 S:01e7 D:0000 DB:83 nvmxdIzC V: 15 H: 892 F: 7
c0f438 rep #$10               A:0000 X:7000 Y:0420 S:01e7 D:0000 DB:83 nvMxdIzC V: 15 H: 910 F: 7

c0f43a lda $1946     [831946] A:0000 X:7000 Y:0420 S:01e7 D:0000 DB:83 nvMxdIzC V: 15 H: 928 F: 7
c0f43d sta $4204     [834204] A:0000 X:7000 Y:0420 S:01e7 D:0000 DB:83 nvMxdIZC V: 15 H: 954 F: 7
c0f440 lda #$03               A:0000 X:7000 Y:0420 S:01e7 D:0000 DB:83 nvMxdIZC V: 15 H: 978 F: 7
c0f442 sta $4206     [834206] A:0003 X:7000 Y:0420 S:01e7 D:0000 DB:83 nvMxdIzC V: 15 H: 990 F: 7
c0f445 ldx $4214     [834214] A:0003 X:7000 Y:0420 S:01e7 D:0000 DB:83 nvMxdIzC V: 15 H:1014 F: 7

c0f448 lda $c0f46b,x [c0fa1b] A:0003 X:05b0 Y:0420 S:01e7 D:0000 DB:83 nvMxdIzC V: 15 H:1044 F: 7

So, this code works JUST fine on SNES9X and ZSNES (Yes I know it's inaccurate, just wanted to test on another emulator).  But some reason when using bSNES this whole thing just comes out as a terrible, terrible mess.

What it's doing is it's loading 7E:1946 (Current Item Page) then stores it to 4204.  Then it loads 03 as a hard set value and stores it to 4206 and then X is loaded from 4214 to get the outcome but as you can see it's pulling a completely whacked out value from nowhere, yet, on SNES9X it works just fine.

Is my code just screwy?

Programming / Another Cartographer Issue *SOLVED*
« on: July 30, 2016, 11:37:24 am »
I'm dumping the Techniques and such now in Sailor Moon: Another Story and all's fine and dandy for the most part.  It continually crashes on one specific pointer down the line and I for the life of me cannot figure out why.  There's various pointers that lead to nothing but empty data, and this one is no exception at all, but it just crashes every single time once it hits this specific pointer but everything else BEFORE hand dumps just fine.

Would there be any reason for this?  It dumps perfect up until that one point then it just crashes for god knows what reason.

Code: [Select]
タイム◦ストップ   <END>

//POINTER #43 @ $3C787 - STRING #43 @ $7E591



It's this last one it breaks at.  It's no different from any of the other pointers in pointer wise or even text wise, yet it just breaks at this point for some reason.

Edit: I'm an idiot.  I didn't look closely enough at the pointers.  After a certain point it turned into 2-byte pointers and it'd cause the crash.  No actual problem, just me overlooking the obvious as per usual!

Programming / Cartographer Issue *SOLVED*
« on: July 23, 2016, 11:56:45 pm »
I'm working on dumping the script for Sailor Moon - Another Story and I'm running into a few issues.

First one is that this game uses 3-byte pointers instead of 2-byte, which is fine and dandy and is easier to work with pointer wise in-game, but I'm not sure how to properly set that up in Cartographer.  The method I do have right now keeps throwing an error no matter how I order the sequences.

Code: [Select]
#GAME NAME: Sailor Moon - Another Story (SNES)

#TABLE: SMASJP.tbl //the string address

This is PROBABLY wrong but I assume I have to use POINTER_RELATIVE_PC due to it using 3-byte pointers.  I tried just regular Pointer_Relative or even Pointer and it does not work with 3 bytes.  It instantly crashes the program.  I wouldn't mind splitting the text up by banks.. but they're all kind of intermeshed in the pointer table itself.  Some are $C5, some $C6, some $C8 and $C9 and they're pretty sporadic in a few instances.  It's a mess.  Not entirely sure what to do here.

Could I get a little help on deciphering what these characters are?  I've got the rest of the table labeled out completely, just these characters are a bit out of my hand.  Minus the obvious uh.. P there.

There's no context on these, just flat out characters in numerical order.

Programming / Tracking Where to Write Tiles In VRAM
« on: July 10, 2016, 09:53:25 am »
This is probably overly complicated for what I'm trying to do in-game, as was seen in the HDMA topic, of trying to get the dialogue boxes to write on BG 1 instead of BG 3 which would allow much more sleek looking designs and allow possible themes as well.

The problem I'm seriously having right now is how to properly track where in VRAM to write the tiles depending on the PC's location on screen.  If it was just plain 256x256 size it'd be no problem but the game uses 512x256 on all maps including the menu originally.  (The menu is now forced to be 256x256 as it's much easier to work with in that area).  The method's I've seen are from Chrono Trigger and Final Fantasy 6.  FF6's wouldn't work due to the game always being in 256x256 from what I can see while Chrono Trigger is 512x256, like BOF II.  The problem therein lies with how Chrono Trigger is using HDMA to properly switch the BG1/3 Tile Map but also retaining the original tile map location as well for the tiles.  Honestly not sure how the heck this works and it's probably the best way to go, but it's also overly complicated and hard to figure out.

The method that may be easiest is just to track the PC's location as you're on screen but that becomes complicated since most of BOF II's maps have more than one location on it but it gets cut off from view as you're moving.  Setting it to 256x256 actually kind of broke this so I'm not sure that's plausible but just setting it to 256x256 in general cuts the layer data in half which would need a tile map rewrite.. which is a bit of a pain considering one half of Layer 1 is at 9800 and the other half is at A000.. so they both fill their portions to the brim and I don't think there's an easy way to 'merge' them for a bit during dialogue without some funky issues.

Minus that, tracking the player is a bit obnoxious because of the multiple location on screen issue.  There could be a building that's say 100 tiles up from you but it's cut off from view, but you're currently in an area that's 100 tiles below and there's no plausible way to reach the above location unless you're 'forced' there from an exit.  So the X/Y camera coordinates could easily be 00 00 or they could be 40 FF which is kind of an ass to work with.

Honestly, I'm not sure how to track this properly nor do I know if this is the best way to go.  If I understood more on how Chrono Trigger uses HDMA for that I could probably replicate it to an extent but it's incredibly tricky.

If I could get any tips on this it'd be wonderful or maybe even a better method.  If worst comes to worst I'll just drop it back to Layer 3 and that'll be that.  I was hoping for Layer 1 mainly because the menu looks all spiffy but then the dialogue box is just.. bland.

Programming / HDMA Question (SNES)
« on: July 01, 2016, 05:15:17 pm »
I'm rather curious on this and I'm extremely confused on how the heck Chrono Trigger is handling it.

I'm trying to rework the dialogue box a bit in Breath of Fire 2 so it can also keep the pretty looking tiles thus allowing multiple themes whenever it gets implemented... but of course that's not really possible due to how honestly most SNES games work.

As far as I can see, it looks like Chrono Trigger has HDMA that may actually read the tilemap data specifically for the dialogue box, although I could be wrong?  Honestly I'm not sure what it's doing but it's using Layer 1 to draw the dialogue box as well as everything else it needs while retaining the full quality like the menu and such.

Any idea how this works?  There may be other games that do this but I have honestly not seen any other game (Or that I can remember) that uses Layer 1 or 2 as dialogue box needs while keeping the background tiles and such where they are.

Programming / Save Game Compression [SNES]?
« on: May 22, 2016, 06:51:19 pm »
I'm rather curious if anyone knows of a method to compress certain data or even combine two bits of data into one just to make things smaller for SRAM.  I'm noticing Tales of Phantasia somehow stores a ludicrous amount of data unlike Breath of Fire 2.. which also uses only three saves as well but I can't quite make heads or tales of what's going on.

I'm wondering if anyone has any experience with something like this?  I'd seriously help out with what I'm hoping to do and I can't think of any other way to do it other than compressing some of the stats down into a single byte or so.

ROM Hacking Discussion / Interesting things in a ROM
« on: May 18, 2016, 03:43:40 pm »
Kind of a spin-off topic to the 'Ever notice weird things in a ROM?' topic, thought it might be fun to post some interesting finds or unique things that go unnoticed, unused or what not!

The first thing I noticed awhile back when I was working on DBZ: Legend of the Super Saiyan SNES RPG, the English translations actually leave out some dialogue.  I cannot remember which exactly, but there were a few more bits of dialogue with Kami and more with Nappa and such too!  This is one of the main reasons why I want to retranslate the game is to figure out what's being said.  Heck, they could even be unused dialogue lines in all honesty!

Super Mario RPG has technically enough room to support another PC.  A few things have to be shifted to fully allow it, but otherwise the basic data to detect what equipment they use and even some space is allotted for it.  The biggest problem there was the sprite data and such.  That obviously does not exist nor is there room for it, but they do leave enough room to state which palette to use, which equipment, and I think some RAM technically as well.  Makes me curious if Luigi was originally going to be apart of it.

Breath of Fire 2.  I just decided to take a look at the Shamanization system in-depth a bit and it turns out that the 'Holy' shaman that gives an unused stat would have actually given a luck boost!  I couldn't understand why it didn't work but it turns out that they have a separate RAM location that stores how much of a boost you get.  Weirdly, it's only read when you fuse and never anywhere else.. which would explain why you'd have to refuse after you level up to get the complete stat changes.  By looking at that though, it turns out that the developers completely forgot to add in a routine that updates the Luck stat which is why the boost never occurs!  I'm half tempted to release a patch to remedy this but it would actually require some guides to rewrite the Shaman stats. 

The system has bits to change for Offense, Defense, Vigor, Wisdom, Luck (Technically), AP and what graphic to use when the form occurs.  What's more interesting is that after the PC graphic there's an unused bit that actually lets you DECREASE stats at your choosing!  I looked through all the forms and this goes completely unused.  I wonder if maybe they had failed forms that would decrease stats or something?  Either way, it's quite handy and I'm surprised they even have it fully coded to work properly too.

Programming / Atlas Importing Issue
« on: March 27, 2016, 05:14:34 pm »
So I noticed when I was extracting the script and then reinserting into the game I'm working on that the script would suddenly EXPLODE.

I took a closer look inside the ROM and it looks like some of the text pointers actually link up into some of the same dialogue.. but it actually ends up writing the same string TWICE on importing causing it to explode in size.


String #1:
'Go fetch this person! <NEW PAGE>'
'This person is located here! <END>'

String #2:
'This person is located here! <END>'

In this case, String #2 actually loads the string #1's end, 'This person is located here! <END>', but writes it again separate as a different pointer and the same dialogue!  This happens quite often throughout the script and is causing some huge irregularities.

Is there anyway around this?  It's really causing issues on fixing things up.

Edit: There's even huge cases further down the road where the same pointer is repeated about 40 times.. but it actually writes them all as separate pointers and separate dialogue although they're the exact same thing.

ROM Hacking Discussion / Breath of Fire II - What Would You Change?
« on: March 06, 2016, 09:53:04 am »
I'm not sure if this would go in Gaming Discussion or ROM Hacking Discussion.. forgive me about that.  What exactly would you change about this game to improve it being game play, aesthetics, attacks, equipment, characters, etc.?

1. Personally, I think some party members should be more optional along the way, mainly Jean as an example.  I'm not a fan of him whatsoever and he doesn't seem very viable in any instance.. not too mention his story portion of the game is one gigantic pain in the ass mundane task that does nothing.  I'd love for it to be a huge side-quest where you could get him, obviously he'd have to be rebalanced, but it'd be more interesting to me in that aspect.  It'd be interesting to see Nimufu come into play as a little guest character as well.  I'd say Ray for that very temporary part of the game as a 'hard set' PC with no chance of full recruitment as well.  Obviously a lot of work for something so little, but a bit more variety doesn't hurt.

2. I'd kill for more background on Patty (Yua)'s life.  There's hardly any mention of her at all by Ryu or even anyone else in the game world, what the heck actually happened to her throughout her years?

3. Variety of weapons kind of like Breath of Fire 1 as a very slim example.  Having Ryu being able to use the Boomerang or a Sword was actually a really nice touch.

4. More Shaman form variations.  I know they gave story reasons for Ryu being the Brood and all.. which is a bit weird considering he's only half-brood.  Either way, I'd say allow him to fuse with Shamans.  In this instance, I'd say a good trade off would be he gains enhanced stats depending on the Shaman, like other PCs, but to compensate for the overly destructive blood, one of his other stats would have to go down.  (Gear wise this could be easily made up since he seems to have more equipment than half of anyone).

5. Maybe a bit more inclusion on Myria near the end of the game.  The final boss is a spawn of her, but it'd be a bit more satsifying to hear more about her as you continue in the game, just remnants of the past.  Maybe even have Deis say something about it here and there.  (Though the fact she's playable was really forced in at last second as seen by her non-existent stab table and random checks to specifically check for her in code).

Programming / Screen Flashing Issue
« on: February 09, 2016, 11:00:28 am »
I've had similar issues before, more-so with just a couple issues writing to VRAM with background data.. but I'm having a HUGE issue with this in my SMB2 hack.

The original routine stored both PC graphics and the POW/Flask/Orb crystals as one giant section of code instead of separating it.  So both graphics were stored essentially at the same time in the same routine with the storage of 07 to 420B.

I broke the original routine off and have it storing the PC graphics top and bottom separately (Which it also did in the original) as it's own routine, then the POW/Flask/Orb graphics as a separate routine.. but for some reason this new routine is causing HUGE screen flickering issues.

Code: [Select]
Top Storage of PC Sprites
$13/8B57 AE EF 02    LDX $02EF  [$11:02EF]   A:1801 X:0000 Y:0080 P:envmXdIZC ;Load bank of PC graphic
$13/8B5A 86 04       STX $04    [$00:4304]   A:1801 X:002F Y:0080 P:envmXdIzC
$13/8B5C AD F0 02    LDA $02F0  [$11:02F0]   A:1801 X:002F Y:0080 P:envmXdIzC ;Load how many bytes to send to VRAM
$13/8B5F 85 05       STA $05    [$00:4305]   A:0080 X:002F Y:0080 P:envmXdIzC
$13/8B61 A9 00 60    LDA #$6000              A:0080 X:002F Y:0080 P:envmXdIzC ;Load where to store sprites into VRAM
$13/8B64 8D 16 21    STA $2116  [$11:2116]   A:6000 X:002F Y:0080 P:envmXdIzC
$13/8B67 AD ED 02    LDA $02ED  [$11:02ED]   A:6000 X:002F Y:0080 P:envmXdIzC ;Load pointer to PC sprites
$13/8B6A 85 02       STA $02    [$00:4302]   A:A800 X:002F Y:0080 P:eNvmXdIzC
$13/8B6C A0 01       LDY #$01                A:A800 X:002F Y:0080 P:eNvmXdIzC ;Set bit for storage into VRAM
$13/8B6E 8C 0B 42    STY $420B  [$11:420B]   A:A800 X:002F Y:0001 P:envmXdIzC ;Store to VRAM

Code: [Select]
Bottom Storage of PC Sprites
$13/8B71 AD F0 02    LDA $02F0  [$11:02F0]   A:A800 X:002F Y:0001 P:envmXdIzC ;Load how many bytes to send to VRAM
$13/8B74 85 05       STA $05    [$00:4305]   A:0080 X:002F Y:0001 P:envmXdIzC
$13/8B76 A9 00 61    LDA #$6100              A:0080 X:002F Y:0001 P:envmXdIzC ;Load where to store sprites into VRAM
$13/8B79 8D 16 21    STA $2116  [$11:2116]   A:6100 X:002F Y:0001 P:envmXdIzC
$13/8B7C AD ED 02    LDA $02ED  [$11:02ED]   A:6100 X:002F Y:0001 P:envmXdIzC ;Load pointer to PC sprites
$13/8B7F 18          CLC                     A:A800 X:002F Y:0001 P:eNvmXdIzC
$13/8B80 69 00 02    ADC #$0200              A:A800 X:002F Y:0001 P:eNvmXdIzc ;Add $200 to get bottom piece of sprites
$13/8B83 85 02       STA $02    [$00:4302]   A:AA00 X:002F Y:0001 P:eNvmXdIzc
$13/8B85 8C 0B 42    STY $420B  [$11:420B]   A:AA00 X:002F Y:0001 P:eNvmXdIzc ;Store to VRAM

Is there anything wrong with this routine?  I'm really confused on why it's causing screen flickering.  It seems to only happen when it STORES to VRAM.  So if I remove the 8C 0B 42 on both, obviously nothing gets stored but it ends up not screen flashing anymore which singles it out to be this area.  Even if I just use ONE of them to store to VRAM, it causes screen flicker.. I don't understand why.

Personal Projects / Super Mario Bros. 2 Deluxe! [SNES]
« on: February 04, 2016, 06:20:24 pm »
Probably seems kind of an odd project to go with especially since my various other ones seem to be RPGs or Mega Man X... but yeah!

What this project is aiming to do is modify SMB2 and 'enhance' it to an extent.  My friend and I are NOT going to go the whole route of adding every single bit of the GBA's new stuff into this game as that is not what is intended.  Some features will be added from it (Though a couple actually come from BS Mario 2) but it won't be a direct port by any means.

This project itself is quite the undertaking so it may or may not be finished (Much like my many others it seems) but some MAJOR strides have been done!

So what exactly has been going on so far?

The first bit was forcing Super Mario All-Stars to load SMB2 on the fly. As soon as I figured out how to do that, I removed as much of the other Mario game's code as possible. I'm sure I missed quite a bit of the actual 'ASM' for the other games, but their graphics, music, level data, etc.. has been removed to allow for over 1MB of extra space. So now when All-Stars is booted, it'll do the whole coin blip with the Nintendo logo then shoot right into the SMB2 title screen!

The second aspect I realized after studying the code a bit was how incredibly ludicrous the graphic storage for PC's were along with their animation data. Everything was hard-coded to the frikin 'T'. Even animations were flat out coded instead of having a routine to set things up properly. Of course, since all characters share the same data this wasn't a big deal for this game, but for what we hope to do it was incredibly hindering.

What has been done?

1. The entire PC graphic routine has been rewritten from ground up. The main routine that stored PC graphics was actually shared with the POW/Crystal Orb/Flask.. for whatever reason. I have no clue why they did that. Now, the POW/Orb/Flask routine has been split and set into it's own bit and their graphics in VRAM have been shuffled to accommodate for much larger PC graphics.

2. The PC graphic routine, as I said, has been rewritten ground up. The routine NOW loads the PC graphics based on what 'frame' is currently in RAM (Stored at 7E:02F3 now since that value goes unused from removing the old code). The code checks what PC you are then loads the frame that you're on. It then loads the proper data for that specific PC and that specific frame and THEN stores the graphics into VRAM.

So basically:

00 - Standing Still
01 - Walking Frame #1
02 - Walking Frame #2

This is done to allow for flexibility on how to handle graphics the way I hope to use them.  Of course, the data has to be properly setup in ROM. Right now, it reads 3 bytes to get the pointer to the PC graphics. It then reads the following 2 bytes to dictate HOW much of the data to send to VRAM. This way we can clearly specify how much we want from the current section.
3. Animation data has been added.  I'm still rather iffy on this as I feel like it could be handled much better, but we'll see in the future.  Right now, everything works as it should.

What 'Animation Data' is basically how each animation is setup.  Say for.. walking.  It's value is 02 which gets stored to 7E:00C7 (Current PC Action).  It reads that value and loads a per PC basis table up, gets the pointer and the current frame and loads the animation data.  In that section there's three bytes technically in total.  The first byte is ALWAYS the frame you want to load, the second byte is the delay until the next frame, the 'third' byte is technically an end.  Set it to 'FF' and it'll stop reading the animation data, reset the values and start loading it from the beginning.  There's NUMEROUS animations in the game for Peach at the moment, mostly the basics but there's quite a few 'new' ones too.

4. The game will sport a 'new' HUD.  The hearts are now horizontal instead of vertical for positioning reasons.  With that, there is now a coin counter, life counter and a score counter!  The score counter will be similar to SMW and BS Mario 2 in which you get points depending on your action.  The coin counter will be the same as other Mario games.  Get 100 coins, get a 1-up.  These coins OFFICIALLY replace the cherries.  All maps will be edited accordingly to allow for coin collection.  However, as of right now, there is no current way to get a 'Starman' quite yet.

What needs to be done?
1. Animation data is in the middle of it's third reworking.  This time is hopefully the last.

2. A WHOOOOOOLE lot of redoing for the other PCs, enemies and various objects.  I want to extend this animation data/sprite assembly code out to EVERYTHING in game, not just the PCs.

3. Big and small sprites. This one I don't think will be TOO hard. I could technically use the life value in RAM to dictate that so that'd make things easier.  We'll see though, depends on what I have planned in the future.

4. Add a check in the animation data if you're holding something or not. All this will do is add a specific number of bytes to load 'new' animations with your hands up for all frames. I'm actually thinking of splitting this off into it's own section for PCs as well but we'll see.

Video update:

Programming / Sprite Mirroring Issue *SOLVED*
« on: February 03, 2016, 06:31:10 pm »
I'm a bit confused on how mirroring technically works when you have more than two 16x16 tiles or a plethora of 8x8 tiles.  Obviously the sprite gets 'mirrored', but there's got to be something more to it as there's a pretty clear bug going on.

The sprite that's actually assembled properly is what it should look like, but the moment you turn left.. it turns into that mess.  The bottom 16x16 tile is fine as it but the top two flip.. completely.  I thought it was just them interchanging positions but it's not that either as the X coordinates are also quite off.

Is there any specific method that anyone knows that games commonly use to flip them all properly?  I've noticed with MMX that it even flips tiles properly upside down, while this game will switch the two tiles and then flip them upside down.  I'm not exactly sure what MMX does as it does most of it's work using the CX4 chip so that was kind of a bust.

Any help would be greatly appreciated!

Pages: [1] 2 3 4