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

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

Zoinkity

  • Hero Member
  • *****
  • Posts: 557
    • View Profile
Re: bad coding in roms
« Reply #40 on: November 27, 2012, 09:23:15 am »
R0 is always zero.  0x0 isn't valid address space.  Any write to 0x0 fizzles, and any read of 0x0 throws an exception due to it being unreadable.  Every one of those writes sets an error code to a nonexistant address that can never be recovered.  Unless they custom editted the badvaddress handler reading would cause a fault.

Thing is, each of these routines is passed a variable that is expected to contain the returned error code.  There's some long-winded error handling routines that read these values, which are fairly pointless since they aren't passed.  At the least if you're going to fry all the error codes you might as well unlink their handlers.
It isn't like the values aren't that important; one attached to the PI returns if the thing is busy, if the request was sent, and if it finished.  As far as they're concerned it is always finished, which isn't just unsafe but explains why their decompressor is wrapped in a loop checking input and output checksums.  Simply handling the value avoids this mess.

Pyriel

  • Jr. Member
  • **
  • Posts: 23
    • View Profile
Re: bad coding in roms
« Reply #41 on: November 27, 2012, 10:26:51 am »
Yeah, I know what R0 is.  That's why I asked for clarification, because I wasn't sure how far the rabbit hole went.  I assumed they'd have to write that code directly in assembler to do what it sort of sounded like you were saying.  I'd like to think even the N64 SDKs would see something that essentially means if (1 == 0) and just throw it away.

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: bad coding in roms
« Reply #42 on: November 27, 2012, 10:10:41 pm »
Ah, now that sounds more like bad code someone might write. “Forget the error code pointers it runs fine guys.”

I don’t put any silly missed optimization opportunities past 90s compilers, but it’s possible they were essentially telling a C compiler to write values to NULL.
we are in a horrible and deadly danger

Mattrizzle

  • Jr. Member
  • **
  • Posts: 43
    • View Profile
Re: bad coding in roms
« Reply #43 on: December 04, 2012, 10:52:46 am »
Not the worst case, but a subroutine which starts at $BF/BF86 in Donkey Kong Country (v1.0)(U), called when swapping Kongs, has unneeded branches and some redundant lines:
Code: [Select]
...
$BF/C006: AD 6F 05     LDA $056F      (Load active Kong variable)
$BF/C009: C9 01 00     CMP #$0001
$BF/C00C: F0 06        BEQ $C014      (branch if Donkey Kong)
$BF/C00E: C9 02 00     CMP #$0002
$BF/C011: F0 14        BEQ $C027      (branch if Diddy Kong)
$BF/C013: 60           RTS            (this cannot be reached, as $056F is always either #$0001 or #$0002)
$BF/C014: A9 02 00     LDA #$0002
$BF/C017: 8D 6F 05     STA $056F      (set active Kong to Diddy)
$BF/C01A: A9 11 00     LDA #$0011
$BF/C01D: 8D 2B 10     STA $102B      (set D.K.'s behavior to #$0011)
$BF/C020: 8D 2D 10     STA $102D      (set Diddy's behavior to #$0011)
$BF/C023: 20 3A C0     JSR $C03A
$BF/C026: 60           RTS
$BF/C027: A9 01 00     LDA #$0001
$BF/C02A: 8D 6F 05     STA $056F      (set active Kong to D.K.)
$BF/C02D: A9 11 00     LDA #$0011
$BF/C030: 8D 2B 10     STA $102B      (set D.K.'s behavior to #$0011)
$BF/C033: 8D 2D 10     STA $102D      (set Diddy's behavior to #$0011)
$BF/C036: 20 3A C0     JSR $C03A
$BF/C039: 60           RTS

If the code snippet above was replaced with this...
Code: [Select]
...
AD 6F 05     LDA $056F      (Load active Kong variable, which is either 1 or 2)
3A           DEC            (decrease value in accumulator by 1, making it either 0 or 1)
49 01 00     EOR #$0001     ("toggle" bit 0, changing 0 to 1, or vice-versa)
1A           INC            (decrease value in accumulator by 1, making it either 2 or 1)
8D 6F 05     STA $056F      (store value to active Kong variable)
A9 11 00     LDA #$0011
8D 2B 10     STA $102B      (set D.K.'s behavior to #$0011)
8D 2D 10     STA $102D      (set Diddy's behavior to #$0011)
...
(the entire subroutine at $BF/C03A can go here, as this subroutine is the only one that calls it)
...
60           RTS
...13 (D.K.) to 17 (Diddy) CPU cycles and 32 bytes would be saved.

FAST6191

  • Hero Member
  • *****
  • Posts: 2367
    • View Profile
Re: bad coding in roms
« Reply #44 on: December 04, 2012, 02:53:36 pm »
Nice snippet Mattrizzle- I am drawn to wonder if that is possibly a crude bit of error handling or an indicator of there potentially being more characters at some point in development (or if riding characters were to count at some point), of course I am quite happy to believe bad coding as well (if if rather than if else).

As for the topic I have nothing especially worth sharing- a handful of packing formats that waste countless amounts of space throughout the header and then has everything byte aligned after that (most other formats will go to 32 bit or higher alignments) which would necessitate a whole bunch data handling after for it to be useful for the memory itself is about as good as it gets right now for me. That said if I dragged up some examples from when I have been playing sound hacker that gets a bit ugly- ultra low sample rates for voices sections despite hardware support for far higher sample rates and the game ultimately ended up only just above the power of 2 boundary for cart size anyway.

Jorpho

  • Hero Member
  • *****
  • Posts: 3858
  • The cat screams with the voice of a man.
    • View Profile
Re: bad coding in roms
« Reply #45 on: December 04, 2012, 10:04:17 pm »
Nice snippet Mattrizzle- I am drawn to wonder if that is possibly a crude bit of error handling or an indicator of there potentially being more characters at some point in development (or if riding characters were to count at some point), of course I am quite happy to believe bad coding as well (if if rather than if else).
The switch is known to be extremely glitchable, with colorful results.
http://davidwonn.kontek.net/snes.html#D
This depresses me. I feel like a goldfish right now...

Myria

  • Jr. Member
  • **
  • Posts: 49
    • View Profile
Re: bad coding in roms
« Reply #46 on: December 11, 2012, 02:20:09 am »
I love it when I see code that does something like:

SEP #$20
CLC
ADC.B #$12

Why not do this instead?

SEP #$21
ADC.B #$11

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: bad coding in roms
« Reply #47 on: December 11, 2012, 03:33:15 am »
I guess that's kind of a "pattern". Furthermore, I've rarely seen SEP/REP being used for flags other than M/X... not sure if the developers didn't bother or just weren't aware, but probably just an oversight usually.

Mauron

  • Sr. Member
  • ****
  • Posts: 424
    • View Profile
Re: bad coding in roms
« Reply #48 on: December 11, 2012, 04:03:16 am »
I've seen games use both this:

SEP #$20
CLC
ADC.B #$12

And in other situations:

REP #$21
ADC.W #$0012

I would guess it was for readability/consistency.
Mauron wuz here.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: bad coding in roms
« Reply #49 on: December 11, 2012, 04:34:13 am »
I'm pretty sure there's a reason to do it (so it's more likely bad understanding from me than bad coding) but I see often, in a PS2 game :

Code: [Select]
sll v1, a0, 16 ; v1 = a0 * $10000
sra a0, v1, 16 ; a0 = v1 / $10000

then v1 is discarded.

What makes me thing it may be stupid optimization is that nop-ing the 2 lines doesn't affect the game...

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: bad coding in roms
« Reply #50 on: December 11, 2012, 04:36:52 am »
Looks like a bit-wise AND with $ffff (the effect, that is, which is discarding the 16 upper bits).

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: bad coding in roms
« Reply #51 on: December 11, 2012, 05:57:42 am »
Yes, but I forgot to add that a0 is always 2 bytes long.

KC

  • Full Member
  • ***
  • Posts: 209
    • View Profile
Re: bad coding in roms
« Reply #52 on: December 11, 2012, 07:21:08 am »
Compilers will automatically insert that when you use a (in this case, signed) 16 bit integer type.  They cannot know that the data is always valid, and have to take measures to ensure that.

RedComet

  • Hero Member
  • *****
  • Posts: 3160
    • View Profile
    • Twilight Translations
Re: bad coding in roms
« Reply #53 on: December 11, 2012, 11:38:08 am »
I love it when I see code that does something like:

SEP #$20
CLC
ADC.B #$12

Why not do this instead?

SEP #$21
ADC.B #$11

Because then you would be setting the carry flag instead of clearing it. ;)
Twilight Translations - More than just Dragonball Z. :P

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: bad coding in roms
« Reply #54 on: December 11, 2012, 11:50:15 am »
That's why he's adding 11 instead of 12 ;)

RedComet

  • Hero Member
  • *****
  • Posts: 3160
    • View Profile
    • Twilight Translations
Re: bad coding in roms
« Reply #55 on: December 11, 2012, 12:04:36 pm »
That's why he's adding 11 instead of 12 ;)

Hah. I completely missed that. :P
Twilight Translations - More than just Dragonball Z. :P

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: bad coding in roms
« Reply #56 on: December 11, 2012, 02:06:14 pm »
Compilers will automatically insert that when you use a (in this case, signed) 16 bit integer type.  They cannot know that the data is always valid, and have to take measures to ensure that.

I suspected something like that. So it's a bad design of the C code ? (in the case I refer to a0 is unsigned)

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: bad coding in roms
« Reply #57 on: December 11, 2012, 06:48:40 pm »
On MIPS, 16-bit-ness has to be enforced if you’re going to have it. Whether it is bad design kind of depends, but it probably isn’t. I can’t think of a way you would just accidentally or mistakenly choose a to use a 16-bit value, unless the programmer was seriously not informed that making it 16-bit will not make the calculation faster like it might on some older platforms (for example).

Either way, it’s only a couple of shifts... it probably doesn’t hurt anything.
we are in a horrible and deadly danger

Pyriel

  • Jr. Member
  • **
  • Posts: 23
    • View Profile
Re: bad coding in roms
« Reply #58 on: December 11, 2012, 06:52:53 pm »
It's two operations created by the compiler to enforce type; they're not slowing anything down.  Without more code, it's not even apparent that $a0 is unsigned, but even if it is, there can be any of number of reasons for casting it as signed.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: bad coding in roms
« Reply #59 on: December 12, 2012, 04:09:09 am »
I don't say bad design because of 16 bits value, but because it considers it signed whereas it isn't (and so the shifts are useless).

Of course, I'm aware it won't really slow down the process. The main drawback is that the compiled code is less readable, especially when you're not accustomed to compiled code :)

But now it makes more sense, thanks :)