Recherche avancée

Sur d’autres sites (10142)

• Origin Crusader Media

  14 février 2012, par Multimedia Mike — Game Hacking

  A gleaming copy of the old Origin game Crusader : No Remorse showed up today :

  
  
  

  Immediately, I delved in expecting to find Xan-encoded AVI files that would play perfectly using FFmpeg/Libav. Instead, I found a directory labeled flics/ that indeed has a lot of AVI files, but not in Xan. The programs attempt to interpret them as raw RGB. The strangest thing is the first frame often looks correct, if upside down :

  
  
  

  The first file I peered inside had the video FourCC ‘RRV1′. Searching for this led me to this discussion forum where people have already been hacking on this very format (Origin games invariably get a heap of lasting love). The forum participants have observed that 3 codecs are in play in this flics/ directory, including ‘RRV1′, ‘RRV2′, and ‘JYV1′, which apparently correspond to the initials of certain developers. The reason that the programs identify the files as raw RGB is because the FourCCs don’t appear everywhere that they’re supposed to. Additionally, there are several trailers for other Origin/EA games stored in Cinepak format elsewhere on the disc.

  It seems that I’m the person who added this title to the Xan wiki page, obviously with no first-hand evidence to back it up. Meanwhile, the forum participants speculate that the files are descended from the old Autodesk FLIC format (which would explain why they live in a directory called flics/). Corroborating strings extracted from the CRUSADER.EXE file include “FlicWait”, “FlicPlayer”, “Flic %s not found.”, “flicpath”, and “FLICPLAY.C”.

  The disc also features a sound/ directory which contains AMF files. Suxen Drol already documented these on the wiki as Asylum Media Format files. The disc contains an ASYLUM.DLL file as well as a utility called MOD2AMF.EXE. The latter works beautifully on a random MOD file I had laying around. The AMF file is a bit larger.

  Samples for all 3 FourCCs can be found here, while the AMF files and associated utilities are here.

• Best way to go about video playback for WebAssembly, Linux, Windows, and Android

  13 janvier 2021, par Michael Macha

  I'm currently working on a game as a passtime during quarantine. It currently builds, via a Makefile, for WASM, Linux, and Windows ; and is eventually planned to be ported to Android through NDK. The API used is (primarily) SDL, with SDL Image and SDL Mixer, and all graphics go through OpenGL.

  


  As of the moment, all graphics, sound, and control is running perfectly ; but I would like to add video cut scenes and I'm uncertain of how to do this with WASM. I recognize that maybe half of the system resources are available in a browser, and am willing to drop fidelity in the web version to compensate. Currently, all code is in C and GLSL ; but if I need to I can add C++, or a little extra JavaScript.

  


  My compilers, for each platform, are gcc, emcc, and mingw32. They're all called through Maketools. As of the moment, it looks like I can just use FFMPEG for gcc & mingw ; but what's best for emcc, which does not have an FFMPEG port available ? Will I need to call something else, or use some specific browser function ? What is the simplest way to go about this, and does anyone have a basic tutorial for in-browser video with WebAssembly ?

  


  For a little further data, I'm debuting my project on Itch.io. For a launched-in-browser game, they require a zip file with an HTML file called index.html, and any support files, within it. (Total file size is effectively limited to 1 GB.) I'm expecting a minimum of 640x480 resolution, but would prefer higher. I'm currently digging through online examples but haven't yet found anything sufficiently basic. (This might change as I keep digging, and I'll update the question if I find anything.)

  


• Writing linear float range to openEXR turns out non linear

  3 avril 2022, par Chryfi

  I am writing the linearized depth buffer of a game to openEXR using FFmpeg. Unfortunately, FFmpeg does not adhere to the openEXR file specification fully (like allowing unsigned integer for one channel) so I am writing one float channel to openEXR, which is put into the green channel with this command -f rawvideo -pix_fmt grayf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr.

  


  The float range is from 0F to 1F and it is linear. I can confirm that the calculation and linearization is correct by testing 16 bit integer (per pixel component) PNG in Blender compositor. The 16 bit integer data is written like this short s = (short) (linearzieDepth(depth) * (Math.pow(2,16) - 1)) whereas for float the linearized value is directly written to OpenEXR without multiplying with a value.

  


  However, when viewing the openEXR file it doesn't have the same "gradient" as the 16 bit png... when viewing them side by side, it appears as if the values near 0 are not linear, and they are not as dark as they should be like in the 16 bit png.
(And yes, I set the image node to linear), and comparing it with 3d tracking data from the game I cant reproduce the depth and cant mask things using the depth buffer where as with the png I can.

  


  How is it possible for a linear float range to turn out so different to a linear integer range in an image ?