Main > Software Forum
Led-wiz helper app Version 2.0.86 released (UPDATED!)
<< < (5/7) > >>
Howard_Casto:

--- Quote from: RandyT on June 24, 2006, 01:11:17 am ---
--- 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.

--- End quote ---

Well 40 commands a second, in my book is slow as hell.  I don't understand the hostility, the clipboard is an inefficient means to control a hardware device, that is exactly why your device is the only one in the history of computers to use it.  I didn't say it didn't have it's place, but it shouldn't be relied on to use for time-sensitive operations.  The clipboard also gets bogged down if you send it a lot of commands in rapid successsion, it buffers them you know and because of that and the delay requried to actually put data in the clipboard it sometimes gets overwhealmed and just totally craps out.  

Granted you are right... if you are just sending a sole command once, it shouldn't be a big deal, but if you are sending multiple commands in rapid succession it sure is.  I never suggested that the delay was soley because of the clipboard bottleneck, but I do agree with him in that it is a bottleneck and he should start using a more reliable method of sending the data.  

Also there is the problem with windows.  The clipboard isn't mean to be time efficient, so if you are doing nothing else the clipboard is fairly fast but if stuff is running in the background, or memory is tight or what have you then windows might take it's time about giving up the data... believe me, I've seen it.  
buks:
mahuti,

Apologies for mentioning the speed earlier.... looks like Howard and Randy are going outside for fisticuffs :) (please, that was intended as a joke and not an insult - call it English humour).

Anyway.....

mamewah starts ledwiz87 and runs mamewah.lwa - check !
shut down ledwiz87 before starting powermame - check !
powermame starts its own attract mode - check !
powermame lights buttons in use - check !
powermame restarts ledwiz87 and mamewah.lwa on exit - check !

Theres about a 5-10 second delay when the mamewah app re-displays after a game. The menu displays but it seems frozen. Then the lights kick in and control is back. I've not run the defrag yet but I will in a minute as Argentina v Mexico has just gone into extra time so I'll go watch that. I'll repost whether this has made a difference to speed.

Excellent app ! I know I've said that before but I just wanted to reitterate it just in case anyone though "what do you expect for a beta ! Its all take take take with you !".

Buks
buks:
defragged c: and e: even though they said they didn't need it. Hasn't made a difference to speed.

Heres the relevent bits from ini files just in case I'm doing something stoopid :

mamewah.ini

### External Application Settings ###
startup_app_commandlines                  C:\SetLedWiz\SwiftLed\swiftled.exe  lledwiz;C:\SetLedWiz\SwiftLed\swiftled.exe mamewah.lwa
exit_app_commandlines                     C:\SetLedWiz\SwiftLed\swiftled.exe xledwiz
exit_and_run_app_commandlines             

pmame.ini

### Execution Settings ###
pre_emulator_app_commandlines             C:\Program Files\CPViewer\cpviewer.exe [name] -clone [cloneof];C:\histview\histview.exe -r=[name] -p=12 -s=0 -n -e=49;C:\SetLedWiz\SwiftLed\swiftled.exe xledwiz
emulator_commandline                      E:\PowerMAME_105.0.1b\powermame.exe [name]{autodosbox}{nosafelaunch}
post_emulator_app_commandlines            C:\SetLedWiz\SwiftLed\swiftled.exe  lledwiz;C:\SetLedWiz\SwiftLed\swiftled.exe mamewah.lwa
general_app_commandlines        

Anyone notice anything wrong ?

Buks         
RandyT:

--- Quote from: Howard_Casto on June 24, 2006, 04:34:46 pm ---Well 40 commands a second, in my book is slow as hell.  I don't understand the hostility, the clipboard is an inefficient means to control a hardware device, that is exactly why your device is the only one in the history of computers to use it.  I didn't say it didn't have it's place, but it shouldn't be relied on to use for time-sensitive operations.

--- End quote ---

It was a means to an end.  A way to give anyone a quick means of controlling the device, even from notepad!

Nobody said it was the best way to control a piece of hardware, nor is it the only way to control the LED-Wiz.  But if you don't program in VB (or other language compatible with an ActiveX OCX) or C++ you would be out in the cold.  Not so with this option.


--- Quote ---The clipboard also gets bogged down if you send it a lot of commands in rapid successsion, it buffers them you know and because of that and the delay requried to actually put data in the clipboard it sometimes gets overwhealmed and just totally craps out. 

--- End quote ---

Some languages allow a user defined event and that can be made to check if  the clipboard has changed / been cleared and trigger the next command.  It's pretty simple and happens quite transparently once it's been set up.  You don't just "dump data" all willy-nilly.  If one did, I would expect them to have problems as well.


--- Quote ---Granted you are right... if you are just sending a sole command once, it shouldn't be a big deal, but if you are sending multiple commands in rapid succession it sure is.  I never suggested that the delay was soley because of the clipboard bottleneck, but I do agree with him in that it is a bottleneck and he should start using a more reliable method of sending the data. 

--- End quote ---

The clipboard approach was designed to provide non-timing sensitive control over a broad language base.  Nothing more.  The resident software doesn't use the clipboard to play back the animation files, only to get the command telling it to do so.

If one were to write code to playback the animations (requiring fast access to the hardware) then obviously this wouldn't be the preferred approach.  But to light up some buttons or tell the resident software to start playback, there's nothing wrong with this approach at all.

RandyT
Grasshopper:

--- Quote from: RandyT on June 24, 2006, 06:27:38 pm ---The clipboard approach was designed to provide non-timing sensitive control over a broad language base.  Nothing more.

--- End quote ---

Have you considered designing the LedWiz so that it emulates a USB mass storage device?

http://forum.arcadecontrols.com/index.php?topic=53795.msg527407#msg527407
Navigation
Message Index
Next page
Previous page

Go to full version