| Main > Software Forum |
| Led-wiz helper app Version 2.0.86 released (UPDATED!) |
| << < (4/7) > >> |
| RandyT:
--- Quote from: Howard_Casto on June 23, 2006, 06:52:34 pm ---Yeah one of my first concerns when randy talked about the product was the copy&paste crap. I know for a fact that the clipboard is slow as hell. The clipboard converts data to clipboard format everytime you send it some... when you poll the clipboard your api call (or whatever you use) has to convert it back as well. On top of that I believe the clipboard has a built in delay of a few milliseconds. This is so teh system has time to catch up. --- End quote --- Howard, please define "slow as hell." There is literally just 25ms or so lag between dumping a command into the clipboard for the LED-Wiz and it being collected and deleted by the resident software. That's a maximum of about 40 commands per second, which isn't bad for a method that can be used by virtually any programming language, including oddball ones. You call it "crap", while others have called it a "godsend" to be able to literally start controlling the hardware from their programs within minutes of plugging it in. Buks stated a few seconds delay. I'm not sure what might be taking so long (hard drive defrag in order?), but it shouldn't be the communication method. There is a possibility that the programming language being used has some really inefficient code for communicating with the clipboard, but I haven't seen this with VB6. On the other hand, I wrote an ActiveX control that allows for more direct control by bypassing the clipboard. It should work in any programming environment that allows for these controls and it's free for the asking. The best current solution for C++ users is, of course, MikeQ's DLL.. RandyT BTW, thanks to Mahuti for another fine update! |
| mahuti:
I've also noted some slowness, but as I said, in the past I couldn't directly attribute it to my code. I'll have to retest, but I think part of the problem too (at least on my side), may have something to do with a combination of all of the following happening in short order; a. sending a command from a frontend that b. uses a batfile that c. launches my app (hmm.... maybe I should let is stay open in the background all the time) d. which then checks the commandline parameter against an ini, as well as e. reads several configuration settings and then; f. passes stuff to the clipboard which is then g. polled and executed by the led-wiz. h. my app then quits i. command is relenquished to the bat file j. mame is then launched. As you can see, there are a number of things happening in that short period. Some of which are out of my control. HOWEVER, I've been intending to spend some time doing things like; 1. reading and storing the config entries in memory after the first time they're accessed. 2. providing more internal options for skipping needless functions based on the specific use. 3. more testing of various individual functions for speed bottlenecks, cutting third party apps out of the picture to get a clearer picture of any problems . 4. setting swiftled to run in the background.... there may some slowdown due to focus issues. 5. Switching to asynchronous coding. Right now my code is running synchronously, it executes a command and waits for a response before continuing on. Those responses happen almost instantaneously, but all together probably add up. In a number of cases, I probably don't need responses before continuing on. Other than those issues, I can tell you my code's pretty clean, but it COULD use some optimization. There's a lot of functions that could be consolidated, and I'm always thinking how to streamline it. While going to sleep I usually come up with some good shortcuts. On a whole though it's good enough for me, for now, and that's the only reason I built it to begin with. Since I use this app all the time myself, you can bet on the fact that I'll continue making it better when I get the chance. |
| buks:
mahuti, I tried what you suggested and got the powermame attract mode and button lighting to work. Excellent. BUT..... I can't get "lledwiz" to work for some reason. "xledwiz" works - I've tried running the command from the dos prompt and if I start Ledwiz87 manually xledwiz definately closes it. But I can't get lledwiz to launch Ledwiz87. I've got ledwiz in c:\Program Files\ledwiz so I tried copying the ledwiz folder to c:\ but it still didn't work. Is the xledwiz parameter using the ledwizpath and ledwizversion settings in the configuration.ini ? If so then I must have them set correctly so I'm not sure what the lledwix param doesn't work. Any ideas ? Also as a side note I will do a defrag at some point and see if this speeds things up but the speed isn't really a big issue at the moment. Cheers for everything so far though ! Buks |
| mahuti:
Also, until I change it, I believe you need the whole path to your .exe....not just the path to it, but also the name of the ledwiz version you're using, like what's noted in the ini file that's distributed w/ the swiftled; ledwizpath=c:\arcade\support\ledwiz\LEDWizBeta71.exe See the exe file there at the end? YES, yes, yes, I know, I shouldn't ask for the name of the ledwiz app twice, but I did. I plan to change it, however, but in the meantime, you should change the ini file. Sorry about the confusion, but I think that'll fix it. And to anyone else that may find difficulties, feel free to fool around a few minutes to fix it, but also feel free to ask me if there's something else going on. My software's ultra hyper mega beta, so there's still a few things I need to work out. |
| buks:
whoot ! Just tried what you said and I can now get it to run from the command line. Cheers for posting so quickly. I'll now mess about with the mamewah ini files to get everything up and running then I'll post back my success or failure ! Thanks again, Buks |
| Navigation |
| Message Index |
| Next page |
| Previous page |