cxrom Posted October 26, 2007 Share Posted October 26, 2007 what kind of things are still unsupported (or poorly supported) in the available editors? im lookin' to get away from assembly for awhile and freshen up on some high level programming.so far, i started with a large helmet/graphic/palette editor combo which looks promising. the logo is not positioned correctly on some helmets though. also schedules can be edited with 2 grids of 8x2 combo boxes. matchups, weeks, and games per week all are configurable. i aim to have the editor be fully dynamic, with everything being loaded from the rom. Quote Link to comment Share on other sites More sharing options...
TomTupa Posted October 26, 2007 Share Posted October 26, 2007 I'd like to have an editor to easily change the startup screen too. Just enough to add text, write what the rom is and who made it, and change the year and such. I tried when I made my all time greats rom (which plays much like drummer's 2007 rom btw) and couldn't get anywhere with it. Quote Link to comment Share on other sites More sharing options...
jstout Posted October 27, 2007 Share Posted October 27, 2007 The most unsupported features are the various graphics and playbook design.Personally, I would love an easier way of editing the graphics throughout the game from the field, helmets, to just the graphics in the opening.I built a program that could extract the playbooks and I know Bad_Al and Konforce did some work on the playbook design but there is still so much more that could be done if you could find a way. Right now I'm still doing entire playbook designs by hand. Quote Link to comment Share on other sites More sharing options...
cxrom Posted October 27, 2007 Author Share Posted October 27, 2007 Personally, I would love an easier way of editing the graphics throughout the game from the field, helmets, to just the graphics in the opening.field is definately doable. i was tinkering with that for the whether hack and it seems to be raw data in kind of a linear layout. this could probably be bundled with a title screen editor. helmets (large and small) and are both already on the list.now what do you mean by opening? like change just the graphics, but keep the cut scene, or just create a whole new cut scene?I built a program that could extract the playbooks and I know Bad_Al and Konforce did some work on the playbook design but there is still so much more that could be done if you could find a way. Right now I'm still doing entire playbook designs by hand.do you have any notes i could use as reference. im still not to sure how plays are designed. Quote Link to comment Share on other sites More sharing options...
jstout Posted October 27, 2007 Share Posted October 27, 2007 The field design is in a TSA (Tile Squaroid) format with numbers that order the blocks (some blocks are used more than once).By opening I meant the Team NFL logo, NFLPA, SUPER BOWL, and possibly the player graphics (SF O-line, Montana, Sanders, and LT).Yeah, I have notes on the play design and could answer almost any question you may have. It isn't really difficult to understand once you know where and what to look for. The big problem for me and probably to get the design to work in a program is that it is like Pointers 'R Us where one added byte could change many dozens of pointers which aren't right next to each other. Quote Link to comment Share on other sites More sharing options...
cxrom Posted October 29, 2007 Author Share Posted October 29, 2007 It isn't really difficult to understand once you know where and what to look for. The big problem for me and probably to get the design to work in a program is that it is like Pointers 'R Us where one added byte could change many dozens of pointers which aren't right next to each other.so lemme get this straight:-you have an array of 8 bytes, 1 for offense and 1 for defense.-depeding on plays picked by both teams, you get 2 indexes into "plays" pointer table-the "play" struct has pointers to "behaviors" for each player (on O and D respectively).so:1. by changing a "behavior," you'd need to change all pointers in every "play" struct that reference that behavior. you'd also need to update pointers to all the "behaviors" that follow the edited one.2. by changing a "play" you'd need to change the address (and update all "plays" that follow) in the pointer table that the 8 byte grid indexes to.is this close to how it works? Quote Link to comment Share on other sites More sharing options...
jstout Posted October 29, 2007 Share Posted October 29, 2007 That is close however the behaviors even have pointers. So you will have to update every following play struct and following pointers in the behavior.Here is an example with something easy:Play: R AND S SWEEP LSlot: Run 1Formation: 0CPlay #: 14, 14, 52, 52, 14, 14, 51, 51Defense: 63, 62, 62, 61, 60, 60, 61, 61The formation has a set of 22 bytes (11 pointers) for the offensive alignment. The offense has 3 structs for this play (14, 51, 52) with each having 22 bytes (11 pointers) for each player. The defense has 4 structs against this play (60, 61, 62, 63) with each having 22 bytes (11 pointers) for each player.The offensive formation pointers are in x4010, the offensive structs are in x4410, and the defensive structs are in x6010. Offense pointers go to section x8010 and Defense pointers go to section xA010.Offense #14 has pointers of A6CD, A6D8, BE3C, B781, A714, A720, A67E, A683, A689, A726, BE36.WR1's behavior (B781) is F7 10 FF 54 BE. This means Boost HP by 10 then his behavior continues at BE54. At BE54 is FC FF E0 37 FE FC. This means Set to Grapple players FFE0 (this is set bitwise and is equal to every defensive player), go block the RCB, and then go back 4 bytes (to the Set to Grapple command thus looping him forever to block the RCB).---The behavior pointers are listed under goto pointers (xFF), jump forward or backward bytes (xFE), Random goto pointers (x20 to x2F), A pointer for change of possession during a pass (part of x91 to x94), CPU goto pointers (xC7), and Random CPU goto pointers (xC8). Quote Link to comment Share on other sites More sharing options...
cxrom Posted October 29, 2007 Author Share Posted October 29, 2007 WR1's behavior (B781) is F7 10 FF 54 BE. This means Boost HP by 10 then his behavior continues at BE54. At BE54 is FC FF E0 37 FE FC. This means Set to Grapple players FFE0 (this is set bitwise and is equal to every defensive player), go block the RCB, and then go back 4 bytes (to the Set to Grapple command thus looping him forever to block the RCB). i think i got it, so wr1s script could be re-written as: F7 10 FC FF E0 37 FE FC with the jump (FF 54BE) taken out (assuming addresses are updated...)? whats the significance of setting grapple(all) if blockRCB() is issued afterwards? also im i correct that commands D0 = positionPlayerRelative(signed Y, unsigned X) D1 = positionPlayerAbsolute(unsigned Y, unsigned X) for the QBs formation data (R AND S SWEEP L: D0 F0 12 EE D0 0C 40)? also i've seen alot of $EAs, $ECs, and some $EEs, what do these do? after looking at some of this i can already see the pointer madness. Quote Link to comment Share on other sites More sharing options...
jstout Posted October 29, 2007 Share Posted October 29, 2007 Here is the guide I made for my reference (TSB II and III have a few more commands not listed). It doesn't show anything extra though about the commands.Location = Y, XPointer = Lo, Hi0x01 = m2m HB (Time)0x02 = m2m FB (Time)0x03 = m2m WR1 (Time)0x04 = m2m WR2 (Time)0x05 = m2m TE (Time)0x11 = m2m HB (Time)0x12 = m2m FB (Time)0x13 = m2m WR1 (Time)0x14 = m2m WR2 (Time)0x15 = m2m TE (Time)0x20 to 0x2F = Random Number (Pointer) ***Note x20 is likely to x2F isn't likely0x30 = Block RE0x31 = Block NT0x32 = Block LE0x33 = Block ROLB0x34 = Block RILB0x35 = Block LILB0x36 = Block LOLB0x37 = Block RCB0x38 = Block LCB0x39 = Block FS0x3A = Block SS0x40 = Chop Block RE0x41 = Chop Block NT0x42 = Chop Block LE0x43 = Chop Block ROLB0x44 = Chop Block RILB0x45 = Chop Block LILB0x46 = Chop Block LOLB0x47 = Chop Block RCB0x48 = Chop Block LCB0x49 = Chop Block FS0x4A = Chop Block SS0x50 = Handoff QB0x51 = Handoff HB0x52 = Handoff FB0x53 = Handoff WR10x54 = Handoff WR20x55 = Handoff TE0x56 = Handoff OC0x57 = Handoff LG0x58 = Handoff RG0x59 = Handoff LT0x5A = Handoff RT0x60 = Fake Handoff QB0x61 = Fake Handoff HB0x62 = Fake Handoff FB0x63 = Fake Handoff WR10x64 = Fake Handoff WR20x65 = Fake Handoff TE0x66 = Fake Handoff OC0x67 = Fake Handoff LG0x68 = Fake Handoff RG0x69 = Fake Handoff LT0x6A = Fake Handoff RT0x70 = Pitch QB0x71 = Pitch HB0x72 = Pitch FB0x73 = Pitch WR10x74 = Pitch WR20x75 = Pitch TE0x76 = Pitch OC0x77 = Pitch LG0x78 = Pitch RG0x79 = Pitch LT0x7A = Pitch RT0x80 = Motion Following QB0x81 = Motion Following HB0x82 = Motion Following FB0x83 = Motion Following WR10x84 = Motion Following WR20x85 = Motion Following TE0x86 = Motion Following OC0x87 = Motion Following LG0x88 = Motion Following RG0x89 = Motion Following LT0x8A = Motion Following RT0x91 = Pass (#1, #2) (Pointer) ***Note Receivers are first nibble player (0 = QB to 5 = TE) and second nibble is chance of being thrown to (0 = not likely to F = likely)0x92 = Pass (#1, #2, #3) (Pointer) ***Note Receivers are first nibble player (0 = QB to 5 = TE) and second nibble is chance of being thrown to (0 = not likely to F = likely)0x93 = Pass (#1, #2, #3, #4) (Pointer) ***Note Receivers are first nibble player (0 = QB to 5 = TE) and second nibble is chance of being thrown to (0 = not likely to F = likely)0x94 = Pass (#1, #2, #3, #4, #5) (Pointer) ***Note Receivers are first nibble player (0 = QB to 5 = TE) and second nibble is chance of being thrown to (0 = not likely to F = likely)0xA0 = Route #10xA1 = Route #20xA2 = Route #30xA3 = Route #40xA4 = Route #50xB0 = Set Position From Kickoff (Location)0xB1 = Set Position From Kickoff (Location)0xB2 = Set Position From Kickoff (Location)0xB4 = Move-Absolute (Location)0xB5 = Move-Absolute (Location)0xC0 = Dropback (Location)0xC1 = Computer Pass Timing (Start Time, End Time, Take Sack Chance)0xC4 = Celebrate (Unknown)0xC5 = Cry (Unknown)0xC7 = Computer Jump To (Pointer)0xC8 = Computer Random Jump To (Pointer) (Random) ***Note Random x00 is likely to x0F isn't likely0xCC = Pass Block0xCD = Move-Relative (Location)0xCE = Move-Absolute (Location)0xCF = Move-Absolute (Location)0xD0 = Set Position From Hike (Location)0xD1 = Set Position From Middle (Location)0xD2 = Hike under Center0xD3 = Hike from Shotgun0xD4 = Take Snap under Center0xD5 = Take Snap from Shotgun0xD6 = Take Snap for Field Goal/Extra Point0xD7 = Move-Relative (Location)0xD8 = Move-Absolute (Location)0xD9 = Move-Absolute (Location)0xDA = Pass Rush0xDB = Vertical Mirror Ball Carrier0xDD = Adjusting Pass Rush0xDF = Computer Takes Control0xE0 = Boost RS (Boost)0xE1 = Boost MS (Boost)0xE2 = Boost RP (Boost)0xE3 = Boost MS (Boost)0xE4 = Player Takes Control0xE5 = Kickoff0xE6 = Punt0xE7 = Field Goal0xE8 = Extra Point0xEA = 3-Point Stance0xEB = Shift (Time)0xEC = 2-Point Stance0xED = Motion (Time)0xEE = QB Stance0xEF = Change Player Icon to Returner0xF0 = Face Direction (Direction)0xF3 = Pause (Time)0xF4 = Pause (Time)0xF5 = Pause (Time) ***Note Time is 2 bytes0xF7 = Boost HP (Boost)0xFA = Recover Ball0xFC = Set To Grapple (Players) ***Note players are selected in bits0xFD = Set To Pass Block (Players) ***Note players are selected in bits0xFE = Go Backward or Go Forward (# of Bytes) ***Note # of Bytes are from Signed numbers0xFF = Jump To (Pointer) Quote Link to comment Share on other sites More sharing options...
jstout Posted October 30, 2007 Share Posted October 30, 2007 F7 10 FC FF E0 37 FE FCwith the jump (FF 54BE) taken out (assuming addresses are updated...)? whats the significance of setting grapple(all) if blockRCB() is issued afterwards?The first time it sets grapple to all makes sure the player isn't able to run through a defender during his path to the RCB. The block RCB makes him chase down the RCB. Without the grapple he would get to the RCB and then just stand on top of him doing nothing. However the behavior would work the same just jumping back to the Block RCB each time.also im i correct that commandsD0 = positionPlayerRelative(signed Y, unsigned X)D1 = positionPlayerAbsolute(unsigned Y, unsigned X)That is close but it really isn't signed and unsigned since F0 is the center of Y in the D0 command and 78 is the center of Y in the D1 command. And the D0 command is adjusted by where the ball is placed. I'll also note the difference of each x08 for X is a yard.for the QBs formation data (R AND S SWEEP L: D0 F0 12 EE D0 0C 40)?A little too far. The QB formation data is only D0 F0 12 EEalso i've seen alot of $EAs, $ECs, and some $EEs, what do these do?The guide I just posted will have that. Quote Link to comment Share on other sites More sharing options...
cxrom Posted October 30, 2007 Author Share Posted October 30, 2007 woah. i'm gonna mess with that for awhile and i'll get back to you. i'll see what i can come up with and thanks again. Quote Link to comment Share on other sites More sharing options...
cxrom Posted October 30, 2007 Author Share Posted October 30, 2007 so i started thinking about how to manage all the pointers and realized its probably more of a pain then its worth. i think i'm gonna make the tool assemble a base *.asm file over the selected rom. that way all pointers are updated any time changes are made. i did this for some data in the 32rom and it worked nicely.so along those lines i started building a dissassembly for banks 1 and 2 (0x04010 - 0x0C00F) and replacing addresses with labels. probably gonna use #defines for commands. so you get: .dw off_qb_PosUnderCenter, off_hb_PosSingleback, off_fb_PosWingTE .dw off_wr1_PosSplitEnd, off_wr2_PosFlanker, off_te_PosRightSide .dw off_c_PosCenterSnap, off_lg_Pos, off_rg_Pos, off_lt_Pos, off_rt_Pos.........off_qb_PosUnderCenter: .db setPositionFromHike, $F0, $12, stanceQBif the tool doesn't end up editing the base file, you'd still be able to do it by hand and leave the pointers to the assembler. i thinks its safe to assume that those that can edit plays will be able to make sense of it. Quote Link to comment Share on other sites More sharing options...
jstout Posted October 31, 2007 Share Posted October 31, 2007 Hmm, that sounds interesting and would handle the pointers. After looking at this I know I could do something like this using CA65 but have one problem.From my example:.define BlockRCB $37.define BoostHP $F7.define SetGrapple $FC.define JumpTo $FF.segment "TEST".WORD WR1_Boost_RCBWR1_Boost_RCB: .BYTE BoostHP, $10, JumpTo, Block_RCBBlock_RCB: .BYTE SetGrapple, %11111111, %11100000, BlockRCB, $FE, $FCThe above works but I don't know how to get the FE FC command to automatically calculate the go back to Block_RCB. Any ideas? Quote Link to comment Share on other sites More sharing options...
cxrom Posted October 31, 2007 Author Share Posted October 31, 2007 i've never used ca65 but lookin at the user guide, somethin like this might work (* is the current PC variable).label: .db SetGrapple, $FF, $E0, BlockRCB, $FE, label - *by the way, does ca65 support rom patching?i've reconstucted the offensive formations/behaviors (0x04010 ~ 0x04300 and 0x08100 ~0x08300). eventually all this should be put together towards a full disassembly. i know i've got quite a bit of prg 8, 11, 12, 15 commented and some other data banks have been recontructed. still a ways to go though.edit: you might need to cast (label - *) to a byte, not sure Quote Link to comment Share on other sites More sharing options...
jstout Posted October 31, 2007 Share Posted October 31, 2007 Thanks, I just tested and this is what worked correctly:.define BlockRCB $37.define BoostHP $F7.define SetGrapple $FC.define LoopTo $FE.define JumpTo $FF.segment "TEST".WORD WR1_Boost_RCBWR1_Boost_RCB: .BYTE BoostHP, $10, JumpTo, Block_RCBBlock_RCB: .BYTE SetGrapple, %11111111, %11100000, BlockRCB, LoopTo, Block_RCB + 1 - *I'm not sure if it is able to patch onto a rom as I've never tried. My thinking was I would just make the segments come out correct and then paste into the rom.I broke down all the rom into data and code but there are no labels or comments on anything so I'm sure you are further along than what I've done in the past. Quote Link to comment Share on other sites More sharing options...
cxrom Posted November 1, 2007 Author Share Posted November 1, 2007 .org $A567 .db $F3, $14, $D8, $F0, $C0 ; [$A567] pause(14), moveAbsolute(F0, C0), .db $D8, $F8, $E0, $D8, $04, $F0 ; moveAbsolute(F8, E0), moveAbsolute(04, F0), .db $C8, $89, $A5, $09 ; cpuRandJumpTo(A589, 09), .db $C8, $8D, $A5, $05 ; cpuRandJumpTo(A58D, 05), .db $C8, $91, $A5, $02 ; cpuRandJumpTo(A591, 02), .db $C7, $95, $A5 ; cpuJumpTo(A595), .db $E4, $FF, $38, $B8 ; playerTakeCtrl(), jumpTo(B838)the "cpu" commands are only exectued when the team is COM or COA?i've also noticed there's some repeat commands like moveAbsoute ($D8 and $D9). are they the same command or similar commands? Quote Link to comment Share on other sites More sharing options...
jstout Posted November 1, 2007 Share Posted November 1, 2007 The CPU commands of xC7 and xC8 are only executed by a COM team and not a MAN or COA. The majority of these computer jumps go to random boosts of speed or strength or slight adjustments for the computer throwing the ball.There are some similar commands that have very subtle differences so just let me know which ones you run into but I'll go through the list later and note them. But for xD8 and xD9 (similar to xD0 and xD1):xD8 is based upon where the ball is snapped (top hash, middle, or bottom hash) where the ball is at xF0. xD9 is based upon the field where the middle is x78. Other than this difference the commands work exactly the same. Quote Link to comment Share on other sites More sharing options...
cxrom Posted November 1, 2007 Author Share Posted November 1, 2007 so how do commands $2x(ptr) work as opposed to $C8(ptr, rand).i came across a .db $2B, $48, $BEand im not sure what to make of it other then that$BE48 == off_behav_blockLILB. Quote Link to comment Share on other sites More sharing options...
jstout Posted November 1, 2007 Share Posted November 1, 2007 Here are those same commands:0x01 to 0x05 and 0x11 to 0x15 (no visible difference so likely is the same command).0xB0, 0xB1, and 0xB2. Each one is a longer distance away from the kickoff. Obvious purpose is because 1 yard = x08 so at most you would have 30 yards of lineup for the return team without more.xB4 and xB5. Same as logic as previously stated. Needed more distance to move to.xCD, xCE, xCF and xD7, xD8, xD9. The commands work in the same way (xCD/xD7, xCE/xD8, and xCF/xD9) but after a Set Block (xFD) command xCD/xCE/xCF will break from the run path to block a player found along the way. xD7/xD8/xD9 won't go to block until the player has reached the end of the path.xE1 and xE3. Slight but unclear difference however xE1 is only used on the kickoff return.xF3, xF4, and xF5. xF3 and xF4 are the same but xF4 makes the player face towards the ball and xF3 faces the current direction. xF5 is (Start Time, End Time) and will pause until Start time then randomly leave anytime up to the End Time. Quote Link to comment Share on other sites More sharing options...
jstout Posted November 1, 2007 Share Posted November 1, 2007 so how do commands $2x(ptr) work as opposed to $C8(ptr, rand).i came across a .db $2B, $48, $BEand im not sure what to make of it other then that$BE48 == off_behav_blockLILB.The $2x(ptr) works exactly the same as $C8(ptr, rand) other than $2x works for MAN, COA, and COM and $C8 works just for the COM. x = rand.Here is an easy example of the $2x set.B79C = 2B 48 BE, FC FF E0, FF 2E B8BE48 = FC FF E0, 35, FE FCB82E = F3 00, FE FEB79C goes to a random 2B (B is our random value). If B is chosen (BE48) then the player sets to grapple everyone then blocks the LILB forever. If B isn't chosen (continues on to eventually B82E) then the player pauses forever. Quote Link to comment Share on other sites More sharing options...
cxrom Posted November 2, 2007 Author Share Posted November 2, 2007 as i map out more of the behaviors, im running into the problem of ambiguity of label names...off_wr1_BlockFS_0: .db $D9, $36, $48 ; [$A8FB] moveAbsolute(36, 48), .db $FF, off_behav_blockFS ; jumpTo(BE60)off_wr1_BlockFS_1: .db $D9, $36, $28 ; [$AD59] moveAbsolute(36, 28), .db $FF, off_behav_blockFS ; jumpTo(BE60)...both essentially do the same thing. personally i dont care if there's label_0 to label_n, but do you have any suggestions for better naming conventions?with what's mapped out now, i've had some fun with formations and some behaviors it looks very promising. Quote Link to comment Share on other sites More sharing options...
jstout Posted November 2, 2007 Share Posted November 2, 2007 ...both essentially do the same thing. personally i dont care if there's label_0 to label_n, but do you have any suggestions for better naming conventions?I don't have any worthwhile suggestions on that. I would be doing the 0 to nth too. Maybe someone else has an idea for the labels. Quote Link to comment Share on other sites More sharing options...
cxrom Posted November 29, 2007 Author Share Posted November 29, 2007 now to get back to this0x01 = m2m HB (Time)0x02 = m2m FB (Time)0x03 = m2m WR1 (Time)0x04 = m2m WR2 (Time)0x05 = m2m TE (Time) 0x01-0x05: probably same0x11 = m2m HB (Time)0x12 = m2m FB (Time)0x13 = m2m WR1 (Time)0x14 = m2m WR2 (Time)0x15 = m2m TE (Time) 0x11-0x15: probably same0x80 = Motion Following QB0x81 = Motion Following HB0x82 = Motion Following FB0x83 = Motion Following WR10x84 = Motion Following WR20x85 = Motion Following TE0x86 = Motion Following OC0x87 = Motion Following LG0x88 = Motion Following RG0x89 = Motion Following LT0x8A = Motion Following RTwhat does "m2m" and "Motion Following ..." mean? Quote Link to comment Share on other sites More sharing options...
jstout Posted November 29, 2007 Share Posted November 29, 2007 now to get back to thiswhat does "m2m" and "Motion Following ..." mean?m2m = Man To Man coverageMotion Following is after the defender has lined up with this command then will move vertically on the screen until lined up directly across from the player marked. Thus is most helpful for the facing the offensive motion plays. The defender will line up on the screen and move with the player in motion stopping across where they do. Quote Link to comment Share on other sites More sharing options...
Coach_Bama Posted May 16, 2009 Share Posted May 16, 2009 Play: R AND S SWEEP LSlot: Run 1Formation: 0CPlay #: 14, 14, 52, 52, 14, 14, 51, 51Defense: 63, 62, 62, 61, 60, 60, 61, 61The formation has a set of 22 bytes (11 pointers) for the offensive alignment. The offense has 3 structs for this play (14, 51, 52) with each having 22 bytes (11 pointers) for each player. The defense has 4 structs against this play (60, 61, 62, 63) with each having 22 bytes (11 pointers) for each player.The offensive formation pointers are in x4010, the offensive structs are in x4410, and the defensive structs are in x6010. Offense pointers go to section x8010 and Defense pointers go to section xA010.Offense #14 has pointers of A6CD, A6D8, BE3C, B781, A714, A720, A67E, A683, A689, A726, BE36.How are the pointers for the offense structs determined? Starting at x4410, do they go in order as they are placed in the ROM? Ex: If the first run play, in the first run slot, has one struct, are there 11 pointers and then the second run play begins? If there are two structs, are there 22 pointers and then the next play begins? This doesn't seem to be the case in my experimentation.Are the structs themselves positioned in a certain order?***Edit: I think I figured it out. The pointers for each player, in each struct, are identified on the tabs in TSB Playmaker. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.