Space invaders sprite problem

[Fredde]

I used hack-o-matic to edit a sprite (the ship) in Space Invaders. But when I tried the edited version, all sort of weirdo things happens. The alien I hit isn't the one that is destroyed and aliens disapears and reapears. What's the problem?

[Nukey Shay]

Did your hacked version of the ship stay within the confines of the original shape? If the original sprite is 10 lines tall...you need to make sure that any alterations occur on ONLY those lines. Anything else, and some other aspect of the game could be changed (if it happens to be a program instruction, the game will most likely crash).

[Fredde]

Yes, I did stay withing the 10 pixel-height. I did notice that the sprites are upside-down when viewed in hack-o-matic.

[uosipa llamxew]

Think you could post the ROM? It'd be interesting to see what happened there. Might make for some cool ideas for a new variant of Space Invaders! :-)

[Nukey Shay]

Yes, I did stay withing the 10 pixel-height. I did notice that the sprites are upside-down when viewed in hack-o-matic.

That is strange then, since others have altered this particular game many times with no problems. Perhaps it was corrupted by HOM for some reason And the 10-pixel height is not a "standard", games could use ANY height (Adventure for example includes a sprite that is around 100 lines tall). What is important is that you don't change the lines above or below the original object's lines (that would be altering another object, data, or program instructions). If the original object is 5 lines, use 5 (or less) lines. If 7, use 7 (or less). Never use more unless the program itself is modified and you can be sure that is going to be read correctly.

 

BTW it's normal for some games to have the sprites oriented upside-down...the program code that fetches the data is designed to work that way. Some games use both methods. HOM is displaying the rom code from start to finish...and does not look to see which method is being used for that particular object (which would probably be impossible for any editor to do without a complete program disassembly).

 

It could be that SI has program instructions or other data arranged in such a way that it APPEARS to be a ship. What lines did you change?

[Fredde]

Line 0c0a to 0c13. If HOM corrupted it, is there perhaps another way to mess around with the graphics(other program for example)?

[Nukey Shay]

If you can call up a DOS prompt, you can use the 2600GFX programs

http://www.atarihq.com/danb/a2600.shtml#devsoftware

 

BTW those lines are the player's base...and you should have been able to change them to anything

0c0a |XXXXXXX |

0c0b |XXXXXXX |

0c0c | XXXXX  |

0c0d |XXXXXXX |

0c0e |  XXX   |

0c0f |  XXX   |

0c10 | XXXXX  |

0c11 |  XXX   |

0c12 |  XXX   |

0c13 |   X    |

Just beyond those lines is a data table. Are you sure that only 0c0a-0c13 were changed?

[StanJr]

Side note: HOM lets you flip the code so that things are right side up.

[uosipa llamxew]

Side note: HOM lets you flip the code so that things are right side up.

 

I must have an old version, I don't see that option.

 

If the original sprite is 10 lines tall...you need to make sure that any alterations occur on ONLY those lines.

 

This is true for many sprites, but sometimes you can edit outside the size of the original and get by. Before you do though, I suggest you back up where you left off and write a new ROM to experiment with the sprite boundaries. Sometimes there is quite a lot of extra room, and sometimes you get one pixel off and you screw the game up. I did with the HangOn hack - one pixel, and the bike was pulled involuntarily to the left of the screen and off the road. Too weird.

[StanJr]

I have whatever was the most recent version of HOM from the HOM thread. Let's me flip, copy and paste, etc. Its a lifesaver.