Sprite collision and frames

[Giles N]

Anyone here who knows if any given range of collision/interaction of sprites are assigned specifically to each frame, or whether it follows box-detection, pixel-detection…?

 

Would changing one frame (with different looks of sprite-grfx) for another, impact collision, or would it just detect and underlying program that says this or that frame has no more, no less than this or that range of collision/intersction…?

[+Bruce-Robert Pocock]

I'm not sure I follow the question 100%, but the 7800 does not have hardware pixel-based “sprites” per se, and MARIA doesn't provide any collision-detection assistance. So … you would have to implement your own, and you could do so in whatever way is convenient to you.

[Giles N]

@Bruce-Robert Pocock

Thanks.

 

So, - in, lets say, Double Dragon, where the programming already is done, will the ‘hitting’ follow the type of graphics/sprite-frames as they look in shape and size, or will they follow a given invisible ‘hit-detection’ program behind.

 

In the picture, lets you swapped frame 1, with frame 2 (dropping frame 1 completely), so you’d have the animation 2->2->3, instead of

1->2->3.

Wouid it make the first frame (now ‘2’) behave as full punch, or wouid it behave as ‘drawn-back fist’ even though it looked like a full punch… (due to collision programming)?

 

 

[+Muddyfunster]

On most systems, the graphics and logic are independant (i.e. they don't have registers like the 2600 to read collisions between sprites like @Bruce-Robert Pocock said).

 

You would have to match your game logic (collisions in this case) to the graphic frame or action. So for frame 2 your code would have to know there is a bit sticking out (the arm - I've overlaid some crude boxes to show).

 

 

If you change the underlying graphics, the code would have to change to account for the change in shape. 

 

So in your example, if I'm following correctly, if you go 2,2,3. then although you are displaying frame 2 instead of frame 1, unless you change the hit detection code to account for the change, it would treat frame 2 as frame 1 for hit and logic purposes. ie, you see 2,2,3, the hit code would still expect 1,2,3. (unless you change it). You might be able to change the graphics (if that's what you are thinking) and it have no impact on the game hit detection, it would depend on how much fidelity is in the hit code, ie, do they just stick a box around the whole thing or do they break the hit area up?

 

In Danger Zone, each aircraft has 16 possible rotations so for each possible rotation, the game has 4 hitboxes. The hit boxes are tied to the frame so if the graphic is showing frame 1, then it looks at hotbox set 1 and so on. 

 

So when the sprite changes (the airplane at the top) the code matches that frame to the hit logic which looks like the collection of red boxes below. Each frame the airplane looks different and the boxes change to match.

 

 

Hope that helps,

 

 

[Giles N]

@Muddyfunster

Is it possible to get into, break through to, such coding-stuff as that which aligns 7800-sprite grfx, with screen-areas of collision-detection…? 

 

Or is it all locked… down…?

—

 

How did anyone, anywhere … at all …  get into changing, improving, making more accessible, - to new 7800-users - improved or alternative versions of games, in the first place? How did they hack? Improve. Vary. Change. Make closer to the original . . . How did hacks happen at all, Etc..? Anyone can buy an original copy to own, but getting a highly-improved or perfected version of the title in question, is often another matter… 

Edited August 20, 2022 by Giles N

[Giles N]

@Muddyfunster

 

As to hardcore, indepth hacking - can one get the code to read, look for, search for frame2 instead of frame1, with all parameters changed?

   How to make the necessary changes…? Possible at all…?

[Giles N]

… so… in one way or another, info out there must exist as to how to get-into the code (albeit only as to sprite/tile/palette-exchange), so to change nice titles to become even better for nerdy 7800-gamers…?

 

 

[Giles N]

@Bruce-Robert Pocock

@Muddyfunster

 

But games - in variations, in inprovement-hacks -. have gotten into changing background-palettes, sprites-in-action, etc  etc  etc

 

How does it happen..?

 
People have had their originals for decades, wanting only some stuff to be imptoved upon.

 

How does one get through to insert better gtfx & sound info, into a ROM that can supplement an original cart…?

 

- - -    
 

Note to the last thing there: I actually have a liking for pure originals too…; they have their charm as the substance/output of their day…

 

 

[+Atarius Maximus]

36 minutes ago, Giles N said:

@Bruce-Robert Pocock

@Muddyfunster

 

But games - in variations, in inprovement-hacks -. have gotten into changing background-palettes, sprites-in-action, etc  etc  etc

 

How does it happen..?

 
People have had their originals for decades, wanting only some stuff to be imptoved upon.

 

How does one get through to insert better gtfx & sound info, into a ROM that can supplement an original cart…?

 

You'd need a basic knowledge of 6502 Assembly to start.  Having never created a 7800 hack, I can't really speak to the process of hacking on this platform however RevEng posted a good basic place to start here.  I've only hacked 2600 games and typically used commented disassembly files created by other AA forum members - made changes - then reassembled them using DASM.   

 

From RevEng (speaking to making color changes):

 

1. load up the game in the a7800/mame debugger

2. trap any writes to the Maria color registers, and run the game

3. look what values are being written to the registers, and figure out which ones you want to change. take note of the displayed disassembly and hex code for the load and store of the color you're interested in modifying. (t's possible the load will be from a table. if that's the case, note the table location and modify the desired table bytes instead, in the next step)

4. Open the rom in a hex editor and search for the hex code in question. If it occurs in several places, you likely want to change each one. It's probably duplicated due to the same color being used in different banks or different levels.

5. sign the changed rom using 7800sign.

6. run the modified rom to test it out

 

[Giles N]

@Atarius Maximus

Thanks … but … woohoooww….!

 

… yeah, simple - oh-well

 

 

(125 years is no time here…)

Edited August 21, 2022 by Giles N

[Traxx]

I use a7800 and can show how to hack or reverse engineer games if you want

 

[Traxx]

I reverse engineered Jinks

[Giles N]

On 8/21/2022 at 2:33 AM, Traxx said:

I use a7800 and can show how to hack or reverse engineer games if you want

 

How complex is this?

 

Do I use a program that hacks, or do I need to master programming?

 

What can hacking do:

- can they open the source-code for games whose source-code haven’t been published, say to study the code or alter it…?

- can hacking (only) access the graphics-sections as to insert other graphics instead of the old versions

(KevinMos3 did hacks of Scrapysrd Dog - a version with new graphics for the hero, and a version where the hero is replaced by the dog ‘Scraps’ to save the guy. In this I did the graphics for the dog-character, posted the frames to Kevin who did the hacking process [including a code file that gives inifinte lives if inserted]. 

—-

I cannot code.

Coding for me would be to start from scratch. So, if it takes learning to code to get to learn to hack, this will be a fairly long process for me.

[Giles N]

On 8/21/2022 at 2:00 AM, Atarius Maximus said:RevEng posted a good basic place to start here.  I've only hacked 2600 games and typically used commented disassembly files created by other AA forum members - made changes - then reassembled them using DASM.   

 

1. load up the game in the a7800/mame debugger

Thanks for introducing the subject!

 

Qs:

what are:

- disassembly files (things I’d need to create or find on the net and run in a7800?)  
- DASM?

On 8/21/2022 at 2:00 AM, Atarius Maximus said:RevEng posted a good basic place to start here.  I've only hacked 2600 games and typically used commented disassembly files created by other AA forum members - made changes - then reassembled them using DASM.   

2. trap any writes to the Maria color registers, and run the game

 

On 8/21/2022 at 2:00 AM, Atarius Maximus said:RevEng posted a good basic place to start here.  I've only hacked 2600 games and typically used commented disassembly files created by other AA forum members - made changes - then reassembled them using DASM.   

3. look what values are being written to the registers, and figure out which ones you want to change. take note of the displayed disassembly and hex code for the load and store of the color you're interested in modifying. (t's possible the load will be from a table. if that's the case, note the table location and modify the desired table bytes instead, in the next step)

Qs: what is the hex code, what does it do?

What if I want to change frames, number of frames used in animation, or which frames are used in animation? Is this a category of ‘registers’?

What’s the difference between ‘registers’, ‘tables’ 

On 8/21/2022 at 2:00 AM, Atarius Maximus said:RevEng posted a good basic place to start here.  I've only hacked 2600 games and typically used commented disassembly files created by other AA forum members - made changes - then reassembled them using DASM.   

4. Open the rom in a hex editor and search for the hex code in question. If it occurs in several places, you likely want to change each one. It's probably duplicated due to the same color being used in different banks or different levels.

Qs: Does the hex code only alter colors, or other things as well?

 

What if I’d want to swap music? Change music files, turn on/off music?

 

What if I’d want to have sprite-frames use the collision-detection used for other frames (as in my Double Dragon-example above - changing how the punching works, frame by frame, collision-detection and all?)

On 8/21/2022 at 2:00 AM, Atarius Maximus said:RevEng posted a good basic place to start here.  I've only hacked 2600 games and typically used commented disassembly files created by other AA forum members - made changes - then reassembled them using DASM.   

5. sign the changed rom using 7800sign.

6. run the modified rom to test it out

 

[+Bruce-Robert Pocock]

9 hours ago, Giles N said:

what are:

- disassembly files (things I’d need to create or find on the net and run in a7800?)  

- DASM?

The disassembly is where someone takes the binary (ROM image) and reverses it back to assembly-language code, usually commenting and adding labels to make it human-legible.

 

DASM is one assembler program that's popular with many AtariAge users.

 

For instance, if I wrote:

UpdateDisplayedArrows:
          lda Arrows
          cmp ArrowsDisplayed
          beq DoneArrows
          bge IncreaseArrowsDisplayed

DecreaseArrowsDisplayed:
          dec ArrowsDisplayed
          jmp ChangedArrows

IncreaseArrowsDisplayed:
          inc ArrowsDisplayed
          ;; fall through
ChangedArrows:

I'm going to compile it with my assembler and produce a binary. My listing file will look something like:

.94dc   d4dc                    UpdateDisplayedArrows:
.94dc   d4dc    ad 36 21                  lda Arrows
.94df   d4df    cd 37 21                  cmp ArrowsDisplayed
.94e2   d4e2    f0 19                     beq DoneArrows
.94e4   d4e4    b0 06                     bge IncreaseArrowsDisplayed

.94e6   d4e6                    DecreaseArrowsDisplayed:
.94e6   d4e6    ce 37 21                  dec ArrowsDisplayed
.94e9   d4e9    4c ef d4                  jmp ChangedArrows

.94ec   d4ec                    IncreaseArrowsDisplayed:
.94ec   d4ec    ee 37 21                  inc ArrowsDisplayed
                                          ;; fall through
.94ef   d4ef                    ChangedArrows:

When I put that together into a ROM file, though, it'll just be the binary data:

ad 36 21 cd  37 21 f0 19  b0 06 ce 37  21 4c ef d4
ee 37 21

A disassembler program, like the one is A7800, can reverse that to figure out the opcodes, but not what they “mean” precisely:

Now, someone could make a disassembly by taking the raw output from a disassembler, like that, and adding their own labels, once they determine what the various addresses are used for. So a disassembly listing for the same code might read

          lda ARROWCNT
          cmp ARROWCPY
          beq Ld4ef

          bcs Ld4ec

          dec ARROWCPY
          jmp Ld4ef

Ld4ec     inc ARROWCPY

Ld4ef

The person doing the disassembly might come up with different names for things (like ARROWCPY for what I had called DisplayedArrows) or not at all (the Ld4ec is just a junk label created by the disassembler based on the address, and doesn't actually provide any information about what's happening at that address), and it can take quite a bit of work to discover what the various addresses are used for — RAM addresses used as variables, ROM code labels, ROM data tables, and so forth. But it's far easier to refer to a disassembly that someone's taken the time to annotate than the raw disassembly provided by the debugger.

 

Naturally, the original source code is the preferred form, but if you don't have that available, a good disassembly is nearly as good.

 

What others were suggesting was: it would be easier to make small alterations if you already have the disassembly written for you. For example, if you wanted to change how many arrows you started the game with, you could look at a disassembly and see somewhere something like

ARROWCNT = $2136 ; How many arrows you actually have

You could then go into the debugger in A7800 and do something like

wpset 2136,1,w

… which will set a watch point looking at $2136, for 1 byte only, for writes.

When you start a new game, perhaps you get something like this

You see the last line in the debugger window says that the code at (PC=) $82b3 wrote the value (data=) $64 (decimal 100) to $2136 (Arrows/ARROWCNT). If you know that you start the game with 100 arrows, then you've found the place you want to alter.

Looking back a little …

… we see that the A register was loaded with $64 on the line above, so you can just alter the #$64 in that line and probably starting a new game would give you a different number of arrows.

 

In a similar way, as @Atarius Maximus was saying, if you look at the MARIA palette registers in the debugger:

… you might be wanting to change something that is currently color $88 (light blue) to another color, say $0f (white) perhaps. From this debugger window, I can see that is in palette register P2C2, which is written at $2A. So you could maybe trap writes to $2a, looking for a write of $88. Hitting F5 after false positives, I run into:

In this case, again, the color happens to be a simple hard-coded value from lda #$88, so you can probably edit the ROM to change that value as well. If it were being calculated, or pulled from a data table, it would be more complicated to change it.

 

At that point, you'd need to (going back to the arrows example)

• alter the original source code corresponding to lda #$64 and recompile it, or
• alter a disassembly listing in the same way, and recompile it, or
• open a hex editor, find correct offset in the ROM for the a9 64 you're after (within the sequence 8d 32 21 a9 64 8c 36 21) and save it

In the hex editor case, since the ROM can consist of multiple memory banks and they wont start at 0000, you'll find that the offset probably will end in b6 like 82b6 but it will probably not be $82b6, it could e.g. be $0236 offset or something. (It'll also be easier to do this if you strip off any .a78 header with 7800header -b romfile.a78 and use the .bin it produces for hex editing, but then you'll also have to add the header back on later.

 

Finally, after editing a ROM, if you want to be able to play it on real hardware, you have to re-sign it with your changes using the 7800sign utility to get it to run.

 

 

[Ecernosoft]

On 8/20/2022 at 6:26 PM, Giles N said:

@Muddyfunster

Is it possible to get into, break through to, such coding-stuff as that which aligns 7800-sprite grfx, with screen-areas of collision-detection…? 

 

Or is it all locked… down…?

—

 

How did anyone, anywhere … at all …  get into changing, improving, making more accessible, - to new 7800-users - improved or alternative versions of games, in the first place? How did they hack? Improve. Vary. Change. Make closer to the original . . . How did hacks happen at all, Etc..? Anyone can buy an original copy to own, but getting a highly-improved or perfected version of the title in question, is often another matter… 

Just write your own collision code. Simple.

Basically, the 7800 can't do collision on it's own, and you must do it yourself.

[Giles N]

@Bruce-Robert Pocock, @Muddyfunster, @Atarius Maximusand @Traxx

 

Thanks guys for answering in-depth and to the point.

 

It seems that doing hacking would require that I really would have to get aquainted with basic 7800-assembly coding-skills, and such a process will take a long, long time for me, if I have the skills needed, the interest to pursue it, the time (and actually also health as I need to set of time for self-maintainance every day) to learn it.

 

I anyway felt I learned some things about how the 7800 ‘thinks’ or works, and it was interesting to learn.

 

Thanks again for good answers (even though some of it went way over my head).

 

—

Cheers!

[Ecernosoft]

On 8/30/2022 at 5:53 PM, Giles N said:

@Bruce-Robert Pocock, @Muddyfunster, @Atarius Maximusand @Traxx

 

Thanks guys for answering in-depth and to the point.

 

It seems that doing hacking would require that I really would have to get aquainted with basic 7800-assembly coding-skills, and such a process will take a long, long time for me, if I have the skills needed, the interest to pursue it, the time (and actually also health as I need to set of time for self-maintainance every day) to learn it.

 

I anyway felt I learned some things about how the 7800 ‘thinks’ or works, and it was interesting to learn.

 

Thanks again for good answers (even though some of it went way over my head).

 

—

Cheers!

What about me?

Anyway, Yes. You do sadly need to make your own collision code but I bet they helped!

[Mord]

6 hours ago, Ecernosoft said:

What about me?

Anyway, Yes. You do sadly need to make your own collision code but I bet they helped!

I think everyone else's answers were more detailed and verbose.

 

But unfortunately when it comes to hacking an existing rom, making your own collision code to replace what's in the code isn't anywhere near as simple as writing it for a new game.  Consider you first have to find the space in the rom to put that code. Then you have to find the original collision code using the same methods they detailed up above, then you have to make sure all calls to it are changed to the new code.  If you just delete the original collision code and put yours in that same spot (still requires finding said spot (or spots)) in all necessary banks it means you have to make sure your own code is no larger than what was taken out. If the original code was extremely packed and efficient that could be an insane undertaking.

 

 

[Ecernosoft]

7 hours ago, Mord said:

I think everyone else's answers were more detailed and verbose.

 

But unfortunately when it comes to hacking an existing rom, making your own collision code to replace what's in the code isn't anywhere near as simple as writing it for a new game.  Consider you first have to find the space in the rom to put that code. Then you have to find the original collision code using the same methods they detailed up above, then you have to make sure all calls to it are changed to the new code.  If you just delete the original collision code and put yours in that same spot (still requires finding said spot (or spots)) in all necessary banks it means you have to make sure your own code is no larger than what was taken out. If the original code was extremely packed and efficient that could be an insane undertaking.

 

 

You're right.

 

Yes, that's also true it's more complex than that. My collision code is nowhere near perfect, ICT demonstrates that perfectly.

Also, I didn't know this was about hacking games, I thought it was about making new ones.

[+Muddyfunster]

14 minutes ago, Ecernosoft said:

Also, I didn't know this was about hacking games, I thought it was about making new ones.

Maybe read the thread before jumping in with comments? Just a suggestion  

[Ecernosoft]

2 minutes ago, Muddyfunster said:

Maybe read the thread before jumping in with comments? Just a suggestion  

Haha, I did. I'm not the best programmer out there... 

Anyway, I must have interpreted it wrong. lol.

[Giles N]

On 9/3/2022 at 1:55 AM, Ecernosoft said:

What about me?

Anyway, Yes. You do sadly need to make your own collision code but I bet they helped!

Not my point to leave out anyone deliberately… 

… just wanted to throw in a thanks to those went in-depth to bring up as how the 7800 is made to behave and how to do it…

 

Yes, learning to code or read code as well to be able to manipulate it, seems necessary… and as I also was more comfy with graphics, level-design, characters and action-ideas when homebrewing on the Amiga500, sure picking up a little 7800 Basic and a smatter of assembly, would be cool.

 

I just don’t have the focus to dive deeply into this right now.

 

- - -

  

Why then did I ask, would perhaps some wonder?

 

Because - if crash/collision detection followed a given say-sprite-category, then hacks could be made which may improve many games just by swithing sprite-number (or more advanced, simply some games as to make the playable just turning on/off a program-thing, given this or that: simple changes that could be a gamechanger (no pun here).

 

So, I’drop by periods, pick up on things over time…

 

 

[Ecernosoft]

40 minutes ago, Giles N said:

Not my point to leave out anyone deliberately… 

… just wanted to throw in a thanks to those went in-depth to bring up as how the 7800 is made to behave and how to do it…

 

Yes, learning to code or read code as well to be able to manipulate it, seems necessary… and as I also was more comfy with graphics, level-design, characters and action-ideas when homebrewing on the Amiga500, sure picking up a little 7800 Basic and a smatter of assembly, would be cool.

 

I just don’t have the focus to dive deeply into this right now.

 

- - -

  

Why then did I ask, would perhaps some wonder?

 

Because - if crash/collision detection followed a given say-sprite-category, then hacks could be made which may improve many games just by swithing sprite-number (or more advanced, simply some games as to make the playable just turning on/off a program-thing, given this or that: simple changes that could be a gamechanger (no pun here).

 

So, I’drop by periods, pick up on things over time…

 

 

Yeah, I bet not.

 

I understand.

[Giles N]

On 9/3/2022 at 3:48 PM, Ecernosoft said:

Also, I didn't know this was about hacking games, I thought it was about making new ones.

My initial thoughts on this is: why should they be mutually exclusive?

 

If hacking means non-source-codes can be studied systematically (by those who have the background to understand it), - many ways of coding stuff still’s not done and/or common in homebrews can finally be learnt: like multi-directional scrolling etc etc.

 

One can study the source-code the best games on something that title did very well, and then new things can either be learnt or difficult things can become ‘common’.

 

Perhaps a DragonFly II ot a Ultra-Concerto can come with inbuilt sprite-registers and ways to swap or manipulate them…?