I'm dealing with an audio anomalie. I have audio that is mastered quite loud, yet on some systems, it is too quiet. Boosting the audio file anymore causes clipping.
It would be fine, except for the fact that, in my project, a lot of other sounds are in use as well. Lowering the volume of everything to match this would make some stuff impossible to hear. And again, this doesn't happen on all computers, only some.
To compensate, can I boost audio in code? The SoundChannel I'm using is already at 1.0 volume (full), and I know I can't use that property to boost it further. Is there any way to raise the audio further in code?
(I'm using Flash Professional CS5.5, Adobe AIR 3, and ActionScript 3)
After some time, I've concluded that it is apparently not possible to boost sound volume above 1 (that is, to amplify) using Flash's API. While you can set SoundTransform to a number greater than 1, it will coerce to 1 nevertheless.
If anyone has information to the contrary, you are welcome to post the answer and I'll change which answer I've accepted if you solve the problem.
You are correct. Sounds cannot be played at a volume above 1 (100%). However -- You can play two identical sounds simultaneously on different channels. This would effectively give you an audio boost above 1. But depending on the nature of the sound you may get some distortions from synchronization. If you're talking about a sound-effect without a lot of discernable Attack, you may get away with it. If you're talking about speech or percussive sound, your mileage may vary.
Related
I think about writing a H264 encoder / decoder from scratch to be able to integrate the tech into a composite product. The first implementation would be written in Java.
I am used to implement scientific papers and such so I should at least bring in the basic math understanding.
What would be the best start and what should I focus on. I know that basically H264 is a mix of existing techniques.
What is are the most important things to implement?
Any idea about how much hours of work the first useful version will take.
The main objective is very fast while maintaining good compression.
How many hours? Maybe 20,000. The decoder specification alone is over 750 page document. And the decoder is the easy part.
After consideration :), I now will still use my own solution based on PNG and JPEG while not using motion vectors. I simply wrote a small solution I can compress parts of the image based on those and use filters to degrade the quality by applying sorts of blur or reduce the number of colors or even resolution. Works well enough for now.
If I need better quality I start looking at VP9 in more detail.
The only draw back is no hardware encoding support which might force me / us to look into H264 again.
Currently I can deliver 60+ frames for every days situation and scale down to 15 frames per second for video content along with bad quality but it is good enough to grab a security cam screen and see if something is wrong.
For the past year I have been working on an isometric city builder. So far I have not used any framework apart from a loose PureMVC clone.
I have heard of Starling but only recently have I played with it.
From my research, the performance boost is fenomenal, but this forces me to manage my resource a lot tighter.
At the moment, I am exporting building animations one building at a time, in ~16 frames/pngs. These are cropped, resized and exported in Photoshop by a script and then imported in Flash, then exported as a swf, to be loaded / preloaded / postloaded on demand.
The frames are way too big to make a spritesheet with them, per building. I believe its called an atlas.
These pngs are then blited between lock() and unlock(). After the buildings + actors walking around are sorted, that is.
I am unsure if just using starling.Movieclip for the buildings, where instead of loading the pngs, I would build a MovieClip symbol with its frames. So bliting wouldn't even be necessary. Unless adding bliting on top of Starling would improve performance even more. That would allow fatter features such as particles effects, maybe some lighting.
Google isn't offering me a strait answer, thus I am asking here.
Google isn't offering a straight answer because there isn't such. It depends very very much on what you've done, how much knowledge you've got and what are your goals.
Using Starling gives benefits as well as drawbacks. Your idea of resources will change totally. If you really have enormous amount of assets, then putting them into GPU will be really slow process. You must start from there - learn what Starling does, how resources are managed with it and what you need to change in order to make the transition between the two.
If this is not that hard and time consuming task, you will have some performance optimization. BUT again it depends on your current code. Your current code is really important in this situation as if it's perfectly optimized your gain won't be that much (but commonly would still be).
If you need to switch between graphics regularly or you need to have dynamic assets (as images for example) you must keep in mind that uploading to GPU is the slowest part when talking about Starling and Stage3D.
So again, there is not a straight answer. You must think of GPU memory and limit, GPU upload time, as well as assets management. You also need to think of the way your code is built and if you are going to have any impact if you make the switch (if your code heavily depends on the MovieClip like structure, with all that frames and things) - it will be hard for you. One of the toughest things I fought with Stage3D was the UI implementation - there is almost only Feathers UI which will take you a few weeks to get along with.
On the other hand, Starling performs pretty well, especially on mobile devices. I was able to maintain a stable 45fps on a heavy UI app with a lot of dynamic loading content and multiple screens on an old iPhone 4S, which I find great. Latest mobile devices top at 60fps.
It's up to you to decide, but I'll advise you to have some experimental long-lasting project to test with, and then start applying this approach to your regular projects. I've done the dive to use it in a regular very tightened deadline project, and it was a nightmare. Everything worked out great, but I thought I would have a heart attack - the switch is not that easy :)
I would suggest using DMT for rasterizing your vector assets into Straling sprites at runtime, and it'll also keep your DisplayTree! meaning that you'll still have the parent/child relations that you had in your Flash Assets.
DMT will not duplicate assets, and will rasterize the vectors into texture atlases only one time (Cache is saved)
you can find it here: https://github.com/XTDStudios/DMT
I am working on a Flash Video player and am implementing the ability to start a video at x time within the span of an FLV (served from FMS). I am able to start it x seconds into a stream without any issue using
netStream.play(source, startTime);
but as far as I can tell, it only supports seconds. I am looking to be able to give a start time (or even a seek time if that is supported) in milliseconds, or really anything more precise than whole seconds.
Anyone know of any way to achieve this even by monkey patching the fl classes?
Thanks,
Doug
Well the seek will allow you to seek by a number of frames, but the spec says that it only seeks to the closes I-Frame in the FLV. That will become a problem with any method you use, because the I-Frames are the only ones that actually contain the whole picture frame (here's the gist of that).
I am making a flash game. And I want to know how big is too big for a swf file. Also, Ive been looking at my swf file and right now its at 38.2k. Is the swf file that gets created during debugging, is this the correct size for the file that will eventually be placed on the web.
thanks
Kilobytes is small stuff.
Anything less than a couple of megabytes is fine - once you get above that you might start worrying about loading times and keeping users interested during the preloader, but most portals accept files up to 10MB or so.
Yes, the file is the same. A game of 38.2 kb is pretty small, if you go on Flash game sites they regularly run in the multiple of megabytes.
The SWF is slightly smaller in release mode. The size difference is essentially nothing.
As for a guideline size, this depends on who you are expecting to play your game.
if you want your game to reach a very wide audience keep it as small as you possibly can.
a game without any heavy animation , embedded assets like png files or sound will usually be small.
a good discussion regarding Optimal swf size for flash games here at
http://board.flashkit.com/board/showthread.php?t=788271
The difference between debug and release builds is, according to my experience, some 30-40% in file size (debug version being bigger, of course), which is not insignificant.
Anyways, I think you're safe to assume that anything below 100kb is small enough to be considered an instant download, with no need to use preloaders. However, adding graphical and sound assets to the game will quickly push it up in size, at which point the preloader will probably be a good idea.
Is there any significant performance/load time impact if single web page will load, say, 10 identical flash objects? 20? 30?.. any evidential data on sustainability of such kind of setup?
This would be the same flash app, each instance serving its own stream.
There's definitely going to be some overhead in size as there is a certain amount of code that is contained in every swf regardless of it's developer created content.
I'm almost certain there would be speed issues as well, which would see frame rates drop right down the more swfs you add to the page.
To be honest the concept smells a little fishy and i would think there must be a better solution to your problem.
EDIT
Also there is a restriction on having two steams coming over http per domain. Sure you could get around this but it will definitely be an issue.
I found this post which might help. The trick is to use SWFObject to embed your swf files.
I ran into a strange problem today. On the music charts page on Muziboo, I was displaying a list of songs and a playlist on the right. Each song has a small button player done in OpenLaszlo. In firefox everything was fine and in IE (not unusually), the page would freeze for sometime. This would happen once and repeat only if I delete cache and try again. I googled a bit and learnt that it's a good idea to embed give each swf a unique id otherwise the browser misbehaves. I then went ahead and used swfobject to embed the swf files and everything started working great!
Yes, it'll likely nuke the browser if you go too far down that road.
If you want to deal in multiple streams, perhaps combining all your would-be applets into one giant one might work better. It'll certainly offset the serious overhead you'd have with 10-40 of the little blighters.
If this is a music player, you want to have a serious look at doing some JavaScript remoting. It's fairly trivial to control a flash app via JS so you could have standard HTML/CSS controls without having to load up a billion flash instances.
Design-wise this just sounds like a bad idea. You'd be running multiple instances of the Flash player inside a browser, each of which has an individual cost, and the host (in this case the browser) will run all of them on the same thread (with the exception of certain elective asynchronous processes), so you're almost surely going to run into problems of various kinds -- jittery playback, UI blocking, processor burden, memory bloat, consequent instability of the host, etc.
Unless the SWFs are very tiny, and doing very little work, it seems like a design that's just asking for trouble. Indeed you could test such a thing fairly easily; have you run any tests yet? Just curious.
Also curious as to the requirements; we might be able to offer more constructive alternatives if we knew a little more about what you were aiming for. Have you considered simply loading all the SWFs into a single container SWF requiring only a single browser-hosted instance of the Flash player?