It is currently Sat Oct 21, 2017 2:24 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Sun Nov 30, 2014 12:36 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6292
Location: Seattle
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"


Top
 Profile  
 
PostPosted: Sun Nov 30, 2014 3:25 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7233
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Sun Nov 30, 2014 4:39 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Nov 30, 2014 12:12 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
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.


Top
 Profile  
 
PostPosted: Sun Nov 30, 2014 2:27 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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.


Top
 Profile  
 
PostPosted: Sun Nov 30, 2014 3:00 pm 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7233
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Sun Nov 30, 2014 4:12 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
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.


Top
 Profile  
 
PostPosted: Sun Nov 30, 2014 8:15 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
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?


Top
 Profile  
 
PostPosted: Sun Nov 30, 2014 8:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
We can assume that if the center is offscreen, an enemy just pops out of view.


Top
 Profile  
 
PostPosted: Mon Dec 01, 2014 5:19 am 
Offline

Joined: Mon Nov 22, 2004 3:24 pm
Posts: 162
Location: Sweden
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.)


Top
 Profile  
 
PostPosted: Mon Dec 01, 2014 5:42 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10066
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sat Dec 06, 2014 3:29 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7233
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], Google Adsense [Bot] and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group