Hello all,
I have been playing with both classes mentioned here. hub.jmonkeyengine.org/wiki/doku.php/jme3:advanced:capture_audio_video_to_a_file
The first as mentioned slows down the scene quite a bit, and it’s hard to work with (I also ran into an instance where my video wasn’t recorded, and had some weird playback error).
The second class is “better” it will sometimes be okay in speed, sometimes I will need to increase my movement speed, and sometimes it will freeze during video.
I really wanted to include the ability to record video in my game, but it seems like unless there is a way to fasten it up I wont be including it in my release.
I haven’t had any problems with the video record app state but it doesn’t do audio.
If video is messing up your movement speed then you may want to make sure you are considering tpf properly in your speed calculations.
@KonradZuse said:
Hello all,
I have been playing with both classes mentioned here. hub.jmonkeyengine.org/wiki/doku.php/jme3:advanced:capture_audio_video_to_a_file
The first as mentioned slows down the scene quite a bit, and it’s hard to work with (I also ran into an instance where my video wasn’t recorded, and had some weird playback error).
The second class is “better” it will sometimes be okay in speed, sometimes I will need to increase my movement speed, and sometimes it will freeze during video.
I really wanted to include the ability to record video in my game, but it seems like unless there is a way to fasten it up I wont be including it in my release.
It’s heavily dependent on the users machine. My new machine captures seamless video… my old machine captured terrible vids.
As cool as it would be to offer an internal way of doing this, most people will just use something like Fraps. Honestly, I still use Fraps even though there are internal solutions.
EDIT: A little late for the explination, but it just dawned on me terrible vids was a terrible way of putting it. It captured the exact same vid my new machine does… the game was just unplayable while capturing video.
Thanks both…
I’ll check into the tpf issue, though it should be correct (would anything else in my game be messed up as well due to tpf issues)?
I also am running a 4-5 year old dell laptop (refurbished) so just saying that you probably understand how slow this bad boy is :p.
I will try it out on the computer that was just purchased recently, so hopefully I can get some better results.
I know there is fraps and such, but some people dislike downloading additional stuff, so I figured it would be a good feature to have.
Also, I was curious about the advanced method. I read some of it, and I thought the audio channel example was cool, but I believe I saw something that said “live video”; so it is possible to stream a live feed via Jmonkey, maybe something like a video feed from a mobile cam?
I also saw something similar that was deprecated so I’m just curious where that stands now with JME3.
Thanks again.
In many ways, if you want to include something in your game then http://hub.jmonkeyengine.org/javadoc/com/jme3/app/state/VideoRecorderAppState.html is still the best way to go.
Negatives:
-it doesn’t do audio
Positives:
-it slows the time stepping down to guarantee you end up with smooth 30 FPS… of course, your game may be hard to control if your machine can’t keep up with 30 FPS but assuming tpf is used properly at least you won’t end up with jumpy frames.
-it’s probably about as fast as you’ll get for an embedded solution.
Anything beyond that then they would have to use an external solution. I also use fraps for my recording because it’s easier and has audio… but I include VideoRecorderAppState in my games for anyone who wants to take video without downloading anything.
@pspeed said:
In many ways, if you want to include something in your game then http://hub.jmonkeyengine.org/javadoc/com/jme3/app/state/VideoRecorderAppState.html is still the best way to go.
Negatives:
-it doesn’t do audio
Positives:
-it slows the time stepping down to guarantee you end up with smooth 30 FPS… of course, your game may be hard to control if your machine can’t keep up with 30 FPS but assuming tpf is used properly at least you won’t end up with jumpy frames.
-it’s probably about as fast as you’ll get for an embedded solution.
Anything beyond that then they would have to use an external solution. I also use fraps for my recording because it’s easier and has audio… but I include VideoRecorderAppState in my games for anyone who wants to take video without downloading anything.
I guess it’s that my machine isn’t handling the 30 fps constantly since ssao is turning it into it into a wet noodle. I guess I could always set the fps to an average (which I believe tpf should give me what I need or is that not a direct equivalent to fps)?
@KonradZuse said:
I guess it's that my machine isn't handling the 30 fps constantly since ssao is turning it into it into a wet noodle. I guess I could always set the fps to an average (which I believe tpf should give me what I need or is that not a direct equivalent to fps)?
tpf is the “time per frame” in seconds. Usually, if you are moving some ‘speed’ then you actually need to move speed * tpf per frame.
When the VideoRecorderAppState is enabled, it forces the tpf to always be 1/30th of a second… no matter how slow the actual frame rate is. Thus, you end up getting smooth 30 FPS real time video even if your game is only running at 1 FPS. This can make it hard to control, though.
If you want to stream the game I suggest using ShadowPlay instead of doing it in the game itself.
jME is based on OpenGL. ShadowPlay (from NVIDIA) doesn’t support OpenGL as far as I know.