Jump to content

konForce

Members
  • Posts

    26
  • Joined

  • Last visited

Contact Methods

  • Website URL
    http://

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. In short it's an unfinished version (that I abandoned in favor of a GUI version) that lets you edit large helmets & their logos.
  2. I haven't had a chance to work on it since the holidays, so there is no update. However, if I can find the original non-GUI version one I'll post it.
  3. I understand how to make user defined plays, all the way down to the routes, etc. There is still some unknown information, but it's nothing that couldn't be figured out. The kicker is that embedded in the route information is the CPU logic. The CPU is not smart, it just does what the logic tells it to per route. In other words, if you create a play you also have to tell the CPU how to use the play. What happens in the play sequence is at the end, a "take control" byte command is issued. If you are a human then you can now control the player and the play sequence is halted. However, if you are a CPU, the play sequence continues according to the logic that immediately follows it. (The last beta of my editor did not even attempt to load CPU data and thus, when saving the playbook, all CPU logic is overwritten with garbage.) The logic for a QB might look like: 1) Drop back for pass. 2) If random number is A then pass to a player 3) If random number is B then move to a location (scramble) 4) While scrambling, if random number is C then pass to a player 5) Run with ball. I never had time to completely look into this, but to me it looked like the best way to create a usable playbook editor would be to actually create a program that lets you draw plays up, and then press a "compile" button that creates the NES byte code needed for TSB. In other words the program would not be able to extract information from the TSB ROM, it would only be able to export a playbook to it. The method my playbook "editor" uses would have only worked if things were a bit more structured in the TSB ROM.
  4. This is impossible (extremely impractical) to do natively, because of space limitations. While the limitations may appear odd, there is reasoning behind it. 63 is 6 bits. In order to get 64, you'd have to have 7 bits (which would give you 127 max). This would increase the space needed to store all the data. The NES only has a fixed amount of SRAM space, so Tecmo had to plan accordingly. The upcoming tecmo GFX editor will be available for MacOSX, but I know everything else (at emuware) is only for Windows.
  5. The update here should fix the problem: http://www.tecmobowl.org/forum/viewtopic.php?t=4417
  6. For background information, see: http://www.tecmobowl.org/forum/viewtopic.php?t=4307 TSB Playbook Editor Beta 3 is available. http://www.emuware.com/files/?tsbPBE-beta03.zip Updates since the second release: * BUGFIX: blitz byte (hopefully) saved correctly * Added more information to various command codes * Sequence data is reordered upon saving (*Nukes CPU AI*) * Added "Safe Save" option The purpose of this release is to correct a problem that was brought to my attention regarding the blitz byte not being saved properly. It should be resolved now, but you'll have to see for yourself if it works. Other than that, there is no additional useful functionality. The editor does load the squences more accurately than Beta 2, but this doesn't translate into any practical applications. If you want to use the editor to swap plays around, use the Safe Save option. It only saves the play slot information. Doing a Full Save will damage the ROM in that all offensive CPU AI will be corrupted. The discovery that TSB stores CPU play logic within the sequences threw a monkey wrench into the route I was taking. To make a useful play editor, a completely high level editor would be necessary - ie, one that would essentially "compile" the playbooks into the NES format. This editor does not do that, and will likely only remain a debugging tool. tsbPBE-beta03.zip
  7. I believe the problem is that when you copy a play slot, the source play's blitz byte ends up being the same as the destination play's blitz byte. So if you copy a play to the other 3 slots, they will all share the same blitz byte (the final copied play is correct, the original(s) are not). Most likely due to a copy by reference when I was expecting it to copy by value. Update: http://www.tecmobowl.org/forum/viewtopic.php?t=4417
  8. No look at all, Preaseason, HOU (Man) vs SF: HOU 48 SF 35 Won the coin toss, but lost the opening kickoff to a fumble... On D picked a DL and rushed the QB every play. On O picked second pass play every time and threw to Hill, unless I goofed and called a different play. FGs/XPs were kicked by mashing the buttons. Kickoffs were kicked at random. Scored a TD every possession until the fourth quarter when I kicked two field goals. First was kicked after I recovered an onsides kick and completed a pass. Good off the upright. 49er's fumbled the kickoff, so I kicked another FG immediately. Good off the upright. Last possession I turned over on downs. (So only 6 4th Q points.) D forced SF to punt twice and loss of downs twice thanks to around 12 total sacks. Tom Rathman: 6 attempts, 98 yards. Team 128 yards. Montana to Rice for 63 yards. Team 123 yards. Moon to Hill for 262 yards. Team 343 yards (47% completion)
  9. Regarding play book editor, there very well could be problems with the blitz byte. Regarding the helmet editor, there is no release yet, and probably won't be for a few weeks, as I can only work on it a little bit on weekends.
  10. You can change which one of the 128 CHR sprite pages (64 tiles each) is used per helmet logo, although unless you feel like butchering some other graphics in the game, it doesn't make any sense in going outside the original four or five pages allocated. Regarding the tiles that are used, those can be added, removed, and rearranged at will. If you look at the 'konForce' helmet, you'll see the alignment has been changed from what the original (Steelers) helmet used. The editor does not attempt to use any of the empty space at the end of the PRG bank (there's enough to be somewhat useful), so you are still limited to the same sum size (for all the teams put together). The release of it is delayed somewhat, as I'm converting it to use a 3rd party GUI lib to make it more extensible down the road.
  11. It's a high level editor, so no knowledge of how TSB stores the GFX is necessary. Although, it's helpful to understand the space limitations and how to make the best use of column aligned tiles (save PRG/code space) VS pixel aligned tiles (save CHR/tile space) The first release will allow you to edit the large helmets. The 1960 ROM, team selection screen. A modern Washington Redskins logo edited by hand. Notice the wasted (unused) tile space and unnecessary pixel aligned tiles (right two). Original Washington Redskins logo. A helmet edited by yours truly. Notice that there is only one underline graphic. As you can tell by the grid lines the left and right most underline piece on the helmet have been adjusted one pixel to the right/left. End result is saving three graphical tiles, but using four more bytes of code space. (Each new pixel adjust costs two bytes.) The helmet above back on the main screen. Stripes are in style... (Ie, selecting a different background for the helmets.) Debugging console. What happens is after you move tiles around and such, the editor sorts the list for optimal size and then re-writes the code. A few helmets (colts and chargers, I think) actually are stored more effeciently with my sorting method than whatever the original programmers used. This is just by chance though; it is possible to construct a weird assortment of tiles where the editor does not produce the smallest amounts of bytes, but you'd have to really try hard to do that.
  12. My availability will be next to none starting next week, so I doubt I'd be able to do much regarding new projects. I have to finish up a helmet editor that I set aside while looking at playbooks. From there, I'll probably be too busy to be of much assistance, although I'm sure I'll continue on a working playbook editor and could try to answer a few questions now and then.
  13. No. On offense the RS=start, RP=acceleration, MS=max is somewhat of a simplification but it's pretty accurate, at least when RS I have not ever looked at the defensive code, so I'm only guessing that they use command bytes to increase speed. It could just be done at a global level, but that hasn't been the Tecmo style. On offense the "E boosters" add speed to the player's normal setting. This is used on flea flickers so that the QBs get back in time, etc. Tecmo always sets the boost back to normal before handing the control back on regular plays. (However, when your QB throws an interception, he gets a boost that doesn't go away.)
  14. On defense, yes. Defensive players are not capped at MS like offensive players. Instead, they are given a boost (maybe via the E0/E1/E2/E3 boost command bytes, if defense works like offense) so that they can catch up to the offensive players. The boost is so great that the MS ends up not meaning much at all. Instead, the RP becomes the critical factor. The more RP a defender has, the faster he will reach his boosted MS. A defender of 44RS 100RP 0 MS will be better than a defender of 44RS 6RP 100MS. The short of it is, for a defender, the RP is the critical factor for top speed, because it allows him to reach it more quickly.
  15. I left out some important info above regarding the general method, I'll edit the post...
×
×
  • Create New...