NES RoboCop with Arcade sprites

[SomeOldGuy]

...and here he is with a flesh colored face. 



Shadow, you were absolutely right, the image looks a lot better now using the skin color for his mouth.  Thanks for the suggestion. 

sics, that was an excellent explanation, thank you.  I think this may open up some possibilities for the other cutscenes.    Great job on Street Fighter by the way.  Loved the way the title and character select screens came out.  You and Xander max make a good team.

Thanks CryinOnion!  This is definitely a passion project.  I don't mind spending time on it because I'm having fun, I'm sure you can relate.  I'm still amazed that I can edit these old games and play them on my NES.   Can't promise when it will be completed but all sprites and backgrounds will be changed.     

[jimstrom]

That is awesome! So much better than the flappy lips animation.

[ShadowOne333]

...and here he is with a flesh colored face. 



Shadow, you were absolutely right, the image looks a lot better now using the skin color for his mouth.  Thanks for the suggestion. 

sics, that was an excellent explanation, thank you.  I think this may open up some possibilities for the other cutscenes.    Great job on Street Fighter by the way.  Loved the way the title and character select screens came out.  You and Xander max make a good team.

Thanks CryinOnion!  This is definitely a passion project.  I don't mind spending time on it because I'm having fun, I'm sure you can relate.  I'm still amazed that I can edit these old games and play them on my NES.   Can't promise when it will be completed but all sprites and backgrounds will be changed.     

That looks incredible!
Great job with the coloring, it came out great!
Now if you want to go the extra mile, you can even repurpose and rework the lips animation for this new one as well ahaha

[Noside]

Fantastic work as usual! love it!

[Xander max]

In his debugger pictures, do you see the following?

Code Select Expand

07:E30D: A9 10   LDA #$10
07:E30F: 85 34   STA $34
07:E311: A9 38   LDA #$38
07:E313: 85 35   STA $35
07:E315: A9 30   LDA #$30
07:E317: 85 36   STA $36
and

Code Select Expand

07:E9EF: A9 0F   LDA #$0F
07:E9F1: 85 34   STA $34
07:E9F3: A9 1C   LDA #$1C
07:E9F5: 85 35   STA $35
07:E9F7: A9 3C   LDA #$3C
07:E9F9: 85 36   STA $36
The values on the left are the addresses for the code, followed by the literal bytes that make up the code, then the human-readable (dis)assembly, and it's the LDA #$?? values you want to change. You should recognize the second set of values at least (0F 1C 3C).

If nothing else, you could use that data as a guide for what to search for to change:
A9 0F 85 34 A9 1C 85 35 A9 3C 85 36
and change the 0F, 1C and 3C to the colors you want (and likewise for the first set of code that sets the damaged colors, where you'd instead be replacing 10, 38 and 30).

I have some games with the same problem, they have different palettes after suffering damage, I understand the explanation, I just couldn't understand how to find the exact location inside the debugger.
For example, where in the Hex editor I find the information that takes me to the E30D address inside the debugger.
Thanks!

[Morinis]

...and here he is with a flesh colored face. 

Nicely done! 

[Cyneprepou4uk]

how to find the exact location inside the debugger

When breakpoint pauses emulation, right click here


It will open Hex Editor in ROM File view at the wanted location.

Another way is to copy C608, Ctrl + G to it in NES Memory view, right click on the byte, select Go Here In ROM File.
Another way is to set "ROM offsets" checkmark in debugger, manually copy ROM address, then Ctrl + G to it in ROM File.
And one more way is write down several bytes on the left of the instructions, then Ctrl + F them in ROM File.

[Xander max]

When breakpoint pauses emulation, right click here


It will open Hex Editor in ROM File view at the wanted location.

Another way is to copy C608, Ctrl + G to it in NES Memory view, right click on the byte, select Go Here In ROM File.
Another way is to set "ROM offsets" checkmark in debugger, manually copy ROM address, then Ctrl + G to it in ROM File.
And one more way is write down several bytes on the left of the instructions, then Ctrl + F them in ROM File.

Thank you for sharing your knowledge, I will study a little more about the debugger. 

[SomeOldGuy]

Xander max, did you figure out how to find the palette you were looking for?  If not I can share the process I used (I still haven't figured out break points ). 

Latest patch below:
https://www.mediafire.com/file/ilaj6ulklc3jhj8/RoboCop_-_Edit_15.ips/file

All levels have been redrawn but still W.I.P.



Some enemies have been redrawn.



...and my new favorite graphic 

[Noside]

Wait a minute, isn't that Blade from Bad Dudes from the 1st picture? once again, fantastic work and thanks for sharing the latest patch, cheers! 

[Morinis]

Nice progress so far! 

[SomeOldGuy]

Yep, those are the Bad Dudes!  I was wondering if any one would notice. 

Thanks for the kind words guys! 

[SomeOldGuy]

Hey Everybody! 

Been working on changing the game's ending sequence and rant into an issue I could use some help with. 



I'm trying to make the image on the left look like the image on the right.  The problem is that the game is ignoring Byte 2 (attributes) for all of the sprites on this screen.  It looks like the game was coded so that only one palette could be used for this sequence.  Is there a good reason for doing this because it seems completely unnecessary?   

I believe this is the code that's causing my problem:



Changing the byte at 0x01965A will change the palette used but all sprites are forced to use that one palette.

I tried a NOP (EA) at 0x01964F hoping to bypass what ever they did but that didn't work (none of the sprites were drawn to the screen).

[Quick Curly]

Hi. Not sure how useful this post will be. Unfortunately, I'm not too familiar with the RoboCop game. However, it looks like a pretty neat project you have going on here, and I was interested in checking it out.

0x199F4-0x19A13 (0x20) - Palette for scene.

Original:

Code Select Expand

0F 32 26 16 0F 22 12 02 0F 0F 0F 0F 0F 0F 0F 0F
0F 22 12 02 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F

Test (to see how things are affected when attribute byte tests are also performed later):

Code Select Expand

0F 32 26 16 0F 22 12 02 0F 3A 2A 1A 0F 3B 2B 1B
0F 22 12 02 0F 27 17 07 0F 23 16 04 0F 37 2A 05

0x19E16-0x19F0F (0xFA) - Free space(?): "FF" bytes
0x19F10-0x1A00F (0x100) - Free space(?): "00" bytes

$B64D-$B66D = 0x1965D-0x1967D (0x21)

Code Select Expand

B64D:A2 00     LDX #$00      ; Beginning of sprites.
B64F:BD 54 BC  LDA $BC54,X   ; $BC54 = 0x19C64.
B652:9D 00 02  STA $0200,X   ; Byte 0 = Y position.
B655:BD 55 BC  LDA $BC55,X   ; $BC55 = 0x19C65.
B658:9D 01 02  STA $0201,X   ; Byte 1 = Tile ID.
B65B:A9 00     LDA #$00      ; Same attribute for all.
B65D:9D 02 02  STA $0202,X   ; Byte 2 = Attribute.
B660:BD 57 BC  LDA $BC57,X   ; $BC57 = 0x19C67.
B663:9D 03 02  STA $0203,X   ; Byte 3 = X position.

Code Select Expand

B666:E8        INX           ; Increment X 4
B667:E8        INX           ; times to account
B668:E8        INX           ; for next sprite.
B669:E8        INX           ; Check if 15 sprites/
B66A:E0 3C     CPX #$3C      ; 60 bytes reached.
B66C:90 E1     BCC $B64F     ; If not yet, go back.

Disclaimer: Text dump is likely not 100% accurate nor included as part of a balanced breakfast.

Disregarding all of the above nonsense, to answer your question of why they made the code the way they did by using the same attribute byte for those animations of RoboCop... who knows? On one hand, you could argue that they were doing it to save space somehow, but really, what space did they save? By logging the data and code used, you can see that they had groups of 4 bytes for that sprite data starting at 0x19C64, but they weren't logged because the code doesn't load those data bytes. So, the bytes still exist and occupy space, but are essentially wasted instead, and they only saved one byte by not using a "BD" LDA instruction/opcode there. Plus, it appears as though there is still free space at the end of that specific ROM bank that they could have used if they needed to. So, what was the point? There was no point! There's no point to anything in life!

Was it to reduce/save time for the game to perform the code? How much time would it really save overall?

Nonetheless, assuming that the free space at the end of the bank is indeed unused (it wasn't logged by the Code/Data Logger), then you could potentially just insert a jump at the appropriate point in the code, and then jump back after your custom code of how it should have been all along!

As a test, I replaced "A9 00 9D 02 02" with "20 C0 BF EA EA" at 0x1966B-0x1966F (0x5), and "00 00 00 00 00 00 00" with "BD 56 BC 9D 02 02 60" at 0x19FD0-0x19FD6 (0x7).

Code Select Expand

B65B:20 C0 BF  JSR $BFC0
B65E:EA        NOP
B65F:EA        NOP

Code Select Expand

BFC0:BD 56 BC  LDA $BC56,X
BFC3:9D 02 02  STA $0202,X
BFC6:60        RTS

The result was the following:



Since it appears that you're creating a custom scene, you would need to play around with the data bytes to fit your specific needs. In addition, it appears that there's additional code to load additional data for other parts of the scene - maybe? So, there might possibly be additional code that you'll also need to manipulate. However, again, there seems to be free space for you to work with, so hopefully, you'll be able to work it out.

With the above code to load individual attribute bytes, you'll have to modify the "00" of each sprite on your own to what you want/need it to be.

As for the additional time for the code to perform the jump and the return back, not only once but multiple times for all of RoboCop's sprites in that part of the scene, efficiency could be improved if you were able to shift everything forward at that point by one byte so that you could just fit in the "LDA $BC56,X" line where the original code already is; however, unless you have a disassembly to work with to make this a much easier and quicker process, it might not be worth your time and effort to manually shift everything through the hex editor, and have to account for manually adjusting branch lengths like the one at $B66C, as well as any JSR and JMP jump sources and destinations. Unless inefficient code causes you a headache, I would avoid the headache caused by all of the extra work for what really amounts to little reward or appreciation.

Sorry again if this post is inaccurate or incomplete (and as a result, unhelpful), and/or difficult to read through because it was verbose, like my code: "consuming much time".
Perhaps it can still be some sort of starting point towards a solution. We can only hope so, anyway.
In any case, I believe that, ultimately, you can do it in the end! Do it for RoboCop!
Best of luck with your project!

[SomeOldGuy]

Awesome! 

I'm glad you took an interest cause I woulda never figured that out, thank you Quick Curly!  I really appreciate you taking the time to explain what's happening with the code.

In addition, it appears that there's additional code to load additional data for other parts of the scene - maybe? So, there might possibly be additional code that you'll also need to manipulate. However, again, there seems to be free space for you to work with, so hopefully, you'll be able to work it out.

hhmmm...  I wonder if this is the code that makes his arm move up and down?  I'll see if I can figure out what you did and try to bypass this then report back with results. 

As for the additional time for the code to perform the jump and the return back, not only once but multiple times for all of RoboCop's sprites in that part of the scene, efficiency could be improved if you were able to shift everything forward at that point by one byte so that you could just fit in the "LDA $BC56,X" line where the original code already is; however, unless you have a disassembly to work with to make this a much easier and quicker process, it might not be worth your time and effort to manually shift everything through the hex editor, and have to account for manually adjusting branch lengths like the one at $B66C, as well as any JSR and JMP jump sources and destinations. Unless inefficient code causes you a headache, I would avoid the headache caused by all of the extra work for what really amounts to little reward or appreciation.

Nope!  The programming is so far beyond me that if it works I'm happy. 

Sorry again if this post is inaccurate or incomplete (and as a result, unhelpful), and/or difficult to read through because it was verbose, like my code: "consuming much time".
Perhaps it can still be some sort of starting point towards a solution. We can only hope so, anyway.
In any case, I believe that, ultimately, you can do it in the end! Do it for RoboCop!
Best of luck with your project!

Dude! Are you kidding! This post was extremely helpful.  Again, thank you. 

In game with Quick Curly code:

[Noside]

Woah! once again, fantastic work!

[sics]

Your dedication is inspiring, you will go far

[CryinOnion]

If there were a HOTY (Hack Of The Year) award, this project would be, along with Street Fighter II Deluxe, the most solid candidate. The use of colors is so well optimized in that screenshot that it looks like an early Megadrive game, instead of an NES one! Keep it up, bro!

[UltraEpicLeader100]

What on earth would this even be used for? Crash Handler? Anti Piracy Screen? I'm confused here.

[SomeOldGuy]

Thanks Noside, hope you like the newest patch!

Hey sics!  I hope to be on your level one day.    Really love what you've done on Street Fighter 2...but can you please make Ken's hair yellow! Jajajaja  kidding!  Wish the NES wasn't so limited.  Seriously, your work is amazing. 

WOW, Thanks CryinOnion!  I'm really looking forward to how Street Fighter 2 deluxe turns out.  I think Castlevania COA would be a very strong contender.  Really like the sprites emco has been producing.  Metroid: Space Complex looks amazing...and we can't forget both of the Zelda Redux hacks!  That's some pretty tough competition.     

UltraEpicLeader100, you're going to have to play the game to find out.   

New Patch Below:

https://www.mediafire.com/file/fo8cjltlq1d0zii/RoboCop+-+Edit+16.ips/file



All of the enemies and most of the original graphics have finally been redrawn.

For the best viewing/playing experience, you'll want to turn off the 8 sprite limit.

And please keep in mind that the game is still very much a W.I.P.

   

Old Guy