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

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

Myria

  • Jr. Member
  • **
  • Posts: 49
    • View Profile
Re: bad coding in roms
« Reply #60 on: December 17, 2012, 09:37:11 pm »
Silly MIPS trick to do absolute value in 8 bytes instead of 12:

bgtz a0, label
label:
subu a0, zero, a0

Funny story with the delay slot stuff:  When I was in college/university, our required class on assembly language had MIPS as the processor of choice.  By this point, I had been hacking PS1 games for a few years, so I was well-versed in MIPS.  Because I was reverse engineering MIPS code, I was used to the delay slot.  In forward programming of MIPS assembly code, most people seem to rely on the assembler's default reordering of instructions - including the way that the professor taught the class.

When I turned in my written final, the professor gave me a bad grade because my code didn't look like it could possibly work.  He actually didn't even know about the MIPS delay slot, and I had to explain it - and how assemblers hide it.
« Last Edit: December 17, 2012, 09:52:21 pm by Myria »

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: bad coding in roms
« Reply #61 on: December 17, 2012, 09:52:59 pm »
Silly MIPS trick to do absolute value in 8 bytes instead of 12:

bgtz a0, label
label:
subu a0, zero, a0
(but that should...

no wait...)

>witchcraft.gif

edit: When I did MIPS for a class in high school, we actually did have to know about the delay slot. When I took the same class at college level (because there simply isn’t anything that transfers like that), we had to program like it didn’t exist and I was like aw come onnnn!

Of course, my guess is you would want to avoid a branch on a modern pipelining processor but I’m no expert or anything.
we are in a horrible and deadly danger

henke37

  • Hero Member
  • *****
  • Posts: 643
    • View Profile
Re: bad coding in roms
« Reply #62 on: December 17, 2012, 11:53:33 pm »
Nice trick, I shall remember it for the time I need to do it. Too bad that all modern processors already have an abs instruction.

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: bad coding in roms
« Reply #63 on: December 18, 2012, 12:33:12 am »
Modern processors like what? :huh:

Anyway, this implementation is really only for architectures with branch slot delay like MIPS and... SPARC, I guess, out of all the things you’re likely to ever code on. For performance purposes, branching is something to avoid in general unless you are seriously starved for bytes (in which case, why are you using a RISC processor anyway?). For most uses nowadays a generic integer absolute is best accomplished by something like:
Code: [Select]
long abs(long x) {
long temp = x >> LONGSIGNBITSHIFT; // (sizeof(long)<<3)-1, which is 31 on a lot of current archs
return (x^temp)-temp;
}
which inlines to three instructions on most architectures if you don’t need to save anything.
we are in a horrible and deadly danger

assassin

  • Full Member
  • ***
  • Posts: 134
    • View Profile
    • My Barren Webpage
Re: bad coding in roms
« Reply #64 on: December 18, 2012, 01:54:50 am »
^ how does that work?  First off, I'm assuming you want temp to be (x >> LONGSIGNBITSHIFT) << LONGSIGNBITSHIFT .  If not, I'm utterly lost.  In my test of input value -3, assuming longs are 16 bits, I get a return value of 32765 - 32768 = -3 .  If you flip it so temp-(x^temp) is returned, negative input values seem to work, but positive ones won't.

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: bad coding in roms
« Reply #65 on: December 18, 2012, 02:08:38 am »
examples:
x = 0 = 0x00000000
temp = x >> 31 = 0x00000000
x^temp-temp = (0^0)-0 = 0-0 = 0

x = 1 = 0x00000001
temp = x >> 31 = 0x00000000
(x^temp)-temp = (1^0)-0 = 1-0 = 1

x = -1 = 0xFFFFFFFF
temp = x >> 31 = 0xFFFFFFFF
(x^temp)-temp = (0xFFFFFFFF^0xFFFFFFFF)-0xFFFFFFFF = 0-(-1) = 1

x = -3 = 0xFFFD
temp = x >> 15 = 0xFFFF
(x^temp)-temp = (0xFFFD^0xFFFF)-0xFFFF = 0x0002-(-1) = 3

^ is a bitwise XOR in C, in case that isn’t clear.

Basically, it all works off several ideas:
- To negate a number in two’s complement, you flip the bits and add 1.
- XOR changes a value if you mask with a 1, and leaves alone if you mask with a 0.
- For a non-negative number, shift-extending the sign bit throughout all bits gives you a mask of all zeroes or ones
- Thus, XORing all bits in a number with its sign bits will flip the bits if the number is negative, and let it be otherwise
- Subtracting by negative one is the same as adding by negative one; adding zero wastes a little time but hurts nothing.
- You’re only bothering to do these extra operations because the time cost is peanuts compared to what branching might do. In general, on modern pipelining / branch-predicting architectures, it is worth replacing a single if statement with a couple of arithmetic statements if you can manage it.
« Last Edit: December 18, 2012, 02:16:47 am by BRPXQZME »
we are in a horrible and deadly danger

Myria

  • Jr. Member
  • **
  • Posts: 49
    • View Profile
Re: bad coding in roms
« Reply #66 on: December 18, 2012, 02:19:08 am »
^ how does that work?  First off, I'm assuming you want temp to be (x >> LONGSIGNBITSHIFT) << LONGSIGNBITSHIFT .  If not, I'm utterly lost.  In my test of input value -3, assuming longs are 16 bits, I get a return value of 32765 - 32768 = -3 .  If you flip it so temp-(x^temp) is returned, negative input values seem to work, but positive ones won't.

It's based on an identity from two's complement integer arithmetic: for all x, -x == ~x + 1.  Also, note that ~x == x ^ -1, and that ~x + 1 == ~x - (-1).

The first statement with the "temp" is using signed shifting.  It's copying the sign bit into all other bits.  In short, it means: long temp = (x < 0) ? -1 : 0;

If x is positive or zero, temp becomes zero.  XORing with 0 and subtracting 0 both do nothing, so it returns x.
If x is negative, temp becomes -1.  XORing with -1, as noted above, is equivalent to NOTing.  Subtracting -1 is equivalent to adding 1.  The follows the identity -x == ~x + 1, so the result in this case is -x.

assassin

  • Full Member
  • ***
  • Posts: 134
    • View Profile
    • My Barren Webpage
Re: bad coding in roms
« Reply #67 on: December 18, 2012, 02:19:57 am »
Ah, thanks.  I was assuming the right shift was logical versus arithmetic, getting nonsense results, then figuring you needed a left shift in there.  :-[

The XOR was an early hang up, which I eventually got past.  ("The exponent isn't making any sense, and there's no way he'd save speed with that anyway.  So that symbol must be an OR, because I remember what AND is.")

Pascal and 65816 assembly are the only two languages I've used in years, so clarifying that symbol was a good call on your part.  :)

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: bad coding in roms
« Reply #68 on: December 18, 2012, 02:27:10 am »
>> is logical or arithmetic depending on the signedness of a variable.

I thought I had clarified that, but it turns out it got deleted at one of the draft stages. I’m in finals mode and shouldn’t be posting at the moment :P
we are in a horrible and deadly danger

Myria

  • Jr. Member
  • **
  • Posts: 49
    • View Profile
Re: bad coding in roms
« Reply #69 on: December 18, 2012, 01:42:48 pm »
branching is something to avoid in general unless you are seriously starved for bytes (in which case, why are you using a RISC processor anyway?).

I was making GameShark codes, where each extra instruction was two full codes the player had to enter.  This led to other optimization techniques, such as NOPing an instruction with a single GameShark code by overwriting the high word with 0x2400, which converts the instruction to "addiu zero, zero, 0xABCD".

Bongo`

  • Sr. Member
  • ****
  • Posts: 337
  • Hatred is an illness...I feel your pain.
    • View Profile
    • Dynamic Designs
Re: bad coding in roms
« Reply #70 on: December 18, 2012, 01:55:22 pm »
I'm working on this weirdly programmed SNES game right now. Not sure if it can even be called bad, but it is certainly weird. It turns the NMI off and waits manually for vblank each frame to do its drawing; it NEVER uses 8-bit mode, only 16-bit; it uses long addressing (24-bit) way too often; it does this very simple variation of an LZ compression where it writes directly to VRAM and reads it back from VRAM for back references, etc.
That game sounds like Gaia Saver. :)
R.I.P Rose Mary C. 11/20/1937 - 2/11/2007
Dynamic-Designs Over 30 years of video game experience!
Completed: Doraemon RPG, Fuzzical Fighter, Gulliver Boy, Just Breed, FEDA, Mystic Ark, Slayers ( Co-op ), Lennus-II
Current: Aretha-2 and many more...

assassin

  • Full Member
  • ***
  • Posts: 134
    • View Profile
    • My Barren Webpage
Re: bad coding in roms
« Reply #71 on: December 27, 2012, 12:18:55 pm »
from Secret of Evermore:
Code: [Select]
8F/804E: A9 00 01     LDA #$0100
8F/8051: 8D 07 0B     STA $0B07    (Dog attack = Level 1:0)
8F/8054: A9 00 01     LDA #$0100   (will set weapon level to 1, and advancement
                                    within level to 0)
8F/8057: 8D DD 0A     STA $0ADD    (bare hands [you can't ever fight with them] = Level 1:0)
8F/805A: 8D DF 0A     STA $0ADF    (Bone Crusher = Level 1:0)
8F/805D: 8D E1 0A     STA $0AE1    (Gladiator Sword = Level 1:0)
8F/8060: 8D E3 0A     STA $0AE3    (Crusader Sword = Level 1:0)
8F/8063: 8D E5 0A     STA $0AE5    (Neutron Blade = Level 1:0)
8F/8066: 8D E7 0A     STA $0AE7    (Spider's Claw = Level 1:0)
8F/8069: 8D E9 0A     STA $0AE9    (Bronze Axe = Level 1:0)
8F/806C: 8D EB 0A     STA $0AEB    (Knight Basher = Level 1:0)
8F/806F: 8D ED 0A     STA $0AED    (Atom Smasher = Level 1:0)
8F/8072: 8D EF 0A     STA $0AEF    (Horn Spear = Level 1:0)
8F/8075: 8D F1 0A     STA $0AF1    (Bronze Spear = Level 1:0)
8F/8078: 8D F3 0A     STA $0AF3    (Lance = Level 1:0)
8F/807B: 8D F5 0A     STA $0AF5    (Laser Lance = Level 1:0)
                                   (oops, what about the Bazooka?  leaving it at its
                                    default of 0 causes bugs with the computer-controlled
                                    character and with Energize.)

this is just done when you start a new game, so there's no reason to have unrolled the loop.  however, as with a couple of prior posters' examples, it presents an opportunity to fix something without extra space usage: there's a bug resulting from the game never setting $0AF7 to 0100h to initialize the Bazooka's level. :)

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: bad coding in roms
« Reply #72 on: January 02, 2013, 07:59:37 am »
I just noticed a game that uses the usual 12x12 fixed-width font approach for its Japanese text. That means that the rendering differs between characters on odd and even positions; however, instead of checking this in advance the game always renders the character as if it were on an even position, and then goes on to overwrite it with the odd version if the position actually is odd. So the character is actually rendered twice every second time!

Zoinkity

  • Hero Member
  • *****
  • Posts: 557
    • View Profile
Re: bad coding in roms
« Reply #73 on: January 05, 2013, 12:14:17 am »
Compilers Gone Wild!

ADDIU   SP,SP,FFF8
SW   S8,0000 (SP)
ADDU   S8,SP,R0
SW   A0,0008 (S8)
ADDU   SP,S8,R0
LW   S8,0000 (SP)
ADDIU   SP,SP,0008
JR   RA
NOP

The value isn't even used (dummied out debug routine most likely) but seriously?  At the least they could write:
JR   RA
SW   A0,0000 (SP)

It isn't just this either.  A lot of this title copies SP to S8 before copying it back and correcting it.  This just happened to be the shortest (and most ridiculous) example.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6463
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: bad coding in roms
« Reply #74 on: April 01, 2013, 05:39:56 pm »
I suppose it's not so much bad as weird.

Famicom Board Game bankswap code:

Code: [Select]
00:830C:A9 00     LDA #$00
 00:830E:2C A9 01  BIT $01A9 = #$00
 00:8311:2C A9 02  BIT $02A9 = #$00
 00:8314:2C A9 03  BIT $03A9 = #$00
 00:8317:84 01     STY $0001 = #$00
 00:8319:A8        TAY
 00:831A:B9 23 83  LDA $8323,Y @ $8323 = #$DC
 00:831D:99 23 83  STA $8323,Y @ $8323 = #$DC
 00:8320:A4 01     LDY $0001 = #$00
 00:8322:60        RTS

Strange that it would use odd values for bank numbers.
Code: [Select]
DC 11011100
D9 11011001
D6 11010110
D3 11010011
Looks like the last two bits are the CHR bank to swap in, and D2-D3 are an inverted copy. I suspect it has something to do with bus-conflicts, but why the odd values?

Using the BIT instruction to essentially auto-ignore an instruction. The game would jump to the line that LDA (A9 xx) the appropriate bank number to swap in.
Quote
Sir Howard Stringer, chief executive of Sony, on Christmas sales of the PS3:
"It's a little fortuitous that the Wii is running out of hardware."

Bisqwit

  • Sr. Member
  • ****
  • Posts: 368
  • Polite, but politically incorrect.
    • View Profile
    • http://iki.fi/bisqwit/
Re: bad coding in roms
« Reply #75 on: April 04, 2013, 12:54:55 pm »
Famicom Board Game bankswap code:
Code: [Select]
00:830C:A9 00     LDA #$00
 00:830E:2C A9 01  .DB $2C : LDA #$01
 00:8311:2C A9 02 . DB $2C : LDA #$02
 00:8314:2C A9 03 . DB $2C : LDA #$03
If it weren't so widely known and used by now, I would call that code clever, not weird or bad.

The LDA+STA pair is odd, though. Which mapper is this?
« Last Edit: April 04, 2013, 01:02:06 pm by Bisqwit »

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6463
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: bad coding in roms
« Reply #76 on: April 04, 2013, 01:20:36 pm »
CNROM (mapper 3)
Quote
Sir Howard Stringer, chief executive of Sony, on Christmas sales of the PS3:
"It's a little fortuitous that the Wii is running out of hardware."

justin3009

  • Hero Member
  • *****
  • Posts: 1559
  • Welp
    • View Profile
Re: bad coding in roms
« Reply #77 on: April 04, 2013, 01:23:58 pm »
Load Klarth
Code: [Select]
$C0/6D75 E2 20       SEP #$20                A:0000 X:0000 Y:6B91 P:envmxdiZc
$C0/6D77 B9 1B 00    LDA $001B,y[$7E:6BAC]   A:0000 X:0000 Y:6B91 P:envMxdiZc - Loads PC2 Status
$C0/6D7A 89 06       BIT #$06                A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6D7C F0 03       BEQ $03    [$6D81]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6D81 B9 18 00    LDA $0018,y[$7E:6BA9]   A:0000 X:0000 Y:6B91 P:envMxdiZc - Loads if poison is active
$C0/6D84 89 80       BIT #$80                A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6D86 F0 03       BEQ $03    [$6D8B]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6D8B AD 67 06    LDA $0667  [$7E:0667]   A:0000 X:0000 Y:6B91 P:envMxdiZc - Checks Victory status
$C0/6D8E F0 04       BEQ $04    [$6D94]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6D94 B9 BA 00    LDA $00BA,y[$7E:6C4B]   A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6D97 D0 07       BNE $07    [$6DA0]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6D99 A9 00       LDA #$00                A:0000 X:0000 Y:6B91 P:envMxdiZc - Loads idle animation
$C0/6D9B 99 79 00    STA $0079,y[$7E:6C0A]   A:0000 X:0000 Y:6B91 P:envMxdiZc - Stores to character animation
$C0/6D9E 80 04       BRA $04    [$6DA4]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6DA4 C2 20       REP #$20                A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/6DA6 64 0A       STZ $0A    [$00:000A]   A:0000 X:0000 Y:6B91 P:envmxdiZc
$C0/6DA8 64 0C       STZ $0C    [$00:000C]   A:0000 X:0000 Y:6B91 P:envmxdiZc
$C0/6DAA B9 00 00    LDA $0000,y[$7E:6B91]   A:0000 X:0000 Y:6B91 P:envmxdiZc - Character position in battle (Where do they stand)
$C0/6DAD 29 FF 00    AND #$00FF              A:0601 X:0000 Y:6B91 P:envmxdizc
$C0/6DB0 0A          ASL A                   A:0001 X:0000 Y:6B91 P:envmxdizc
$C0/6DB1 AA          TAX                     A:0002 X:0000 Y:6B91 P:envmxdizc
$C0/6DB2 BD 4F 06    LDA $064F,x[$7E:0651]   A:0002 X:0002 Y:6B91 P:envmxdizc - Load X coordinates in battle
$C0/6DB5 85 04       STA $04    [$00:0004]   A:0070 X:0002 Y:6B91 P:envmxdizc
$C0/6DB7 AD 05 06    LDA $0605  [$7E:0605]   A:0070 X:0002 Y:6B91 P:envmxdizc
$C0/6DBA 38          SEC                     A:0090 X:0002 Y:6B91 P:envmxdizc
$C0/6DBB ED 4F 06    SBC $064F  [$7E:064F]   A:0090 X:0002 Y:6B91 P:envmxdizC
$C0/6DBE 18          CLC                     A:0000 X:0002 Y:6B91 P:envmxdiZC
$C0/6DBF 65 04       ADC $04    [$00:0004]   A:0000 X:0002 Y:6B91 P:envmxdiZc
$C0/6DC1 10 01       BPL $01    [$6DC4]      A:0070 X:0002 Y:6B91 P:envmxdizc
$C0/6DC4 85 04       STA $04    [$00:0004]   A:0070 X:0002 Y:6B91 P:envmxdizc
$C0/6DC6 D9 04 00    CMP $0004,y[$7E:6B95]   A:0070 X:0002 Y:6B91 P:envmxdizc - PC 2 X coordinates
$C0/6DC9 F0 20       BEQ $20    [$6DEB]      A:0070 X:0002 Y:6B91 P:envmxdiZC
$C0/6DEB C2 20       REP #$20                A:0070 X:0002 Y:6B91 P:envmxdiZC
$C0/6DED 22 DE AF C1 JSL $C1AFDE[$C1:AFDE]   A:0070 X:0002 Y:6B91 P:envmxdiZC

Load Mint
Code: [Select]
$C0/46D5 E2 20       SEP #$20                A:0000 X:0000 Y:6B91 P:envmxdiZc
$C0/46D7 B9 1B 00    LDA $001B,y[$7E:6BAC]   A:0000 X:0000 Y:6B91 P:envMxdiZc - Loads PC2 Status
$C0/46DA 89 06       BIT #$06                A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/46DC F0 03       BEQ $03    [$46E1]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/46E1 B9 18 00    LDA $0018,y[$7E:6BA9]   A:0000 X:0000 Y:6B91 P:envMxdiZc - Loads if poison is active
$C0/46E4 89 80       BIT #$80                A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/46E6 F0 03       BEQ $03    [$46EB]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/46EB AD 67 06    LDA $0667  [$7E:0667]   A:0000 X:0000 Y:6B91 P:envMxdiZc - Checks Victory status
$C0/46EE F0 04       BEQ $04    [$46F4]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/46F4 B9 BA 00    LDA $00BA,y[$7E:6C4B]   A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/46F7 D0 07       BNE $07    [$4700]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/46F9 A9 00       LDA #$00                A:0000 X:0000 Y:6B91 P:envMxdiZc - Loads idle animation
$C0/46FB 99 79 00    STA $0079,y[$7E:6C0A]   A:0000 X:0000 Y:6B91 P:envMxdiZc - Stores to character animation
$C0/46FE 80 04       BRA $04    [$4704]      A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/4704 C2 20       REP #$20                A:0000 X:0000 Y:6B91 P:envMxdiZc
$C0/4706 64 0A       STZ $0A    [$00:000A]   A:0000 X:0000 Y:6B91 P:envmxdiZc
$C0/4708 64 0C       STZ $0C    [$00:000C]   A:0000 X:0000 Y:6B91 P:envmxdiZc
$C0/470A B9 00 00    LDA $0000,y[$7E:6B91]   A:0000 X:0000 Y:6B91 P:envmxdiZc - Character position in battle (Where do they stand)
$C0/470D 29 FF 00    AND #$00FF              A:0201 X:0000 Y:6B91 P:envmxdizc
$C0/4710 0A          ASL A                   A:0001 X:0000 Y:6B91 P:envmxdizc
$C0/4711 AA          TAX                     A:0002 X:0000 Y:6B91 P:envmxdizc
$C0/4712 BD 4F 06    LDA $064F,x[$7E:0651]   A:0002 X:0002 Y:6B91 P:envmxdizc - Load X coordinates in battle
$C0/4715 85 04       STA $04    [$00:0004]   A:0070 X:0002 Y:6B91 P:envmxdizc
$C0/4717 AD 05 06    LDA $0605  [$7E:0605]   A:0070 X:0002 Y:6B91 P:envmxdizc
$C0/471A 38          SEC                     A:0090 X:0002 Y:6B91 P:envmxdizc
$C0/471B ED 4F 06    SBC $064F  [$7E:064F]   A:0090 X:0002 Y:6B91 P:envmxdizC
$C0/471E 18          CLC                     A:0000 X:0002 Y:6B91 P:envmxdiZC
$C0/471F 65 04       ADC $04    [$00:0004]   A:0000 X:0002 Y:6B91 P:envmxdiZc
$C0/4721 10 01       BPL $01    [$4724]      A:0070 X:0002 Y:6B91 P:envmxdizc
$C0/4724 85 04       STA $04    [$00:0004]   A:0070 X:0002 Y:6B91 P:envmxdizc
$C0/4726 D9 04 00    CMP $0004,y[$7E:6B95]   A:0070 X:0002 Y:6B91 P:envmxdizc - PC 2 X coordinates
$C0/4729 F0 20       BEQ $20    [$474B]      A:0070 X:0002 Y:6B91 P:envmxdiZC
$C0/474B C2 20       REP #$20                A:0070 X:0002 Y:6B91 P:envmxdiZC
$C0/474D 22 DE AF C1 JSL $C1AFDE[$C1:AFDE]   A:0070 X:0002 Y:6B91 P:envmxdiZC

Old data that I'm starting to take a look at.  This is an example of loading the character's battle data, coordinates, etc..

This is a chunk of data between Klarth and Mint.  Hilariously, they share the EXACT same code in this chunk.  All the other PC's share something extremely similar as well.  Same data just completely different location in banks.  I even took the liberty awhile ago to re-write that bit for a few PC's and bumped all this similar code to a new area then had each of their routines JSL to it.  They still worked flawlessly.

Not really 'bad coding', but more or less it's just a huge waste of room.
'We have to find some way to incorporate the general civilians in the plot.'

'We'll kill off children in the Juuban district with an infection where they cough up blood and are found hanging themselves from cherry blossom trees.'

Bisqwit

  • Sr. Member
  • ****
  • Posts: 368
  • Polite, but politically incorrect.
    • View Profile
    • http://iki.fi/bisqwit/
Re: bad coding in roms
« Reply #78 on: April 04, 2013, 11:24:03 pm »
Maybe they used some kind of code generator / set of macros...
Or had an intern doing copypaste coding :-)

Xenesis

  • Jr. Member
  • **
  • Posts: 90
  • Syogun Changer
    • View Profile
    • Wars World News
Re: bad coding in roms
« Reply #79 on: April 07, 2013, 09:30:20 pm »
I see this a lot in Intelligent System's coding. It irks me because it wastes a *lot* of space (One 32-bit pointer per possible input) and if it somehow ever got a value out of range it'd jump to a garbage address.

Code: [Select]
08085430 0080     lsl     r0,r0,#0x2 ;Input here is lsl'd by four
08085432 4903     ldr     r1,=#0x8085444 ;A list of pointers here
08085434 1840     add     r0,r0,r1
08085436 6800     ldr     r0,[r0]
08085438 4687     mov     r15,r0 ;Then just updates the program counter. ;_;

This particular example is from Advance Wars 2. Although it seems to be in a lot of IS' GUI code. :|