Topic: SFC3 MACRO UTILITY v0.9 READY!

[Vertigo]

Quote:
Just curious, but.......

Does it come with a manual?

DrSchreber  

A simple readme file.  I mean, you only use two keys after all...

Quote:

I have a little program I made that captures keystrokes without disrupting other progs. It's written in C++ and uses DirectInput, and the  graphical frontend uses MFC. I'd be willing to share the source with you. Unfotunately I can't test it with SFC3 since I don't have the game (yet).  

You misunderstand.  I've done that already.  When you capture keystrokes, you have two (and only two) options:

1) do your thing, and "eat" the keystrokes.  The main app (SFC3) never sees them.
2) do your thing, and pass the keystrokes onto SFC3.

With Option #1, chat doesn't work since any "a" and "s" keys never get to SFC3.

With Option #2, SFC3 sees the keystrokes and acts on them.  So you get this example:

1) You press "S."
2) My app sets your speed to EXACTLY 1/4 impulse.
3) The keystroke is then passed onto SFC3.
4) SFC3 sees the "S" command, and...
5) incremements your speed again by about 3%.
6) Your speed is no longer 1/4 impulse.

Ugly.

What I think I'll do:  I'll define ENTER as a Macro ON/OFF switch, and also pass ENTER commands through to SFC3.  So, you get this:
1) You Press ENTER to chat.
2) Seeing this, the SFC3Macro goes to sleep, and passes the ENTER key.
3) SFC3 sees your ENTER keystroke, and opens the chat window.
4) You type your message.  
5) You press ENTER to send your message.
6) Seeing this, the  SFC3Macro wakes up again, but after passing the ENTER key.
7) SFC3 sees your ENTER keystroke, and sends the message.

It's elegant, and seems like it would work.    

[Blitzkrieg]

Please define that key as somthing that isnt used when typing. Perhaps the ` key or # key or even the Insert key. Anything but the enter key or anything that takes up standard letters / important typing keys, please.

[ksfung]

Please re-read his last response, He plans on using the ENTER key to both toggle the macro, and pass through the ENTER key. I think that is a very elegant solution.

[3dot14]

just wondering how good is it when responding to customized key maps?

I don't use A and S for speed. I use Num7 and Num9. would the utility work with them?

[Vertigo]

Quote:
just wondering how good is it when responding to customized key maps?

I don't use A and S for speed. I use Num7 and Num9. would the utility work with them?  

In the current rev, no.  

However, I'm currently working on putting keybindings into an INI file.  (I saw this question coming).  Then you'll be able to simply change (for instance)

[Commands]
UpThrottle=A

to

[Commands]
UpThrottle=PAD7  (or whatever name I settle on).  

[Vertigo]

SghnDubh is also now hosting the file on BattleClinic.com, under the analysis section.  Thanks, SghnDubh!  

[SghnDubh]

(Standing on the porch, ringing the triangle)

COME N GET IT!

 

[Vertigo]

Version 0.93 is done, and has been sent to my gracious hosters.

Pi, you can now  use keypad buttons to change speeds, if you so desire.

Some moderate improvements in this version:

* Enter key now toggles macro utility on/off to allow for easier chat.
* Settings now kept in INI file.
* New file: Commands.txt, which explains key bindings.
* Added support for virtually all possible keybindings, about 83 keys.
* Added support for some non-standard keybindings, about 10 keys.
* Added support for key combos, such as SHIFT-CTRL-S.
* Added support for extended key flags (see commands.txt for more).

So you can now choose from perhaps about 500 different key combinations, but still
only have 3 commands to actually to bind them.  

That's about it for the groundwork.  The only thing left to do now is add actual
commands to make this thing more useful.

I'll tell you one thing: after using this util for a while, I can't stand clicking on the
speed bar anymore.  The hotkeys are sooo nice.
 

[Krusaderr]

Excellent work Vertigo. Thank you for taking time out of your schedule to make this.    

[zaniwhoop2]

Quote:

You misunderstand.  I've done that already.  When you capture keystrokes, you have two (and only two) options:

1) do your thing, and "eat" the keystrokes.  The main app (SFC3) never sees them.
2) do your thing, and pass the keystrokes onto SFC3.

With Option #1, chat doesn't work since any "a" and "s" keys never get to SFC3.

With Option #2, SFC3 sees the keystrokes and acts on them.  So you get this example:

1) You press "S."
2) My app sets your speed to EXACTLY 1/4 impulse.
3) The keystroke is then passed onto SFC3.
4) SFC3 sees the "S" command, and...
5) incremements your speed again by about 3%.
6) Your speed is no longer 1/4 impulse.

Ugly.

What I think I'll do:  I'll define ENTER as a Macro ON/OFF switch, and also pass ENTER commands through to SFC3.  So, you get this:
1) You Press ENTER to chat.
2) Seeing this, the SFC3Macro goes to sleep, and passes the ENTER key.
3) SFC3 sees your ENTER keystroke, and opens the chat window.
4) You type your message.  
5) You press ENTER to send your message.
6) Seeing this, the  SFC3Macro wakes up again, but after passing the ENTER key.
7) SFC3 sees your ENTER keystroke, and sends the message.

It's elegant, and seems like it would work.    

I guess I did misunderstand. Maybe if I could play with it, I'd understand better what's happening. What functions/interfaces are you using to catch the keystrokes (I'm assuming SFC3 uses DInput, maybe not)? As an alternative to the ENTER method, you could set the speed to a bit below 1/4 impulse so when SFC3  increases speed, it sets it to exactly 1/4 impulse. As it sounds, I think the ENTER method is strange, but maybe it's one of those things that works better that it sounds (at least to me).  

[Vertigo]

Quote:

I guess I did misunderstand. Maybe if I could play with it, I'd understand better what's happening. What functions/interfaces are you using to catch the keystrokes (I'm assuming SFC3 uses DInput, maybe not)? As an alternative to the ENTER method, you could set the speed to a bit below 1/4 impulse so when SFC3  increases speed, it sets it to exactly 1/4 impulse. As it sounds, I think the ENTER method is strange, but maybe it's one of those things that works better that it sounds (at least to me).  

Well, why can't you play with it? I mean, it's a free download, available from three places.  Or do you not have SFC3?

Anyway, having tried it out, the "Enter key as toggle approach" seems to work pretty well, actually.  I'm pretty happy with it, and will let it stay as the final fix.

Trying to increase it a "little less" and add a keystroke could be made to work, but it's even uglier than the Enter solution.  Also there are timing issues there I don't want to go into.  To summarize, if you give SFC3 a keystroke immediately after a mouse action, it tends to lose the keystroke.  Ugly.

If SFC3 were actually using a "instant" call like GetAsychKeyState(), I'd be out of luck.  Lucky for me, they are using a standard message queue.  If you are adept at Win32 programming, download the utility.  The source code is included.  To catch keystrokes, I'm using SetWindowsHookEx(), which allows me to intercept the message queue.  Sounds simple, but it can be very tricky in practice.  

[zaniwhoop2]

Sadly enough, I don't have SFC3 . But when I do, I'll play around with it a bit. Something I noticed while looking (breifly) though the code is that you had a function to get a screenshot. I haven't played around with DCs that much, but can you write to the fullscreen DC, or does that not work? If it does, that could open up a new realm of features...  

[Vertigo]

Quote:
Sadly enough, I don't have SFC3 . But when I do, I'll play around with it a bit. Something I noticed while looking (breifly) though the code is that you had a function to get a screenshot. I haven't played around with DCs that much, but can you write to the fullscreen DC, or does that not work? If it does, that could open up a new realm of features...  

Yes, and No.  Sure, you can write to the fullscreen DC, and that will might last about 1/60th of a second before the next frame comes along.  

I'm not sure if you have done any Direct3D programming, but the Immediate Mode rendering code will clear the entire frame buffer every frame.  Any graphics you inserted would get wiped almost instantly.  In order to get persistent graphics, you have to get yourself into the rendering pipeline.

This is really, really, REALLY hard, if not impossible to do when you just latching onto someone else?s program.  It?s not quite technically impossible, but that is some really fancy (and time consuming) reverse engineering.

Basically, I?d have to
1) intercept every D3D call (I know how to do this), use that to
2) puzzle out the basic workings of the SFC3 engine.
3) Somehow insert new rendering commands into the pipeline without breaking everything.

That ain?t no joke.  That?s full time work, the kind you could get paid $80K a year to do.

But persistent overlays could be very cool.

And is SFC3 really a good enough game to warrant this effort?  I don?t think so.  You?d be better served taking my code and porting it back to a better game, like OP.  It actually should be relatively trivial for someone who?s motivated, and anyone has my permission to try.

Come to think of it, I?ve never looked at the released public source for previous SFC games.  Is the retained 3D engine code public, too?  That would make step #2 almost easy.

You actually looked at my source code?  I?m FLATTERED!  What do you think?
 

[Vertigo]

BTW, HAS ANYONE ACTUALLY TRIED THIS UTILITY YET?  DOES IT WORK?

I wanna know...  please?  

[Tulmahk]

When I tried to use it, the log file records the following:

*********** SFC3MACRO Message Log ***********


Message Logging Level = 1.
Could not find action name.
Could not find action name.
Could not find "=" sign.
Could not find "=" sign.
Could not find throttle!  Green Color: 5AC300.
Error finding throttle.
SFC3 Macro has been stopped.
SFC3 Macro has been started.
Could not find throttle!  Green Color: 5AC300.
Error finding throttle.
SFC3 is closing.  Closing Log.


This is a very interesting utility, I sure hope the kinks can be worked out.  It is very promising.

If I may offer my layman's opinion of what is going on above, it could have something to do with different monitors having different Color Profiles (and/or the video card itself).

My setup is a GeForce2 200MX PCI with a 19" GEM Delta DC 995 monitor & an inactive S3 onboard video chip.

I hope this helps, I'd love to see this thing work.  

[zaniwhoop2]

Quote:

Quote:
Sadly enough, I don't have SFC3 . But when I do, I'll play around with it a bit. Something I noticed while looking (breifly) though the code is that you had a function to get a screenshot. I haven't played around with DCs that much, but can you write to the fullscreen DC, or does that not work? If it does, that could open up a new realm of features...  

Yes, and No.  Sure, you can write to the fullscreen DC, and that will might last about 1/60th of a second before the next frame comes along.  

I'm not sure if you have done any Direct3D programming, but the Immediate Mode rendering code will clear the entire frame buffer every frame.  Any graphics you inserted would get wiped almost instantly.  In order to get persistent graphics, you have to get yourself into the rendering pipeline.

This is really, really, REALLY hard, if not impossible to do when you just latching onto someone else?s program.  It?s not quite technically impossible, but that is some really fancy (and time consuming) reverse engineering.

Basically, I?d have to
1) intercept every D3D call (I know how to do this), use that to
2) puzzle out the basic workings of the SFC3 engine.
3) Somehow insert new rendering commands into the pipeline without breaking everything.

That ain?t no joke.  That?s full time work, the kind you could get paid $80K a year to do.

But persistent overlays could be very cool.

And is SFC3 really a good enough game to warrant this effort?  I don?t think so.  You?d be better served taking my code and porting it back to a better game, like OP.  It actually should be relatively trivial for someone who?s motivated, and anyone has my permission to try.

Come to think of it, I?ve never looked at the released public source for previous SFC games.  Is the retained 3D engine code public, too?  That would make step #2 almost easy.

You actually looked at my source code?  I?m FLATTERED!  What do you think?

Well, I actually have had some experience with Direct3D, but only DX8 and 9. Currently I have a few little programs that can read, render, optimize, and distort (with vertex and pixel shaders) SFC2 and most Armada models (many thanks to assimsoft.com for the formats), SFC3 is closer to what I'd like to work with and have experience with. All I'd need is the a pointer to the Direct3D device and I'd be set (as long as there was no switching video modes in game).

Unfortunately, there is no source code for SFC 1 or 2 (something about proprietary code I think). If you could block and execute code before the D3D scene ended, you could do a lot. Or, have your app use another instance of D3D to render to a surface, and then copy it to the DC. Although slow, it could be interesting...I need to get SFC3.  

[Vertigo]

Quote:
When I tried to use it, the log file records the following:

*********** SFC3MACRO Message Log ***********


Message Logging Level = 1.
Could not find action name.
Could not find action name.
Could not find "=" sign.
Could not find "=" sign.
Could not find throttle!  Green Color: 5AC300.
Error finding throttle.
SFC3 Macro has been stopped.
SFC3 Macro has been started.
Could not find throttle!  Green Color: 5AC300.
Error finding throttle.
SFC3 is closing.  Closing Log.


This is a very interesting utility, I sure hope the kinks can be worked out.  It is very promising.

If I may offer my layman's opinion of what is going on above, it could have something to do with different monitors having different Color Profiles (and/or the video card itself).

My setup is a GeForce2 200MX PCI with a 19" GEM Delta DC 995 monitor & an inactive S3 onboard video chip.

I hope this helps, I'd love to see this thing work.  

It does, and I half expected that problem.  I'd say there are two separate problems:

1) Sounds like there is an error in the  [Command List] section of the .INI file.  It's of no consequence since the throttle command are being found anyway.  If you want to cut'n paste that section into a post, I'll take a look at it.

2) I HOPED beyond hope that the color of the throttle bar would be constant across all systems, but it doesn't look like it will be that easy.  This is the number one reason I kept trying to get someone to test it.  It's also the reason that the color is defined in the INI file, so it can be changed, just in case.

*Tech note: My video card does 16-bit RGB in 5-6-5 format, the problem is probably that your card uses 5-5-5 format.  No big deal, I just have to find out the actual combined color value, so the utility can find the throttle.

OK, I've got alternate code that spends more effort searching for the throttle color, I'll get that polished and into the next revision.  It eats more CPU time, so I wasn't going to add it unless I had to.

Anyone else?




 

[Tulmahk]

That's another concern, does it make a differance if you're in 16 or 32 bit color mode?  I was playing in 16, but it sounds like you coded with that color depth in mind.

Still, should be worth a test.  I'll do that and report back.  

LATER...
Ok, I tested it in 32 bit color depth and same problem.

Maybe a fuzzy logic routine would help?  Instead of requiring an exact color match, match it to within 10% or so?  Surely there is some hardware-independent way to do this.

Of course, Taldren should've designed the game this way from the get-go.  There's a button for full impulse, but not one for any other speed (except 0).  And there should be power-slider presets.  Well, hindsight is 20/20 I suppose.

Good luck, I hope you get this working, it will provide a great advantage for anyone using it (if your opponent isn't).  

[Tulmahk]

As you requested, here is the entire [Command] section of the .ini file:

;------------------------------------------------------------------------------
;This is where you bind your keystrokes to the commands you want SFC3Macro to
;perform.
;
;For instructions about available keys and commands, please see Commands.txt.
;
;Format:
;(Command) = 'key', [SHIFT], [CONTROL], [ALT], [RunAlways], [PassThru], [IsExtended], [NotExtended]
;
[Command List]
UpThrottle=S
DownThrottle=A
OnOff=ENTER, RunAlways, PassThru
;ShowLog=F6, RunAlWays
;AdvancedDisplayQuery=F7, RunAlWays
 

[Vertigo]

Quote:
That's another concern, does it make a differance if you're in 16 or 32 bit color mode?  I was playing in 16, but it sounds like you coded with that color depth in mind.

Still, should be worth a test.  I'll do that and report back.  

LATER...
Ok, I tested it in 32 bit color depth and same problem.

Maybe a fuzzy logic routine would help?  Instead of requiring an exact color match, match it to within 10% or so?  Surely there is some hardware-independent way to do this.

Of course, Taldren should've designed the game this way from the get-go.  There's a button for full impulse, but not one for any other speed (except 0).  And there should be power-slider presets.  Well, hindsight is 20/20 I suppose.

Good luck, I hope you get this working, it will provide a great advantage for anyone using it (if your opponent isn't).  

I've just sent out v0.931, which has a crude matching algorithim.  I don't want to spend the CPU cycles doing anything as heavy as fuzzy logic.  I am, after all, leeching CPU cycles from an unaware program as it is.  Hopefully, this revision will fix your problems.  Let me know.

Technically, GetPixel() should be returning a device-independent 32bit RGB color, but it just doesn't seem to work that way.  So, I gotta kludge a little.

SFC3 does 32 bit color?  :O  This I didn't know, not having seen any ability in SFC.INI or the GUI config tool.  How do you do this?