Hi guys,
A quick search on the forums hasn’t shown anything useful/recent on the subject of intro/loading videos.
Essentially once peoplepress ok on the settings screen then while the game is loading it should play back a video. Once the game has loaded any key/mouse/whatever should then skip the rest of the video.
In Android there is no settings screen so it should go straight to the video while the app loads.
Has anyone done anything like this or even made a start on it? It’s a very common feature of games so something people will expect…
Thanks,
Z
At the moment there’s no simple way of doing it. Monolo_fan did release something, but it has no audio and he said it still needs a lot of development, so I wouldn’t expect anything easily useable in the near future, unless you want to do it yourself 
and then share it after <3
In Android, there is a splash screen that can appear so that the user has something to look at until the app is loaded. It goes away automatically on the first update loop. No video though.
so many people ask about video player…
maybe you will find something interesting here:
http://hub.jmonkeyengine.org/groups/user-code-projects/forum/topic/video-rendering-system-for-jmonkeyengine/
if not, only wait for JME solution or make one yourself.
Ugh, I’ve been doing some reading around and the java-video-playback situation is really horrifically messy! 
It’s almost easier just to point a web browser at youtube and stream the video from there!
Hmm, this thread seems interesting: http://www.java-gaming.org/topics/java-media-player/27100/view.html
have you tried it?
@zarch said:
Hmm, this thread seems interesting: http://www.java-gaming.org/topics/java-media-player/27100/view.html
Yeah, there is some interresting information there :)
mhhh this lib just looks like exactly what we need.
@Momoko_Fan please read the linked thread and consider this approach.
Read through the thread it looks like “all” that would be needed is to grab YUNPM (they go through quite a few iterations in the thread and the most recent looks like it gives decent performance from what they are saying) and insert it into the correct place in the rendering system.
Assuming the proof of concept works we would also need to do a compile of ffmpeg without the problem codecs for each target platform and put the correct DLLs in the SDK for distribution along with the attribution/source stuff to comply with LGPL.
I don’t see a problem with restricting games developers to one or two open source codecs so we can avoid all the patent/etc problems that come with certain codecs. If a developer can’t cope with encoding their videos into a known format then they aren’t going to get very far anyway…
mhhh… not sure about the patent thing though
FFmpeg License and Legal Considerations
if you skip to the last question of the FAQ it’s pretty clear there are patent issue with the codec algorithm and not only with the content…
Apart from that i tested the bundled executable and it works fine…
Looks like it would be pretty straight forward to include it into the renderer.
But this license thing has to be sorted out before…
According to the YUNPM thread (I’ve not confirmed this myself) ffmpeg comes bundled with a bunch of codecs, however if you build it yourself you can choose what codecs to include.
If you ditch all the patent encumbered ones (for example just use Theora) there are no known patent issues. The reason no-one will give a definitive answer though is the risk that someone is sitting on a submarine patent and waiting for Theora to become big before starting to sue.
…because software patents “encourage innovation” don’t you know…
So that’s why I said about building ffmpeg ourselves for each target platform and including the dll in the SDK.
TBH I don’t see a problem with restricting developers to a certain codec. If people can manage to make a video they can manage to transcode it and 99.9% of games will only be rendering out known and included video clips anyway.
Just for a idea since in only read quickly trough this, it would be probably a good thing if the whole video rendering stuff would be something like render to textures, since that would allow to add videos easily as game content too, not only for an fullscreen intro.
Maybe even the ImagePainter is fast enough…
just a few cents
Yep, I agree.
Also we could somehow bundle an encoder for this particular format with the SDK.
@normen what do you think?
EDIT : this was meant to answer Zarch
@zzueg, actually it already has the capability to render to texture.
@nehon said:
Yep, I agree.
Also we could somehow bundle an encoder for this particular format with the SDK.
@normen what do you think?
EDIT : this was meant to answer Zarch
The only issue with that is that the bundled encoder would potentially also need a decoder...which would then have the same issues.
Although given that JME3 is distributed for free I guess the worst case is we just have to stop that bundling...
We will have to restrict ourselves to one of the open formats yeah, that point was always clear.
There are a few things to consider:
- This library uses an external process to play the video, instead of a native library. Thus the ffmpeg executable will need to be extracted or included somewhere along with the jME3 application.
- The ffmpeg version included with the builds has patent encumbered codecs, and thus cannot be distributed legally. Someone needs to recompile a version without these codecs.
- Android support - If we were to add a video player system to jME3, it would need to support Android as well. From the patent-free codecs, Android only supports WebM, and only after version 2.3.3. Previous versions will require using patent-encumbered codecs so that means you need to have two versions of the video, one for desktop / Android 2.3.3+, and one for Android below 2.3.3.
Good points. Doing the recompile I don’t see being an issue, its just a matter of someone getting it done.
The external process thing I guess would be a blocker for using this on applets as well?
http://developer.android.com/about/dashboards/index.html
This shows pre-Gingerbread to be down to 17% of the market (from 30% at the start of the year). What’s the cut off point at which we move the minimum supported device up? I can’t remember the details but haven’t I seen stuff about other issues with the earlier versions as well, not just missing video codecs? The same page shows OpenGL 1.1 only being down to 9.2%.
Theres theora decoders that are purely java afaik so they should work on android as well?