hit print screen on your keyboard to take a snapshot of the current screen to the clipboard. Then paste it into a image editor such as photoshop.
Awesome got it to work thank you for the reply and awnser Eternal.
Small update:
CHANGELOG (v0.11 – 2nd, May, 2014)
Only a small update this time.
Added “Show Information”. Shows Health, Stun, Position, Distance, Ex and Ultra meter, Combocounter, Animation Number and which frame of the animation is currently active.
Changed the throw box color to blue (from green)
Download link is here
Oh, almost forgot, I think it was abeltech who found the pointers for active animation frames, so spacial thanks to him for that!
You are gdlk thank you
Another small update.
CHANGELOG (v0.12 - 5th, May, 2014)
Added Pause and Next Frame functions as requested by a few people. In an attempt to make them not crash (as often) as the same function in SF4 Camera Man, this will only work if the user has not paused the game himself. Once the user has paused the game (even once!) it will not function anymore and the user will have to re-enter the stage. If it still crashes I don’t know what it could be, sorry. Hotkeys are the same as in SF4CM, TAB for pause/unpause, CTRL+TAB to advance 1 frame.
Download link is here.
akuma and oni’s raging demons in-sync sounds too badass
Forgot to mention that I did a sample with your code that shows how to inject the drawing routines but I never got around to finishing it. Lemme know if you wanna see it.
There was some noticeable slowdown with v.0.12. I switched to v.0.11 and it went away - thank you for leaving the old versions up.
I guess my PC is just not powerful enough?
@lullius
10928 - Left Shoulder
11088 - Left Elbow
11248 - Left Wrist
11408 - Left Hand
11568 - Left Hip
11728 - Left Knee
11888 - Left Ankle
12048 - Left Foot
12208 - Right Shoulder
12368 - Right Elbow
12528 - Right Wrist
12688 - Right Hand
12848 - Right Hip
13008 - Right Knee
13168 - Right Ankle
13328 - Right Foot
14928 - Also right elbow but seems to lag 1F behind 12368? E.G. the hurtbox is positioned 1F slower than the actual game. Seems to follow the same pattern
of numbers as the previous section but 2560 higher. E.G. 12848+2560 = 15408 = Right hip
but 1F lagging.
These numbers assume the player is facing towards the right of the screen (E.G. Player 1 starting position)
If you have the player facing the left side the screen (E.G. Player 2 starting direction) then all calls for left and right are swapped. E.G. If you have an attack that modifies the Left Elbow hurtbox it will wont be displayed if you have 11248 enabled. Instead you need 12528 enabled.
Also if you notice there is a pattern where if you take the Left side and add 1280 you get the right sides number. Thought it was worth pointing out.
@lullius some stuff I noticed that I’d like to know if you can figure out how to address:
-
It seems the program has some trouble displaying Yun’s palm strike hitbox correctly. I’m sure this affects a few other attacks as well. What happens is if you do his palm (QCB+Punch) it won’t show all of the hitboxes. He has a hitbox that can only hit grounded opponents and a hitbox that can hit both ground and air. Every time you do the palm strike it only shows one of the two hitboxes and then the next palm strike shows the other hitbox. E.G. it’ll show the only hit grounded opponents part then next time it’ll show the hitbox that can hit both grounded and air. It should be displaying these both at the same time every time.
-
The way that the camera shifts in-game causes slight inaccuracies in the hitbox display. When characters are farther apart the hitboxes aren’t drawn in the same spot as when they are close together. This is especially noticeable during jumping attacks. It’s not a big deal but it’s one that would be nice if fixed.
Also some other stuff:
Any chance you could remove the pushboxes / throw hurtboxes from the “Basic” section and make them selectable on their own as a check box? That way you can see the full hurtbox without having those images in the way.
Could you also make sure hurtboxes are always layered OVER the hitbox? Seeing as hurtboxes are empty squares while hitboxes are filled in squares it’d be easier to keep track of hurtboxes if they weren’t obscured by hitboxes.
If you can’t figure out how the game turns hurtboxes on or off could you simply set the “head, chest, waist” hurtboxes that you have set under “basic” as individual check boxes in addition to the numbers I listed earlier. Some moves turn off hurtboxes on heads for instance Cody’s B+MP has no hurtbox on his head. However it still has a hurtbox on his waist and so I can’t make a clear image of his B+MP hurtbox because the only way to turn off the head hurtbox display also turns off the waist hurtbox.
Lastly, any chance you could remap the “Next Frame” button to the **** button? (The one directly above TAB on standard KBs) makes more sense to me personally and easier to hit repeatedly than CTRL+Tab. Plus it seems silly to have a button designation that requires two buttons when you are only using two commands. The key isn’t typically bound to anything in-game. Alternately you could do Left Shift or just Ctrl by itself.
Thanks! I’ll see if I can rename these in the list in the next version.
Useful info there. I don’t know why there’s so many boxes lagging one frame behind. I hadn’t noticed that the sides were 1280 a part, nice find.
-
I’m aware of this. It has something to do with where the box is stored in memory I think. I don’t quite remember right now, but I think there’s something like 16 ‘slots’ in memory for each player’s fireballs. That means that the game can display a total of 32 fireballs at once. If you throw a fireball, then wait, then throw another one, usually it would use slot 1, disable it when the fireball goes offscreen, then re-use it for the second fireball. If you throw fireballs in rapid succession the game won’t have time to clear slot 1, so slot 2 is used for the second fireball. When more than 1 fireball is on screen (Akuma’s jumping EX fireball, Juri’s super and so on), more of the slots are used to keep track. I’m guessing that Yun’s palm tries to show two boxes at once, but for some reason SF4BV isn’t picking up one of the boxes. The next time you do it, the ‘slots’ have been swapped, or gone from number 1 and 2 to number 2 and 3 or something like that. The buggy box is now somehow swapped to the other hitbox, and now only the other one displays correctly… I don’t know why it isn’t detected as even Juri’s super works (although glitchy).
-
Yes, that is correct. I mentioned it in the readme. It’s not an easy fix though. SF4BV is essentially it’s own game with it’s own 3d space. It tries to copy the camera movement from SF4 and apply it to it’s own camera. This will probably never be 100% accurate. And even if I could copy the camera moves perfectly there’s still the aspect ratio and so on. I had to guess a couple of numbers to get it as close as it is. By the way, the camera in SF4BV does not copy SF4’s camera roll. It’s especially noticeable if you open SF4CM and roll the camera.
I don’t think that I’ll be working to improve this as it’s better to leave this up the the game itself. If SF4BV was hooked into the game it could use the game’s own camera setup and there would be no need for any of this. It would make the boxes 100% accurate just like the original debug mode. It would also work in fullscreen mode, in any resolution and aspect ratio.
Then why aren’t I doing it? Well, to be honest, I tried. I’m no good with 3d or hooks (or programming in general…) . I hooked into SF4 and can use it to draw things on the screen, but I can’t get what I draw to be part of the game’s 3d space for some reason (it just stays still whatever I do in the game). The game won’t give me it’s camera values (getTransform), so I’m guessing it uses some other way of setting it up and moving it. If I could figure out how to draw directly in SF4’s 3d space it would be pretty simple to port SF4BV over I think.
I could add more check boxes for throw and push.
I don’t know if I want to make hurtboxes layered over hitboxes. I don’t think it would be a problem to do so, but then it wouldn’t let you see how ‘deep’ the boxes are. Every box in SF4 has 3 coordinates. X, Y and Z. They are not 2d, but 3d. This can be easily seen by using SF4CM to move the camera so you can see the boxes at an angle instead of the usual straight on view. If something is drawn on top of something else, it means that it’s closer to you (out of your screen) in the game.
I don’t think that moving hurtboxes from basic to the list of other hurtboxes would be a problem. I’d really like to do it the way the games does it though, by turning them on and off, but it’ll have to wait a little. At least until SF4BV is hooked in to the game and can draw everything perfectly. I think that should probably be priority number one right now.
I could remap the Next Frame function to another button, no problem, but it won’t be **. The reason for that is that ** is not located in the same spot on every keyboard. I could use Ctrl by itself or Left Shift though.
Thanks for all the feedback!
Even though most of these suggestions are easily doable I don’t know exactly when the next version will be out or how much of the suggestions it will include. I work on SF4BV when I have the time and feel like it. I’m not saying I’m done programming for SF4 just yet, but I’ve grown a little tired of programming SF4 tools lately so things are moving quite slow now. Everyone is free to check out the code on github and make contributions though.
I sent you a message. I’m very interested in seeing what you came up with.
I don’t know why that would happen. I’m guessing it’s some kind of bug because I don’t think 0.12 should use noticeably more resources than 0.11.
I should really post in here more often. I always try to write too much in one post to catch up. Just look at this one, probably my longest post yet. 
Found another weird bug:
The position info gets all screwy for Ibuki’s backdash and command jump (DP + Punch) at some points during the command jump the game lists her position as negative on the Y axis which would put her under the ground. Likewise her backdash reads as though she moved forward up until she recovers then the position info is correct. If you do a backdash from the starting positions (distance apart: 3) around frame 20 until recovery completes it says that the distance is 2.775 and her posX is -1.275. Once the recovery has completed the information changed to the correct distance of distance 4.575 posX -3.075
Also, the thing you have listed as “Animation #” isn’t actually the animation. It’s the move script. For example, Ryu’s farMP got a buff back in Super that allowed it to be special cancelable. When they did that buff they added a new script called 5MPF_New with an index number 346. The index number for Ryu’s old far MP is 263. They both use the same animation though (RYU_ATK_5MPF which is animation # 80 )
Lastly, Ibuki’s Kunai (fireball in mid air) and Super Combo (Where she throws a bunch of Kunai) and Cody’s knife throw are all strike hitboxes not projectile hitboxes but you have them show up as solid green projectile hitboxes and have the flagged under projectile not attack. They are projectiles, but the way the game reads them is as strikes for purposes of hitbox data.
Something I’m curious about. Why does it slow down SO much when you turn on show information? is it just because of drawing all of that additional stuff on screen or is it really that taxing to read the information as it’s generated? I noticed a HUGE drop in frame rate sometimes when I turn it on. Sometimes it’s not so bad but other times I have to close SF4BV and start it up again a few times before the frame rate is even remotely at a playable level with the show information tag on.
