Jump to content
IGNORED

Superman Hack?


Big_Mo

Recommended Posts

I disassembled most of it...never bothered to finish the boring stuff. Because the code is based on an early form of Adventure (which is completely reverse-engineered), the code here is not too difficult to figure out. I also split the display kernel portion from the main program and stuck them in seperate banks for an 8k build. The display kernel is very short, so almost the entire bank can be used for additional rooms and shapes (or to make existing ones taller or more detailed). Because scanline time is not completely drained when displaying objects, you could even add a comparison below the LDA(addr),y lines in order to use a GFX delimiter other than zero.

 

Out_Of_Gas's "Greatest American Hero" is a game based on Superman.

Superman.zip

  • Like 1
Link to comment
Share on other sites

Hi there,

 

I disassembled most of it...never bothered to finish the boring stuff.

I also partially did this game. You can find it at Steve Engelhardt's site http://www.bjars.com/source/Superman.asm. I started this not knowing Kurt had already done his work. Maybe between the two you can fill in any gaps. Just like Kurt, I got bored with this after some time.

Link to comment
Share on other sites

Interesting! I can't seem to find .bin files for Greatest American Hero or Nukey's Superman, but I was able to play them on Vizzed.com.

 

I'm interested in taking a stab at tweaking the graphics for Superman, being an old pixel pusher myself. I think it may be possible to make the backgrounds better and designed in such a way that that would help you know geographically where you are.

Edited by Big_Mo
Link to comment
Share on other sites

If you want to make screens more detailed, there's only a few things that need changing.

 

Alter the value given to $8C (playfieldGraphicsOffset) near the top of the kernel. This is the byte offset counter used when reading data for PF registers. Since there are 3 registers, the value is a multiple of 3 - 1. Using those 3 sets of 3 values, the program draws the playfield in "bands"...a group of 3 bytes for each band. To double the resolution, use #$11 as the value given to $8C.

 

Alter the AND value used at LF545 (.skipObjectDraw). As a screen is "drawn", $8B (currentScanline) keeps track of how many double-line "scanlines" have been done. The current AND value of $0F skips loading new PF register info for 15 out of 16 double scanlines. Altering it to, say, AND #$07, would reload PF gfx after 7 out of 8 double-scanlines have been drawn. (Doubling the PF vertical resolution and shortening the "band" height). The AND value used should be a bitpattern that the 6502 can easily deal with...$0F, $07, or $03 ($01 might not be possible and lead to glitches, dunno about that).

 

The actual playfield data should be the same number of bytes defined by the value given to $8C above. These PFdata bitmaps can exist anywhere in rom memory. The way they are currently layed out is like this:

PF2 value (lower band)

PF1 value (lower band)

PF0 value (lower band)

PF2 value (middle band)

PF1 value (middle band)

PF0 value (middle band)

PF2 value (upper band)

PF1 value (upper band)

PF0 value (upper band)

 

If you altered the value given to $8C and bumped the AND value to #$07 as mentioned above, this table would need to be expanded to 18 bytes...like this:

PF2 value (lower band 2)

PF1 value (lower band 2)

PF0 value (lower band 2)

PF2 value (lower band 1)

PF1 value (lower band 1)

PF0 value (lower band 1)

PF2 value (middle band 2)

PF1 value (middle band 2)

PF0 value (middle band 2)

PF2 value (middle band 1)

PF1 value (middle band 1)

PF0 value (middle band 1)

PF2 value (upper band 2)

PF1 value (upper band 2)

PF0 value (upper band 2)

PF2 value (upper band 1)

PF1 value (upper band 1)

PF0 value (upper band 1)

 

The pixels operate in reverse from what you might expect. A drawn pixel is the sky. Blanks create the buildings.

Link to comment
Share on other sites

Very cool. Thanks. I have no experience assembling 2600 code, but I'm sure I can learn it. Even with my limited knowledge I can see how the graphics data is stored.

 

I will probably start by redesigning the sprites and backgrounds using pixel pushing. Changing how the colors are changed on which scanlines of the characters will make a big difference in how they look (making Supes' cape never enter the top pixel of his sprite, fer instance, so the top line can be black for his hair).

Link to comment
Share on other sites

Currently editing Debro's file to 8k with all the added animations. In addition, I've added delimiters for the objects (so you can use blank gaps in them), CTRLPF for each display band (so backgrounds can be drawn reflected or reversed on any scanline), and scanline counters to make them more detailed. I edited the variable table too so adding additional sprites is easier (such as adding an additional criminal, etc)...there was some ram unused that is now all grouped together.

Link to comment
Share on other sites

A couple of ways...either by flickering both sprites so GRP1 isn't always so overloaded, or by using the leftover ram to store a sorted object list of things to print. Both would need some extensive changes done, which IMO might not be worth the trouble in such a simplistic game...not that I even have any ideas at the moment about how to accomplish them.

 

Updated 8k kernel:

I threw in my edits to Debro's disassembly (since almost all of it is already commented), and added the changes mentioned above. Because there is no longer a limit to how much data a screen reads, the values move forward instead of reverse (so all the screen data is shown in the disassembly the same way that it appears on-screen). Because WSYNC's are mostly-avoided in the kernel to save time, it's absolutely necessary that bitmap and screen data does not cross page boundries. 8 "modes" of display are available for each band of PF data (dictated by the lower nybble of PF0), and you can use as many bands as you want to (even to fill the entire screen by lowering LOWER_PF_BOUNDRY).

Suprmn8K.zip

  • Like 1
Link to comment
Share on other sites

There are at least 3 other hacks of Superman, but I don't know just how "hacked" they are:

"Captain Quick" and "Superman 1" also by James "OutofGas" Francis

"Superman - Race Against Time" by Tim Martin

OOPS! I've been going through my binaries in an effort to eliminate duplication, and consolidate info from the various filenames used for all of the dupes. Wouldn't you know it, I just found out that "Superman - Race Against Time" was misidentified -- it's really a hack of Barnstorming.

Link to comment
Share on other sites

  • 3 weeks later...

5099098612_38f4d1f937.jpg

Here's an experiment I did in tweaking the characters for Superman. I don't know if it's entirely feasible, but I wanted to try to use more color changes by scanline to flesh out the characters in addition to improving their pixel layout.

 

I have an animated GIF of the characters in motion. I gave Lex a jetpack, and just hid Lois's face with her hair. Somtimes it load...sometimes Tripod replaces it with an ad. Sorry if the latter occurs.

 

superani4x.gif

Edited by Big_Mo
  • Like 2
Link to comment
Share on other sites

I don't know if it's entirely feasible, but I wanted to try to use more color changes by scanline to flesh out the characters in addition to improving their pixel layout.
The existing kernel allows color changes for each double-scanline (i.e. each byte of character gfx). So your example is fine. To do byte or color changes for EVERY scanline would require a different display kernel.

 

 

Somtimes it load...sometimes Tripod replaces it with an ad. Sorry if the latter occurs.
Tripod ALWAYS blocks hotlinking. If somebody visits the actual page where the image is unloaded to, that would make it visible here (because their browser would be able to pull the image directly from their cache). You could have just uploaded the image to your post here to avlid that problem, or provide a link to the webpage you made rather than a direct link to the image.
Link to comment
Share on other sites

Let's see if this works...

 

Click to see it animate.

 

One thing I was thinking is that, except for Superman/Clark, none of the other characters ever really stand still, so I think eliminating the "still" pose and replacing those with a second walking frame would make everything look better.

post-867-128760223234_thumb.gif

Edited by Big_Mo
Link to comment
Share on other sites

Lois with hair looks like she has a bag over her head. :)

I agree -- the kooky style hat of the original graphic fits right in with Noel Neill's look in the '50s Superman TV series.

I may go back to that.

 

Actually, one thing that strikes me is that maybe the helicopter should be something other than a copter. Bizzarro, maybe? Hmmm.

Link to comment
Share on other sites

  • 6 years later...

So, reviving this old thread... while looking through the code I was trying to figure out how the screen layout is handled. Is it literally just each screen having pointers for four other screens for exiting in each direction? Because I think one way to make the game less maddening would be via a more sensible and memorizable layout of screens. Sort of a recognizable geography.

 

I still wonder what the programmer was thinking with the subways screen backgrounds. I mean, are those rectangles supposed to be windows on the subway cars?

 

One other thing that I always thought the game should have included, perhaps as a difficulty setting, was that if you reassemble the bridge before putting Lex in the slammer, he blows it up again after X time. That would've added a little strategy to the game. Being able to get rid of the helicopter somehow would be helpful as well.

Edited by Big_Mo
Link to comment
Share on other sites

I think it was very early on and they were doing the best they could with the resources they had. Much easier to look back and ask these questions than to look forward and prevent them.

 

The map is "sort of" logical in that it is linear from left to right. It's once you start going vertically that you get into a jumble. I wonder if it could be more grid-like to better resemble an actual city?

  • Like 1
Link to comment
Share on other sites

I did a ton of work on this game a few years ago for an unreleased hack. I don't remember everything off the top of my head, but I can look back at my notes if you need more specific info (I hope I made notes!!!).

You nailed the screen layout. There's a table of sets of 4 pointers per room: each pointer links to a new screen from each direction. So the world layout is easily hackable once you know how the table works and which hex values go with which room.

 

The subways always annoyed me as well. I think those big square blocks are supposed to be parallel tubes/tracks like the ones that led to Luthor's hideout in the movie. But...yeah....the coloring is weird and it's a stretch.

Edited by CDS Games
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...