|
Hi everybody,
I am trying to provide recording functionality (save gameplay as video file) for my Unity WebGL game.
I can easily record video stream (via javascript plugin) as
let canvasStream = canvas.captureStream();
But I fail to record audio :frowning:
I can go with
stream = await navigator.mediaDevices.getUserMedia(constraints);
But I don’t like this method. It creates popup, interrupting the game. I’d like it to go smoothly, without interruption.
I see the WEBAudio object created on the page with WEBAudio.audioInstances, WEBAudio.audioContext, etc. But I failed to get audio stream from there.
No errors logged and no audio in my recording. Just video.
Appreciate your help and advice on how to get Audio Stream from any of these available objects:
WEBAudio
WEBAudio.audioContext
WEBAudio.audioContext.destination
WEBAudio.audioInstances[1].buffer
WEBAudio.audioInstances[1].getNumberOfChannels()
WEBAudio.audioInstances[2].gain
Thank you.
|
|
|
|
|
using java scipt how to scroll images
|
|
|
|
|
You're going to have to go into a LOT more detail than that.
|
|
|
|
|
Simplest example:
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8" />
<title></title>
</head>
<body>
<div style="width:1200px;height:1200px;overflow:scroll;">
<img src="file_found_in_same_folder_as_this_html_snippet.jpg" />
</div>
</body>
</html>
And now for a better question: Why can't I point to a file that is not in the same folder as the HTML file referencing the image I want to display?
[EDIT]
... by hardcoding it in the body as a string, that is, like here, but providing a full path and drive location ..?
[/EDIT]
modified 2-Sep-24 17:19pm.
|
|
|
|
|
RedDk wrote: a full path and drive location
If you're loading an HTML file from your local disk, then you should be able to reference images from the same disk using a file path. (Although a File URI[^] would probably be safer.)
If you're loading HTML from a website, then you cannot reference files on "your" local disk by providing a path and drive location. That path would refer to a location on the end-user's computer, which may not exist, or probably wouldn't contain the expected image. But even if it did, allowing websites to read the contents of their users' local file system would be a security risk.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Lets see, how shall I word this ...
It sounds as if I do indeed have a problem loading an image using an HTML file that I saved to my hardrive when, in fact, what I meant to say is that I would obviously use a script. And to show where the file is so that a function could get it for me I'd use "imageURL" and "push" it. But being in a rhetorical holiday mood I was being facetious and using this fast-as-all-get-out < img src= /> tag in order to make my sarcastic point.
Why answer? Because using < img src="file:///C:/Users/Member_13108495/images/pianoGrande.jpg" /> loads only a broken page icon WHEN the HTML is using an extant path. The real point is that, in my understanding of it ... for purely security reasons, as you state, shuffling through the contents of a hardrive using a webbrowser is faux pas (even though Firefox doesn't "seem to have any problems with that" (quoting some nerd on SO yesterday)).
The only way one could use < img src= /> is what I said in the displayed example I provided; the image has to be in the folder where the .html resides.
modified 3-Sep-24 15:02pm.
|
|
|
|
|
Do any of you have experience with something like this?
I spent most of yesterday experimenting. I originally designed my project to run on a laptop, or desktop computer with a keyboard and mouse. I omitted touchscreen functionality on the website up until recently. I became curious about an idea, and I had to see if it was possible and practical for implementation.
Is it possible to convert touchscreen interaction events (e.g. 'touchstart', 'touchend', 'touchmove', 'touchcancel') to automatically dispatch the corresponding synthetic mouse events? For example, would it be possible to touch the screen, move your finger, and make it behave as a mousemove event? It might be. So, I had to find out.
You'd think there would be a standardized way to accomplish this sort of thing. As more websites are accessed through touchscreen tablets, developers who didn't have a need for touchscreen functionality before must now implement it, or risk being left behind in the stone age.
I spent a few hours digging around to see how it could be done. I didn't find much at all, and neither did I see any sort of standardized way to map touch events to mouse events. I did find a simple set of methods that are claimed to work, so I tried them out. It was crude and inadequate, but I found proof of concept that it's possible.
Below are the two sample methods that I used for reference. The source URL is also included.
JavaScript mapping touch events to mouse events[^]
function touchHandler(event)
{
var touches = event.changedTouches,
first = touches[0],
type = "";
switch(event.type)
{
case "touchstart": type = "mousedown"; break;
case "touchmove": type = "mousemove"; break;
case "touchend": type = "mouseup"; break;
default: return;
}
var simulatedEvent = document.createEvent("MouseEvent");
simulatedEvent.initMouseEvent(type, true, true, window, 1,
first.screenX, first.screenY,
first.clientX, first.clientY, false,
false, false, false, 0, null);
first.target.dispatchEvent(simulatedEvent);
event.preventDefault();
}
function init()
{
document.addEventListener("touchstart", touchHandler, true);
document.addEventListener("touchmove", touchHandler, true);
document.addEventListener("touchend", touchHandler, true);
document.addEventListener("touchcancel", touchHandler, true);
}These two methods serve as basic examples to illustrate how the event mapping can be done. It's impractical to put them to use, but it conveys the concept well. As for developing this feature in a real-life scenario, it can be done, but only with a vast amount of effort, a lot of complex code, and a lot of time to spare.
|
|
|
|
|
I'm not answering crap until you start recognizing my replies with at least a like. So here's the short answer, you're going about this the wrong way and over complicating it. Those events should be a proxy for the real handler that it's a user defined routine. Why? Two reasons:
1) You don't have to do this.
2) You can manually call the user defined handlers if you need to automate functionality. Say, you're trying to replay a user's interaction with the website.
You're welcome.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I'm not answering crap until you start recognizing my replies with at least a like.
When did this site turn in to StackOverflow? 
If you don't want to answer the question, then don't answer. Don't reply just to berate the user for not "liking" your previous replies.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Leave me the hell alone, Richard. Nobody has time for your childish nonsense. Go be hateful to someone else.
Jeremy Falcon
|
|
|
|
|
Mate, this seems an odd response, as does the demand for "likes".
Everything OK?
cheers
Chris Maunder
|
|
|
|
|
The jest should've been obvious Chris. I provided an answer while saying I wasn't gonna answer. And the only reason Richard did what he did was from a carry over from something the other day.
Oddly enough, it seems Steve (the person it was directed towards) was the only one that got it.
Jeremy Falcon
|
|
|
|
|
That wooshing sound is the sound of this all going over my head.
I'm going to grab another beer and see if that helps 
cheers
Chris Maunder
|
|
|
|
|
 Cheers buddy. ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I'm not answering crap until you start recognizing my replies with at least a like.
LOL. I'm sorry about that.
Jeremy Falcon wrote: You can manually call the user defined handlers
I tried adding touchstart, touchmove, and touchstart at the window level, the document level, body element level, web-window level, and it's too messy. Performance was poor. I have thousands of event handlers, both inline event listeners and added event listeners using the "element.addEventListener" method. Going through each one and adding their corresponding touch event handlers would create a trainwreck of a hackjob; a complete dumpster fire of code. Every idea I have tried, or considered trying doesn't work. Except for one.Jeremy Falcon wrote: 1) You don't have to do this.
It's actually done! I finished it almost an hour ago.
It was as difficult as I had thought. It took 3+ days and about 25 hours in total. 33% was studying, another 33% was experimenting, and I spent 33% of the time testing. It works better than I had ever imagined. 
I told you it was going to take a lot of code. Here it is as of now:
https://chromosphere.com/chromosphere/scripts/js/ui/events/ui_touch_functions_d_f.js[^]
|
|
|
|
|
Steve Raw wrote: I tried adding touchstart, touchmove, and touchstart at the window level, the document level, body element level, web-window level, and it's too messy.
By proxy I don't mean necessarily adding new events. But, for the events you do handle have them call another function that's the real handler. That way, more than one event can be used for the same handler. It's a lot less messy than trying to map event A to event B.
Steve Raw wrote: Performance was poor. I have thousands of event handlers, both inline event listeners and added event listeners using the "element.addEventListener" method. Going through each one and adding their corresponding touch event handlers would create a trainwreck of a hackjob; a complete dumpster fire of code. Every idea I have tried, or considered trying doesn't work.
Well, first things first... you need to remove those thousands of event handlers. Bubbling and capturing (trickling) are plenty enough to not need 90% of those I bet. Not sure if you read into bubbling and capturing, but here's a quick summary. In short, bubbling goes up and capturing goes down.
Check out the docs on addEventListener. There's a useCapture parameter. The default bubbles but you can change it to capturing mode via that parameter. Suffice it to say though, events will always propagate (unless canceled in the handler), and that's a good thing as you'll need less of them.
Assuming it's a top level event, bubbling is preferred. If it's a very specific element then capturing may be preferred. But, either way you go, the important thing to do remember is you don't need events on every element. As you discovered it's gonna bring your site to a crawl.
Steve Raw wrote: It's actually done! I finished it almost an hour ago.
Nice
Steve Raw wrote: It was as difficult as I had thought. It took 3+ days and about 25 hours in total. 33% was studying, another 33% was experimenting, and I spent 33% of the time testing. It works better than I had ever imagined.
Nice. Isn't web development fun?
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: By proxy I don't mean necessarily adding new events. But, for the events you do handle have them call another function that's the real handler. That way, more than one event can be used for the same handler.
It's so difficult to have a discussion that is so technical. To clarify what you're saying here is that for all mouse-related event listeners, whether inline, or assigned by 'element.addEventListener', I include a function call to the event handler function that handles a touch event?
I have a few mouse-related event listeners assigned to the window element. I attempted to modify those window event listeners to include a corresponding touch event hander function call. I gave that a try several times in various ways. I quickly realized that using such an approach couldn't work. So, I tried using separate event listeners that handle touch events corresponding to the element's mouse event handler. In theory, that could work, but attempting to implement that would be a huge undertaking, it would be very difficult to maintain and modify. I realized that using such an approach would be like throwing rocks at a hornets nest.
I feel very confident using the approach I eventually decided upon after a lot of experimentation and testing. It adheres to standards, it's efficient and uses few resources, it's no more complex than it needs to be. The code is all located in a single location which makes it easy to modify and maintain. I think it's about as ideal as it can possibly be.
I'm planning on adding documentation and comments to the script today. It'll be much easier for others to understand what I'm doing once I have that completed. If you're interested, I can send you a link to view the documented code.
Jeremy Falcon wrote: Not sure if you read into bubbling and capturing, but here's a quick summary. In short, bubbling goes up and capturing goes down.
Yep, I sure did. I studied for hours and gained a wealth of knowledge and understanding far beyond what I had before.
Jeremy Falcon wrote: Assuming it's a top level event, bubbling is preferred. If it's a very specific element then capturing may be preferred.
Yes, I very much agree with that.
Jeremy Falcon wrote: Nice. Isn't web development fun?
Yes, it certainly can be.
|
|
|
|
|
Steve Raw wrote: It's so difficult to have a discussion that is so technical. To clarify what you're saying here is that for all mouse-related event listeners, whether inline, or assigned by 'element.addEventListener', I include a function call to the event handler function that handles a touch event?
Maybe some code will help. A fiddle...
Using events as a proxy.
Regardless of whether it's a touch event, click event, pointer event, etc. they can all call dude(). There's no need to add an extra layer of mapping to any of it. This has the benefit of allow the programmer to automate events without having to worry about going through the event cycle, but your real function is all that needs to be called. And it's waaaaay less mentally confusing.
Steve Raw wrote: I have a few mouse-related event listeners assigned to the window element. I attempted to modify those window event listeners to include a corresponding touch event hander function call. I gave that a try several times in various ways. I quickly realized that using such an approach couldn't work. So, I tried using separate event listeners that handle touch events corresponding to the element's mouse event handler. In theory, that could work, but attempting to implement that would be a huge undertaking, it would be very difficult to maintain and modify. I realized that using such an approach would be like throwing rocks at a hornets nest.
Guess it's my turn not to follow what's being said.
Just gonna assume we're talking about a click event on window... which should be discouraged. Unless that's like the only event you have and you plan on doing the mapping accordingly. But, if there's one on window plus 1,000 others then that's a different story.
But, the mapping touch basically between the same between mouse, touch, and pointer. The above fiddle also has a touch example. You can use Chrome Dev Tools to simulate the touch for testing it out.
Hope I'm on the right track with understanding the ask.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Maybe some code will help. A fiddle...
Using events as a proxy.
That's interesting. I've never used the bind method, let alone inside an addEventListener method.
If I were to use that approach, then how would I set the event parameters if that bind method is located inside a click event listener? Let's say that I needed to run a passive event, such as mousemove within a click event listener. Click events are non-passive, yet mousemove events are passive. Passive events can't be canceled (without some effort, anyway), yet click events are cancelable. What if the click event is set to bubble, and the mousemove event needs to propagate as capture? I don't know how that could be done. Without being able to set those custom parameters for events, and event listeners, nothing would work. Perhaps if I added the parameters into the method as arguments, that might be possible. The solution I have now works great. It's as simple as it could possibly be. It's efficient, and every element in the DOM is automatically enabled for use with touch interaction. To make that possible, I only had to write a single subroutine. I'd say it only took a couple of minutes to write up and I'm all done. It seems to be an ideal solution in every way. If there's a better way to go about it, then I'm open to ideas.
|
|
|
|
|
Let me tackle this in the morning. I must retire for my beauty sleep.
I will say though, that bind, call, and apply are totally worth reading up on. Especially if you need a pass around a new this or in the case of that code example pass params where none were expected to be passed.
Jeremy Falcon
|
|
|
|
|
|
You're right, I'd have to be really bored. 
Jeremy Falcon
|
|
|
|
|
Steve Raw wrote: If I were to use that approach, then how would I set the event parameters if that bind method is located inside a click event listener? Let's say that I needed to run a passive event, such as mousemove within a click event listener
It's the same way. I should say though, you seem to be stuck on this idea of calling one event from another. That's not the way to go, regardless if it's passive or active.
Something like bind works on any function though, but that's not the important bit. I don't recommend doing this at all, but to answer the question (this time without bind just for illustration): Fiddle.
The key takeaway should be using the proxy approach.
Steve Raw wrote: What if the click event is set to bubble, and the mousemove event needs to propagate as capture?
They are two independent events. Bubbling or canceling one won't affect the other. You may need to take a step back at your code and the way you've done things, take a breather, and look at the big picture man. This is like crossing streams in Ghostbusters. Something is gonna blow up.
Steve Raw wrote: Without being able to set those custom parameters for events, and event listeners, nothing would work.
If it's a proxy, you can use any params you want for the real handler. The first fiddle showed that, with only passing the id as a single param.
Steve Raw wrote: It's efficient, and every element in the DOM is automatically enabled for use with touch interaction.
You mentioned 1,000 event listeners, trust me... there's room for improvement man. I promise.
Steve Raw wrote: and every element in the DOM is automatically enabled for use with touch interaction
That's just it, if every element has a listener attached to it, then not only will your site be slow but you've made it extremely difficult for your users to user the site... they can click the wrong thing. Just because you can do something, doesn't mean you should. I promise.
Steve Raw wrote: To make that possible, I only had to write a single subroutine.
If your 1,000 events are calling the same routine, that's using a proxy.
Jeremy Falcon
|
|
|
|
|
I haven't had the chance to read up on bind, call, and apply yet. I'll see if I can make use of them as you suggest. I've got a dentist's appointment. I've got 8 minutes to get there. I'll write more later.
|
|
|
|
|
Good luck, buddy.
Jeremy Falcon
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
