This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Contra: notes from reverse engineering

Contra: notes from reverse engineering
by on (#137086)
I just discovered that one of the creators of Little Inferno did an extensive reverse-engineering and wrote up some notes about how Contra's authors had chosen to do things: "Retro Game Internals: Contra"
Re: Contra: notes from reverse engineering
by on (#137092)
Interesting ! Most of it is common sense, but there was some interesting stuff about random enemy spawns (specific about Contra), and the most interesting : Screen space and point-to-rectangle collision tricks.
Re: Contra: notes from reverse engineering
by on (#137096)
Bregalad wrote:
point-to-rectangle collision tricks.

Yeah this one was a nice find. Somehow I never had thought about being able to do it like this.
Re: Contra: notes from reverse engineering
by on (#137107)
The point-rectangle collision doesn't really look like a good idea, because they had to program in a different box for every player enemy box combination.

I liked the idea of using screen coordinates though. They probably didn't do that too many 16-bit games. The only problem with that is you can't have big bosses that scroll on and off the screen.
Re: Contra: notes from reverse engineering
by on (#137111)
I particularly enjoyed the collision detection part, as well as the bit about the RNG used.

That said: there's one thing in Contra that's always been a mystery to me -- the single "flickery" pixel on the title screen in Lance's hair:

https://www.youtube.com/watch?v=Vb5KsW_6nZc

I've always assumed it has something to do with the use of sprites and/or OBJ cycling for Bill and Lance's hair and eye colour + Bill's shirt and cigarette (probably done to add more colour/quality to the title screen), but that's purely speculative on my part. It doesn't look like it's sprite 0 (used Nintendulator to check); would love to know the root cause for that one.
Re: Contra: notes from reverse engineering
by on (#137113)
Even though my game does not scroll (while the gameplay is going on), I had to use 16-bit coordinates for everything for the following 2 reasons :

- Handling velocities with a finer resolution than pixels/frame (and thus, the position had to hold a sub-pixel part)
- When a sprite is close to the the edge of the screen, having the X position in 8-bit caused too many overlapping bugs in the left/right direction. It is for instance not possible to have a sprite partly on the screen in neither direction.

So for a scrolling game there's even less reason to use 8-bit coordinates. They even mention sub-pixel position somewhere in this document. This is a contradiction with the "screen-coordinates" system I think.

Quote:
as well as the bit about the RNG used.

As far I can tell, *all* FC/NES Konami games work like that, except maybe the very early ones. They also *all* have a specific sprite cycling pattern (which is what you're seeing on the title screen), and they all have that pause sound. This is why Konami games are so distinctive to games from all other companies, in my opinion.
Re: Contra: notes from reverse engineering
by on (#137120)
I haven't read it, but I just assumed that "screen coordinates" meant coordinates relative to the top left corner of the screen, as opposed to coordinates relative to the level itself. That doesn't rule out fixed point or anything like that.
Re: Contra: notes from reverse engineering
by on (#137132)
Don't you still need to emulate another bit so objects on the edge of the screen don't appear on both sides of the screen like the glitches in Ghosts n Goblins and Super Pitfall?
Re: Contra: notes from reverse engineering
by on (#137135)
We can assume that if the center is offscreen, an enemy just pops out of view.
Re: Contra: notes from reverse engineering
by on (#137148)
thefox wrote:
Bregalad wrote:
point-to-rectangle collision tricks.

Yeah this one was a nice find. Somehow I never had thought about being able to do it like this.
The same trick also applies to background collision detection. You can "extrude" the edges of the map and only test a single point at the feet of the player.

Admittedly this requires the collision attribute map to be separated from the display tiles, plus the player and other objects must be of a uniform size (though you can cheat with additional attributes for crouch spaces and the like.)
Re: Contra: notes from reverse engineering
by on (#137149)
Bregalad wrote:
Screen space

Man, I could never do something like this. Completely giving up a well structured model of the level for a limited error-prone representation that has to be scrolled around with the camera just so that collision tests are 8-bit? There must be something else that can be updated before it has to come to this.

I guess that if you really wanted to do 8-bit collision tests, you could do it after having converted the coordinates to screen space for drawing sprites, which you have to do every frame anyway.
Re: Contra: notes from reverse engineering
by on (#137322)
I have to agree it's a bit dumb. It's explicitely mentionned in the doccument that object's positions are stoed in 16-bit, the only difference is that it's fixed point 8.8 and not the 12.4 that I use (I made this choice for no particular reason however).

This implies that there will be problems with object really close to either side of the screen and many checks for overflow when drawing the sprites, but also that no shifts are required to get the standard screen X-pos and Y-pos. They use the screen points for collision detection instead of the logical position, which is a bit weird, especially for BG collision detection.

As for point-to-rectangle collision, well I don't know how good an idea it is I'll have to think a bit more about it. If both the player and enemies are supposed to take different shapes at different times it's definitely a bad idea but if either one is constant, replacing it by a point sounds like a good idea.