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

Author Topic: bad coding in roms  (Read 34371 times)

snarfblam

  • Submission Reviewer
  • Hero Member
  • *****
  • Posts: 586
  • CANT HACK METROID
    • View Profile
    • snarfblam
Re: bad coding in roms
« Reply #100 on: March 05, 2014, 05:44:30 pm »
In most cases, a game with significant slowdown is probably just poorly programmed, or outright asking too much of the hardware. I've heard that the FDS versions of Metroid and Zelda exhibit less slowdown. I don't know if that's true, but if it is, there's really no excuse for worse NES performance other than a hurried port.

Are there any other NES games that use an AI system for player 2? I mean, something more code-intensive, like shooting in all directions and jumping, not just moving around.

In Conquest of the Crystal Palace, when you summon your little dog buddy, he runs all around the screen attacking enemies and avoiding obstacles, and he seems to do a pretty decent job too. He even seems to be able to traverse moving platforms with some success. No slow down to speak of, either.

OneCrudeDude

  • Full Member
  • ***
  • Posts: 110
    • View Profile
Re: bad coding in roms
« Reply #101 on: March 06, 2014, 12:48:56 pm »
To be completely fair, Contra Force doesn't have a whole lot going on in the first place.  The enemies don't do anything spectacular, just sit there and throw grenades, and there rarely appears to be more than two enemies on screen.  There's less going on in this game than there is in Contra and Super C, both of which push a lot of action with minimal and short lived slowdown.  And game speeds up as soon as the enemies die, so maybe their attacking processes are incredibly unoptimized.

gauveldt

  • Jr. Member
  • **
  • Posts: 47
    • View Profile
Re: bad coding in roms
« Reply #102 on: March 07, 2014, 06:13:12 am »
Code: [Select]
9.  $C2/801A 9D 7E 31    STA $317E,x[$7E:3544]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/801D 9D 80 31    STA $3180,x[$7E:3546]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/8020 9D 82 31    STA $3182,x[$7E:3548]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/8023 9D 84 31    STA $3184,x[$7E:354A]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/8026 9D 86 31    STA $3186,x[$7E:354C]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/8029 9D 88 31    STA $3188,x[$7E:354E]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/802C 9D 8A 31    STA $318A,x[$7E:3550]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/802F 9D 8C 31    STA $318C,x[$7E:3552]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/8032 9D 8E 31    STA $318E,x[$7E:3554]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/8035 9D 90 31    STA $3190,x[$7E:3556]   A:0140 X:03C6 Y:2000 P:envmxdizc
    $C2/8038 9D 92 31    STA $3192,x[$7E:3558]   A:0140 X:03C6 Y:2000 P:envmxdizc 
    $C2/803B 9D 94 31    STA $3194,x[$7E:355A]   A:0140 X:03C6 Y:2000 P:envmxdizc

Tales of Phantasia

It's used to erase item names when you scroll down the list.  Not sure why it was used like this.

Decided to write a mini loop for this sucker just to make it easier.

This has the appearance of loop unrolling.  You might have to give the programmers slack here as they were probably dealing with performance issues throughout the game due to the potential for audio streaming to occur at any time and were probably living in machine cycles the entire coding process.  In that case their mindset would have been on fast code over compact code and lots of loop unrolling is what you get.

March 07, 2014, 06:45:58 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Because then you would be setting the carry flag instead of clearing it. ;)

I think it's intended in the example since the first example is a sep #MEM8 : clc : adc #CONSTANT where the second is sep #MEM8+CARRY : adc #CONSTANT-1 (carry==1 cancels the -1).  The CONSTANT-1 math would be done in the assembler (so it has no effect on runtime cycles).  The former example adds 1 byte of ROM space and several clock cycles for the clc where the second example is a good optimization that eliminates the extra byte and saves cycles.  The second example would be far preferable in anything being looped or otherwise frequently utilized, say like IRQ or NMI handlers.
« Last Edit: March 07, 2014, 06:45:58 am by gauveldt »

oziphantom

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
Re: bad coding in roms
« Reply #103 on: July 27, 2015, 11:57:29 am »
Ok Thread resurrection!
Seeing as what I'm about to post is
a.) in line with this topic and starting another one when there was this one seems wrong
b.) features a lot of IS bashing which is what I'm going to be posting
c.) we are not suppose to post large reams of code, but this post is about large reams of code..
I think it is valid...

Panel De Pon/ Tetris Attack
OH DEAR, somebody had ROM to burn and was not afraid to do it...

Some highlights include
Code: [Select]
_noOverflow                      rep #$20 ;a 16 bit
                                 asl 
                                 asl 
                                 asl 
                                 sep #$20 ;a 8 bit
                                 lsr 
                                 lsr 
                                 lsr 
                                 xba 
                                 pha 

Or this, which I put down to being  a macro but they could have done better than this
Code: [Select]
                                 ldy #$A952
                                 jsr addVRAMtoDMATable
                                 plb 
                                 bra _skipCode
                                 .long $7E2800
                                 .word $06C0,$0080
                                 .byte $78
_skipCode                        bra j80A971

Most of the time the bra jumps to an RTS. Clearly written by a different programmer than the Decompress routine as that is master class.
Code: [Select]
One calls it like so
                                 jsr decompress_src_dest ;will make pc+6 for return
                                 .long $94AF3B,$7F5D00
                                 phb 
And then the start of the function is as such
decompress_src_dest              php 
                                 rep #$30 ;a,x,y 16 bit
                                 phb 
                                 phx 
                                 phy 
                                 sep #$20 ;a 8 bit
                                 lda $09,s ;read calling bank
                                 pha 
                                 plb  ;set to be data bank r
                                 rep #$20 ;a 16 bit
                                 lda $07,s ;read calling address
                                 tax 
                                 clc 
                                 adc #$0006 ;skip 6 src,dest bytes
                                 sta $07,s ;save back into stack to fix return address

July 27, 2015, 12:07:58 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Due to post char limits ...

Lets plot the blocks shall we?
Code: [Select]
pltBlock_ABlock_YMapIndex        phx 
                                 phy 
                                 rep #$30 ;a,x,y 16 bit
                                 phb 
                                 phk 
                                 plb 
                                 ldx CurrentRowToVRAMLUTPtr
                                 stx jl7E0024
                                 and #$00FF
                                 asl 
                                 tax 
                                 lda Player1_Tile_Map_00_0,y
                                 bit #tileType.bounceMode2
                                 bne _rock
                                 bit #tileType.solidBlock
                                 bne _isSolidBlock
                                 bit #tileType.darkPallete
                                 bne _isDarkPallete
                                 bit #tileType.shockFace
                                 bne _isShockFace
                                 bit #invalid
                                 bne _isBounceMode
                                 bit #tileType.bounceMode
                                 bne _isBounceMode
                                 tya 
                                 and #$FEFF
                                 tay 
                                 lda (jl7E0024),y
                                 tay 
                                 jsr (plotNormalLUT,x)
                                 jmp _exit
_isDarkPallete                   tya 
                                 and #$FEFF
                                 tay 
                                 lda (jl7E0024),y
                                 tay 
                                 jsr (plotDarkLUT,x)
                                 jmp _exit
_isShockFace                     tya 
                                 and #$FEFF
                                 tay 
                                 lda (jl7E0024),y
                                 tay 
                                 jsr (plotWinceLUT,x)
                                 jmp _exit
_flash                           tya 
                                 and #$FEFF
                                 tay 
                                 lda (jl7E0024),y
                                 tay 
                                 jsr (plotFlashLUT,x)
                                 jmp _exit
_isBounceMode                    tya 
                                 and #$FEFF
                                 tay 
                                 lda (jl7E0024),y
                                 tay 
                                 jsr (PlotBounceLUT,x)
                                 jmp _exit
_rock                            tya 
                                 and #$FEFF
                                 tay 
                                 lda (jl7E0024),y
a85859C                          tay 
a85859D                          jsr (plotRockLUT,x)
                                 jmp _exit
_isSolidBlock                    tya 
                                 and #$FEFF
a8585A7                          tay 
a8585A8                          lda (jl7E0024),y
                                 tay 
                                 lda a7E0354
                                 bne b8585B6
                                 jsr (jp858EAB,x)
                                 jmp _exit
b8585B6                          jsr (jp858EF5,x)
                                 jmp _exit
_exit                            plb 
                                 ply 
                                 plx 
                                 rtl 
.snip.
Code: [Select]
plotNormalLUT                    .word <>clearTile ,<>plotHeart ,<>plotCircle ,<>plotUpTriangle
                                 .word <>plotStar ,<>plotDiamond ,<>plotDownTriangle ,<>plotExclamationBlock
plotDarkLUT                      .word <>clearTile ,<>plotDarkHeart ,<>plotDarkCircle ,<>plotDarkTriangle
                                 .word <>plotDarkStar ,<>plotDarkDiamond ,<>plotDarkDownTriangle ,<>plotDarkExclamationBlock
plotWinceLUT                     .word <>clearTile ,<>plotWinceHeart ,<>plotWinceCircle ,<>plotWinceUpTriangle
                                 .word <>plotWinceStar ,<>plotWinceDiamond ,<>plotWinceDownTriangle ,<>plotFlashExclamationBlock
plotFlashLUT                     .word <>clearTile ,<>plotFlashHeart ,<>plotFlashCircle ,<>plotFlashUpTriangle
                                 .word <>plotFlashStar ,<>plotFlashDiamond ,<>plotFlashDownTriangle ,<>plotSolidBlock
PlotBounceLUT                    .word <>clearTile ,<>plotFullyRaisedHeart ,<>plotFullyRaisedCircle ,<>plotFullyRaisedTriangle
                                 .word <>plotFullyRaisedStar ,<>plotFullyRaisedDiamond ,<>plotFullyRaisedDownTriangle ,<>plotFullyRaiseExclamationBlock
                                 .word <>plotRaisedHeart ,<>plotRaisedCircle ,<>plotRaisedTriangle ,<>plotRaisedStar
                                 .word <>plotRaisedDiamond ,<>plotRaisedDownTriangle ,<>plotRaisedExclamationBlock ,<>plotHeart2
                                 .word <>plotCircle2 ,<>plotUpTriangle2 ,<>plotStar2 ,<>plotDiamond2
                                 .word <>plotDownTriangle ,<>plotExclamationBlock2 ,<>plotSquishedHeart ,<>plotSquishedCircle
                                 .word <>plotSquishedTriangle ,<>plotSquishedStar ,<>plotSquishedDiamond ,<>plotSquishedDownTriangle
                                 .word <>plotSquishedExclamationBlock ,<>plotHeart ,<>plotCircle ,<>plotUpTriangle
                                 .word <>plotStar ,<>plotDiamond ,<>plotDownTriangle ,<>plotExclamationBlock
plotRockLUT                      .word <>plotSingleRockBlock ,<>plotLeftEdgeRockBlock ,<>plotMiddleRockBlock ,<>plotEndRockBlock
plotSolidLUT                     .word <>plotSolidBlock
And then there is the actual plot code - brace yourself I have left the HEX in so you can see the patterns as well
Code: [Select]
85/87AC BB          clearTile                        tyx 
85/87AD A9 00 00                                     lda #$0000
85/87B0 9F 00 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_0,x
85/87B4 9F 02 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_1,x
85/87B8 9F 40 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_0,x
85/87BC 9F 42 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_1,x
85/87C0 60                                           rts 
85/87C1 BB          plotHeart                        tyx 
85/87C2 A9 A0 04                                     lda #blockTileMap.heart_TL
85/87C5 9F 00 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_0,x
85/87C9 A9 A1 04                                     lda #blockTileMap.heart_TR
85/87CC 9F 02 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_1,x
85/87D0 A9 A2 04                                     lda #blockTileMap.heart_BL
85/87D3 9F 40 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_0,x
85/87D7 A9 A3 04                                     lda #blockTileMap.heart_BR
85/87DA 9F 42 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_1,x
85/87DE 60                                           rts 
85/87DF BB          plotCircle                       tyx 
85/87E0 A9 A4 04                                     lda #blockTileMap.circle_TL
85/87E3 9F 00 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_0,x
85/87E7 A9 A5 04                                     lda #blockTileMap.circle_TR
85/87EA 9F 02 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_1,x
85/87EE A9 A6 04                                     lda #blockTileMap.circle_BL
85/87F1 9F 40 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_0,x
85/87F5 A9 A7 04                                     lda #blockTileMap.circle_BR
85/87F8 9F 42 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_1,x
85/87FC 60                                           rts 
85/87FD BB          plotUpTriangle                   tyx 
85/87FE A9 A8 04                                     lda #blockTileMap.upTriangle_TL
85/8801 9F 00 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_0,x
85/8805 A9 A9 04                                     lda #blockTileMap.upTriangle_TR
85/8808 9F 02 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_1,x
85/880C A9 AA 04                                     lda #blockTileMap.upTriangle_BL
85/880F 9F 40 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_0,x
85/8813 A9 AB 04                                     lda #blockTileMap.upTriangle_BR
85/8816 9F 42 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_1,x
85/881A 60                                           rts 
85/881B BB          plotStar                         tyx 
85/881C A9 AC 04                                     lda #blockTileMap.star_TL
85/881F 9F 00 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_0,x
85/8823 A9 AD 04                                     lda #blockTileMap.star_TR
85/8826 9F 02 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_1,x
85/882A A9 AE 04                                     lda #blockTileMap.star_BL
85/882D 9F 40 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_0,x
85/8831 A9 AF 04                                     lda #blockTileMap.star_BR
85/8834 9F 42 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_1,x
85/8838 60                                           rts 
85/8839 BB          plotDiamond                      tyx 
85/883A A9 B0 08                                     lda #blockTileMap.diamond_TL
85/883D 9F 00 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_0,x
85/8841 A9 B1 08                                     lda #blockTileMap.diamond_TR
85/8844 9F 02 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_1,x
85/8848 A9 B2 08                                     lda #blockTileMap.diamond_BL
85/884B 9F 40 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_0,x
85/884F A9 B3 08                                     lda #blockTileMap.diamond_BR
85/8852 9F 42 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_1,x
85/8856 60                                           rts 
85/8857 BB          plotDownTriangle                 tyx 
85/8858 A9 B4 08                                     lda #blockTileMap.downTriangle_TL
85/885B 9F 00 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_0,x
85/885F A9 B5 08                                     lda #blockTileMap.downTriangle_TR
85/8862 9F 02 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_0_1,x
85/8866 A9 B6 08                                     lda #blockTileMap.downTriangle_BL
85/8869 9F 40 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_0,x
85/886D A9 B7 08                                     lda #blockTileMap.downTriangle_BR
85/8870 9F 42 20 7E                                  sta BG1_VRAM_TMAP_MIRROR_1_1,x
85/8874 60                                           rts 

« Last Edit: July 27, 2015, 12:07:59 pm by oziphantom »

NES Boy

  • Full Member
  • ***
  • Posts: 147
    • View Profile
Re: bad coding in roms
« Reply #104 on: May 01, 2017, 06:27:47 pm »
I just discovered an instance of bad coding in the first Mega Man game.

At the end of the battle with CWU-01P, the color $3D is loaded into the sprite palette line. How did this happen? Well, the battle with CWU-01P calls for a series of colors in offset 0x01F520-0x01F525, with the next color being loaded with each incarnation of CWU-01P destroyed. Destroying the last CWU-01P has the game attempt to load a color at offset 0x01F526, which has a native byte of BD.

Kea

  • Jr. Member
  • **
  • Posts: 53
    • View Profile
Re: bad coding in roms
« Reply #105 on: May 01, 2017, 10:06:23 pm »
You could fill a book writing about mysterious coding decisions by TOSE, who (among other projects) were responsible for the GBA  Final Fantasy ports. Some examples from their work on Final Fantasy I & II: Dawn of Souls:

-There are separate routines for copying party member's stats from general to battle RAM, for the start of battle and between every action respectively; but the second routine is called soon after the first, before these stats are used for anything, rendering it almost completely redundant. Also, in the first routine the Monk's unarmed critical rate is calculated as Stamina; in the second it's Level*2.

-Many data tables are duplicated. For instance, there are four identical copies of the monster stats table scattered throughout the ROM. All four are used by different areas of the game's code.

-Continuing with monster stats, each entry in the table has a byte indicating the AI that monster uses, however it is never read. Instead a separate table for monster AI bytes is used whenever the game needs to find a monster's AI.

-Similarly, entries in the spell data table have an 'animation byte' indicating what animation to play when cast. This byte is read only when a player character casts a spell; when monsters cast spells they use the spell's ID to index to the animation tables.

-Many routines are in the ROM, but are never called or referenced. Often their effects have been incorporated into routine(s) that might have called them.
-A few routines will load a RAM value into a register then immediately overwrite it with a constant or second RAM value.

-In general, there's quite a few vestigial leftovers of NES/PSX-era formulas. For instance, damage spells roughly operate off a formula of: (Int+Luck)/2 + (Int/10 *  SpellPow). At the same time, it also replicates the original 'doubling' mechanic, where a spell's accuracy is compared against the target's Magic Resistance - except instead of doubling damage, if the spell 'hits' it adds a measly Intellect/5 to damage.

(Oh, and player characters with over 200 Resistance take take 25% damage from spells; those with 199-100 take 50% damage; and those with <100 take 87.5% of normal damage. Monsters' Resistance stat doesn't apply in this way.)

FAST6191

  • Hero Member
  • *****
  • Posts: 2372
    • View Profile
Re: bad coding in roms
« Reply #106 on: May 02, 2017, 02:33:57 am »
While some of those speak to many coders, odd porting and bad coding I do also have to wonder if some of those are anti cheat. I know many of their games were not trivial to make cheats for.

On spell animations does it do anything to account for bosses or large sprites? If all the PCs are the same height and with same broad sprite animation types it could make for an animation that looks odd on a massive sprite.

The many tables thing has me curious. Would it line up with the size of banks in an earlier system at all? I am still quite prepared to believe multiple coders created their own array/table/incbined a table independently of each other -- it is poor coding form  but it is not like you have to be nice to ROM hackers.

Mugi

  • Full Member
  • ***
  • Posts: 227
  • Personal text
    • View Profile
    • Blacklabel-translations
Re: bad coding in roms
« Reply #107 on: May 02, 2017, 05:03:37 am »
honestly, this is my favourite so far...



the birthday string, instead of being %s: %02d.%02d, decided that it's better if it's %s: %d%d.%d%d and has no less than 8 branches on the code that prints it to ensure things like hiding the digits that are 0, ofcourse, regardless of the fact that this game has a routine to align text per screen, or per relative location (think a text area laid on the screen) it was decided that the better way to do it is to manually define the position of each string, and digit, and their shadows. It literally took me a week to fix this thing simply due to the fact that realigning the numbers required rewriting X and Y for each number and each number's shadow separately, then remove the code that hides the first digits if they're 0 and some praying later it works.

this game is an infinite source of ....interesting programming solutions :P
In PSP we trust.

Kea

  • Jr. Member
  • **
  • Posts: 53
    • View Profile
Re: bad coding in roms
« Reply #108 on: May 02, 2017, 08:42:59 am »
While some of those speak to many coders, odd porting and bad coding I do also have to wonder if some of those are anti cheat. I know many of their games were not trivial to make cheats for.

On spell animations does it do anything to account for bosses or large sprites? If all the PCs are the same height and with same broad sprite animation types it could make for an animation that looks odd on a massive sprite.

The many tables thing has me curious. Would it line up with the size of banks in an earlier system at all? I am still quite prepared to believe multiple coders created their own array/table/incbined a table independently of each other -- it is poor coding form  but it is not like you have to be nice to ROM hackers.

For spell animations, differences between monster and PCs are handled in the animation script and script processing code themselves; both use the same scripts overall. A lot of the effects are general enough to work for both small PCs and big monsters, f.x. "animate this tile in the center of the target's sprite", or "play this animation in the center of the targets' side of the field". A few spells play very different animations depending on who's casting (Thundaga's is much shorter when cast by monsters), but again that's taken care of inside the script.

The monster data tables are located at 0x1DE044, 0x223F4C, 0x227054, and 0x22A880. I'm not familiar enough with segmented-memory systems to know if that fits with any previous FF1 port's banks, but I do think this was probably a case of multiple coders including the same table. The first is used for the Bestiary, the second is used to update monster stats mid-battle, the third is used when generating monster stats at the start of battle, and the fourth is used when checking if a monster is Regenerating type at the end of each round.

It might be that some of these things were deliberate, if so it seems like a pretty crude anti-cheat. Most likely they didn't mind if they had redundant data or used up extra ROM space by accident so long as it worked - 16MB is plenty of space.

Chronosplit

  • Hero Member
  • *****
  • Posts: 1154
    • View Profile
Re: bad coding in roms
« Reply #109 on: May 02, 2017, 11:11:01 am »
Isn't Pokemon Red/Green pretty broken anyways?
SELECT Pokemon corruption! :P
Now that's a hallmark in bad coding.  I tip my hat to Red++ actually fixing bugs because that's a long road even with the disassembly, especially for something with a remake that uses a completely different non-crap engine.

Some things that are not-so-well-known:
-With the correct sequence, you can walk through walls all the way past Mt. Moon before beating Brock.  Without codes.
-Beating the optional first match with Gary before a certain point will have Prof. Oak give you Poke Balls when you talk to him (5, which became what you get all the time at the start).  This prompt is scrambled to heck.
-If you combine the missingno glitch and the seafoam shore glitch, even weirder things will happen.

nesrocks

  • Hero Member
  • *****
  • Posts: 516
    • View Profile
    • nesrocks.com
Re: bad coding in roms
« Reply #110 on: May 02, 2017, 01:13:11 pm »


What is this monstrosity you ask? It's a list of positions for the lava balls in Super Pitfall. Basically, it's a "rendered" arc animation with small pseudo-random jittering. Seriously, instead of using a simple formula for arc motion the programmers decided screw math and wrote the positions for each frame manually. There are dozens of other examples for that game, but this is the dirtiest one. The section with the arc motion isn't depicted here as it doesn't fit, this is just the jitter section.
« Last Edit: May 02, 2017, 01:25:55 pm by nesrocks »

Madsiur

  • RHDN Patreon Supporter!
  • Full Member
  • *****
  • Posts: 173
  • FF6 hacker
    • View Profile
Re: bad coding in roms
« Reply #111 on: May 24, 2017, 04:54:33 am »
Not really bad coding but more lazy behavior, all thew SNES FF3us dummy code has been ported to FF6 Advance. The next thing might not be bad coding either since my knowledge of GBA Thumb is limited but they seems to have taken FF3us code and maybe use an 65816 / Thumb converter because code is the exact same structure and registers IDs used are generally the same except that for 10 SNES instructions you have 30 Thumb instructions... (even SPC registers like $13XX are used for music calls, likely switching to GBA audio registers later).

Kallisto

  • Sr. Member
  • ****
  • Posts: 457
    • View Profile
Re: bad coding in roms
« Reply #112 on: May 24, 2017, 01:47:00 pm »
Lot of you guys should do extra-pay work for these companies to fully repair their old codes in games.

NES Boy

  • Full Member
  • ***
  • Posts: 147
    • View Profile
Re: bad coding in roms
« Reply #113 on: June 08, 2018, 10:04:54 pm »
I was looking up information regarding the Rockman Complete Works games when I stumbled upon some trivia in this walkthrough. Apparently due to a coding bug, this hint at the beginning of Fire Man's stage in Navi Mode doesn't show up:


Interestingly, this was translated (not quite well, I may add) in Mega Man Anniversary Collection, despite the bug not being fixed:
Quote
Fireballs from the ground can be transformed by the ice weapon, but the Magma below is all gone!