Working with
ESP8266 Microcontroller
RobotDyn AC Dimmer
The dimming works but there's occasional flickering.
Trying to trouble-shoot the cause / find a solution.
The code below is the core dimming loop.
Even stripped down strictly that code, I'm still getting the same degree of flickering.
Possible causes:
Responsiveness / occasional hiccups on in the ESP8266?
Responsiveness of the AC Dimmer?
Algorithm?
Something else?
Arduino IDE / C++
void loop(){
eTime=micros()-cTime;
if(digitalRead(ZcpPin)==HIGH){
digitalWrite(PwrPin, LOW);
cTime=micros();
}else if(eTime > Delay){
digitalWrite(PwrPin, HIGH);
}
}
Related
I've encountered strange behavior when using AS3's TouchEvents to handle multi-touch. The touch lags considerably in certain situations, but Flash's frame rate isn't affected. It's as though the touches are getting buffered and the events just aren't dispatched until several seconds after the touch.
I've uploaded a demonstration here: https://youtu.be/omkCDqljfio
I've only managed to reproduce this touch lag in the ActiveX version of Flash Player, but I've reproduced it in both Windows 10 and Windows 7. So what I have here is a C# application that's hosting my AS3 test suite, but it can also be observed if the swf is viewed in Internet Explorer.
Since my application already involves hosting the SWF in a WPF window, I've been attempting to create a solution where touch is received in C# and then communicated to the AS3. It would work perfectly but it seems my WPF window isn't receiving touch frames when the touch is on a WindowsFormsHost. So there's another problem that I have to solve.
FlashDevelop project: https://drive.google.com/file/d/0BxC2eCzurT9rd0gzSGc4TUdQLTQ/view
Visual Studio solution: https://drive.google.com/file/d/0BxC2eCzurT9rUThmRHBKWHZmbzA/view
AS3 touch events:
Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
stage.addEventListener(TouchEvent.TOUCH_BEGIN, stage_touchBegin);
stage.addEventListener(TouchEvent.TOUCH_MOVE, stage_touchMove);
stage.addEventListener(TouchEvent.TOUCH_END, stage_touchEnd);
Creating the display objects that contribute to the lag, presumably because of the touch event capture phases:
for (var i:int = 0; i < 500; i++)
{
Dotter.createBGDot(_bgLayer, _shapesOn ? Shape : Sprite);
}
...
static public function createBGDot(bgLayer:Sprite, dotClass:Class):void
{
var dot:* = new dotClass();
var color:Color = new Color();
color.brightness = Math.random();
dot.graphics.beginFill(color.color);
dot.graphics.drawCircle(0, 0, Math.random() * 400 + 40);
dot.x = Math.random() * bgLayer.stage.stageWidth;
dot.y = Math.random() * bgLayer.stage.stageHeight;
bgLayer.addChild(dot);
}
I know this is sort of an unusual situation, but I appreciate any advice about how to resolve these issues.
Now that I've used Adobe Scout I think it is a rendering issue after all. The frame rate still shows 30fps because the processing time just barely manages to hit the 30fps mark. Lowering the frame rate fixes the problem.
It is still strange that the touch events would have such a long delay when the frame rate is just barely falling short, though.
I am developing an HTML5 game and using Web Audio API for sounds. I am having an issue in which sounds start slowing down as game progress and game also starts feeling jerks which i guess is due to java-script GC doing memory cleanup.There are two types of sound i am playing in the game:
1) Background sound which continuously loop
2) Jump sound, hit sound etc occurs due to some event in the game which occurs very frequently. For example: firing multiple bullets from gun.
Not sure what i am doing wrong, please help. Please refer below code
function play(){
this.startTime = this.actx.currentTime;
this.soundNode = this.actx.createBufferSource();
this.soundNode.buffer = this.buffer;
this.soundNode.connect(this.volumeNode);
//If there's no reverb, bypass the convolverNode
if (this.reverb === false) {
this.volumeNode.connect(this.panNode);
}
//If there is reverb, connect the `convolverNode` and apply
//the impulse response
else {
this.volumeNode.connect(this.convolverNode);
this.convolverNode.connect(this.panNode);
this.convolverNode.buffer = this.reverbImpulse;
}
this.panNode.connect(this.actx.destination);
this.soundNode.loop = this.loop;
this.soundNode.playbackRate.value = this.playbackRate;
this.soundNode.start(
this.startTime,
this.startOffset % this.buffer.duration
);
this.playing = true;
}
There's nothing in your code that stands out as specifically memory intensive, apart from the use of the convolver (which can be really expensive and cause bad performance on lower-end devices). I'd try this though:
Try disabling your audio (don't run any of the audio code, don't just mute it). Do you still have the janks in the game visuals? If so, it's not your audio that's the culprit.
Try running your audio but always run it without the convolver. If the jank disappears, the convolver is your culprit. The only thing I could think of there is to try setting the convolver buffer only once and not every call to play().
Try running different profiles in Chrome Dev Tools (JS, Memory, Paints etc.) and try to figure out where the janks come from. https://developer.chrome.com/devtools/docs/cpu-profiling
Good luck!
I'm having trouble with smooth character movement for a 2d game I'm making.
It looks like the character is double when moving. Kinda like this (its just one pixel though):
( ()
/ /{}\ ==>
| ||
The game runs on a solid 60 FPS and my monitor is not the problem (I have tested this on several monitors).
I'm using starling at the moment, but I've had this since I first stared making games (using openGL). I was hoping someone could tell me what I'm missing. Here is my code:
private var _x:Number = 20, _y:Number;
public function update(delta:Number):void
{
if(gravity){
_y += delta * 120;
}
if(_y + skin.image.height > game.stage.stageHeight){
_y = game.stage.stageHeight - skin.image.height;
gravity = false;
}
if(right && left){
skin.playAnimation("none");
}else if(left){
_x -= delta * speed;
skin.playAnimation("left");
}else if(right){
_x += delta * speed;
skin.playAnimation("right");
}
//update skin
skin.update(delta, Math.round(_x), Math.round(_y));
}
skin update method:
public function update(delta:Number, x:int, y:int):void
{
image.x = x;
image.y = y;
if(currentAnimation){//this is texture switching (I tried without, still happens)
currentAnimation.update(delta);
}else{
image.texture = textures[4];
}
}
Here is the game.
Based on my own experimentation, as well as all the data in the comments, I think the ghosting is dependent on the frame rate and the computer itself.
First, and most importantly, when I tried the game in the link, it had the described ghosting at the full frame rate of 60. However, when I tried to film a screencast for further analysis, that occupied some CPU, dropping the frame rate down to around 35 or 40. At that point, the ghosting stopped.
Second, because different people are reporting different experiences with the described ghosting, I'd also think that it has a little to do with the individual computers themselves, probably rooted in their available memory and CPU, though that's just a theory, as I don't have any benchmarks to go off of.
Third, I think part of it is also rooted in neuroscience, as different people perceive animation differently.
People always talk about wanting a higher frame rate, but honestly, to fix this, I would recommend LOWERING the frame rate. Flash Professional CS6 has a default frame rate of 24 FPS, and I have never experienced a ghosting problem to my memory. It is worth mentioning that Flash animators usually work in 24 FPS.
Then again, appearance-wise, it really isn't a major deal. It is one of those graphics flaws that people tend to ignore, similar to the motion blur you get on 24 FPS films, until they changed it to 48.
It seems to be something that all games have (I actually never noticed it on some games where I do notice it now) and I just have to live with it. Its not my hardware, its not my monitor. I tried it on a lot of computers (good to bad hardware) and it looks the same on all computers. It looks worse on the computers with bad hardware, but there is not a huge difference.
Code that had been working is suddenly not.
Printing works fine in all browsers even Chrome on MAC( Chrome v: 21.0.1180.57 > which reports up to date. )
A movieclip is being added via AddPage. Then printed.
Expected behavior is that the movieclip is printed as it is in other browsers. Instead the SWF itself is being printed even when bypassing Chrome's print preview and using the standard one.
Any ideas? The generic code is below. The code isn't as important. This has worked for several thousands of users for a few months. Chrome issue popped up yesterday.
if(myPrintJob.start()) {
if (myPrintJob.addPage(containerElement, rect, options)){
pageCount++;
}
Provider.testProvider("service.userPrinted", dataStr, userPrintedResult, onFault);
if (pageCount > 0) {
myPrintJob.send();
}
}
Following Up:
Other users reported the same bug. It has been flagged as "started" by Google Engineers.
One claims he has a fix.
http://code.google.com/p/chromium/issues/detail?id=141082
See comment below:
Comment 11 by viettrun...#chromium.org, Aug 24 (2 days ago)
Probably, the people who are using the AS3 PrintJob API and are seeing
this problem are forgetting to call .send() once their done. (This
confuses Pepper Flash into doing a "normal" print, rather than
forcibly completing the still-open PrintJob and printing that.)
Nonetheless, I have a change to make it work....
Status: Started
Does Flex 3 support threading? If so, are there any examples or links I could look at?
Somewhere, in Adobe, Flash Player does support multithreading... http://www.bytearray.org/?p=3007. It's just not publicly available yet.
Other than that, see Multithreading or green threading in actionscript? There are also a few articles on the internet about using Pixel Bender's multithreading for data processing.
ActionScript 3 is single-threaded.
What you can do is cut the work in slices small enough that the responsiveness is not too affected. For example:
private var _long_process_work_object:LongProcessWorkClass;
private var _long_process_timer:Timer;
private function startSomeLongAndIntensiveWork():void
{
_long_process_work_object = new LongProcessWorkClass();
_long_process_timer = new Timer(10);
_long_process_timer.addEventListener("timer", longProcessTimerHandler);
_long_process_timer.start();
}
private function longProcessTimerHandler(event:TimerEvent):void
{
_long_process_timer.stop();
// do the next slice of work:
// you'll want to calibrate how much work a slice contains to maximize
// performance while not affecting responsiveness excessively
_long_process_work_object.doSomeOfTheWork();
if (!_long_process_work_object.Done) {
// long process is not done, start timer again
_long_process_timer.start();
return;
}
// long process work is done, do whatever comes after
}
As stated by Alex here:
Actionscript is single-threaded, if you spend lots of time doing heavy
computation, the UI cannot be updated while you’re doing that
computation so your application appears stuck or effects don’t run
smoothly.
Similarly, there is no yielding or blocking in Actionscript either. If
the next line of code is supposed to run, you cannot prevent the next
line of code from running. That means that when you call Alert.show(),
the next line of code following that runs right away.
In many other runtimes, the Alert window has to be closed before the
next line of code continues. Threading may be a feature of
Actionscript some day, but until then, you have to live with the fact
that there is no such thing right now.
Flex 3 is based on ActionScript 3. ActionScript 3 does not provide support for multithreading ( you cannot write code aimed for multi-thread execution ).
A compiled flex application runs on the Flash Player platform. Adobe Flash Player 11.4 and up added support for multithreading.