Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - odabugs

Pages: [1]
1
General Discussion / Re: Hitbox viewer general support & feedback
« on: July 05, 2014, 04:45:33 AM »
First baby steps toward compiling comprehensive hitbox data on SRK Wiki: http://wiki.shoryuken.com/The_King_of_Fighters_XIII/Kyo#Normal_Moves_2

We don't yet know precisely how to replace the stage background with a solid color, but with a bit of Photoshop work and the excellent sprite rips at Logical Bends we're starting to get a feel for ways to produce sharp, high-quality hitbox snapshots that should match what you see when running the game at 480p (which is the "native" resolution of hitbox data--if a box measures 50 units wide internally then it should generally show up 50 pixels wide onscreen at 480p).

2
General Discussion / Hitbox viewer general support & feedback
« on: July 04, 2014, 04:23:09 PM »
Hi,

Since we've heard of some people having trouble getting the hitbox viewer up and running, please post here to let us know about any issues you're experiencing with it.  For users who tried early on to install it and found that pydbg was giving them grief, this was largely due to a mistake in early revisions of the installation guide that has since been corrected.  We advise downloading the viewer again (so you won't hit "can't import utils" problems--we resolved that too) and repeating the install process using the unofficial pydbg installer package that can be found here: http://www.lfd.uci.edu/~gohlke/pythonlibs/#pydbg (grab pydbg-1.2.win32-py2.7.exe).  This is a considerably simpler and more error-proof way to install pydbg.

In the short term we're looking into tying up loose ends and implementing features that we were hoping to have done before the word got out a bit sooner than we anticipated (it happens!).  Later on down the line we may look into moving away from the current Python-based runtime environment toward something that will allow us to provide a simple "click and run" binary package (and hopefully improve stability--I'm sure some users have already noticed issues on this front).  In the meantime we're certainly also open to feedback, feature proposals, general questions and suggestions for changes.

Phoenix and I will do our best, our individual schedules allowing, to use this thread for providing user support, responding to feedback, and announcing new and planned features and changes.  Both of us may also be reached via PM on DC or on SRK, and users wishing to contribute to the project are encouraged to reach out to us (though contributors are also advised to note that our current codebase is obviously not quite in a mature state).

Currently planned changes for future builds (as of 07/04/2014):
+ Config file support (the config file we have right now is ignored by the program)
+ Proper layering of box rendering by box type
+ Customization of box colors and the layering order (by box type) in which boxes are drawn
+ Turn off box drawing for one player
+ Left/right facing indicator (helps to resolve ambiguous crossups)
+ Write general README and document existing command line arguments for usage (-usefill, -noborders, -nopivots, -thicklines, etc.)
+ Simple frame counter (once player state can be more reliably determined this will make collecting frame data significantly easier)

Longer-term "maybes":
+ Translations of documentation and program messages?  (User help will make a big difference here)
+ SF4 Box Viewer-style GUI in place of command line?
+ Frame advance or other TAS features? (May require more research to assess the viability of implementing this with our current codebase)
+ Downloadable package with required components bundled for install?

Misc. outstanding issues (as of 07/04/2014):
- 1080p and 1440p resolutions don't show boxes positioned properly on the Y axis (if anyone has a monitor large enough to take clear 1440p screenshots, please contact me to help here)
- Throwable boxes still need further research
- Controlling the game with a breakpoint is probably less than ideal for stability (alternative solutions?)

Pages: [1]