Recherche avancée

Sur d’autres sites (3224)

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.

• Cross-compiling for ffmpeg : libvpx decoder version must be >=0.9.1

  13 octobre 2016, par bot1131357

  (Note : I know the title is almost identical to this question, but its solution is only applicable if I were building on my own system. I am building for an embedded ARM device.)

  I am trying to build a cross-compile FFmpeg library to be targeted on an arm device, and the ./configure command tells me that libvpx is outdated.

  My version of libvpx is as follows :

  $ pkg-config --modversion vorbis 
  
  1.3.2

  When I run ./configure

  $ ./configure --prefix=/home/test/Dev/build-arm/ffmpeg-armhf/ --enable-cross-compile --cross-prefix=${CCPREFIX} --arch=armhf --target-os=linux --pkg-config-flags="--libs vpx --static --cflags" --enable-shared --enable-libvpx 
  
  ERROR: libvpx decoder version must be >=0.9.1
  
  
  
  If you think configure made a mistake, make sure you are using the latest
  
  version from Git.  If the latest version fails, report the problem to the
  
  ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
  
  Include the log file "config.log" produced by configure as this will help
  
  solve the problem.

  My vpx.pc file is located in /usr/share/pkgconfig. Since it’s for a different target (arm), Should I be putting this file somewhere else ? :

  # pkg-config file from libvpx v1.6.0-322-gc325fb7
  
  prefix=/home/test/Dev/build-arm/libvpx
  
  exec_prefix=${prefix}
  
  libdir=${prefix}/lib
  
  includedir=${prefix}/include
  
  
  
  Name: vpx
  
  Description: WebM Project VPx codec implementation
  
  Version: 1.6.0
  
  Requires:
  
  Conflicts:
  
  Libs: -L${libdir} -lvpx -lm
  
  Libs.private: -lm -lpthread
  
  Cflags: -I${includedir}

  In my config.log I see this :

  (...lots of text...)
  
  arm-openwrt-linux-gnueabi-gcc -Werror=missing-prototypes -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=armv7-a -std=c99 -fomit-frame-pointer -marm -fPIC -pthread -c -o /tmp/ffconf.cZcBLWc3.o /tmp/ffconf.sWjTIULb.m
  
  arm-openwrt-linux-gnueabi-gcc: /tmp/ffconf.sWjTIULb.m: Objective-C compiler not installed on this system
  
  check_pkg_config vpx >= 0.9.1 vpx/vpx_decoder.h vpx/vp8dx.h vpx_codec_vp8_dx
  
  false --exists --print-errors vpx >= 0.9.1
  
  check_lib2 vpx/vpx_decoder.h vpx/vp8dx.h vpx_codec_dec_init_ver -lvpx
  
  check_func_headers vpx/vpx_decoder.h vpx/vp8dx.h vpx_codec_dec_init_ver -lvpx
  
  check_ld cc -lvpx
  
  check_cc
  
  BEGIN /tmp/ffconf.gM9G9FSQ.c
  
      1   #include <vpx></vpx>vpx_decoder.h>
  
      2   #include <vpx></vpx>vp8dx.h>
  
      3   long check_vpx_codec_dec_init_ver(void) { return (long) vpx_codec_dec_init_ver; }
  
      4   int main(void) { return 0; }
  
  END /tmp/ffconf.gM9G9FSQ.c
  
  arm-openwrt-linux-gnueabi-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=armv7-a -std=c99 -fomit-frame-pointer -marm -fPIC -pthread -c -o /tmp/ffconf.cZcBLWc3.o /tmp/ffconf.gM9G9FSQ.c
  
  /tmp/ffconf.gM9G9FSQ.c:1:29: fatal error: vpx/vpx_decoder.h: No such file or directory
  
  compilation terminated.
  
  ERROR: libvpx decoder version must be >=0.9.1

  It looks like the include and library paths are not provided to the compiler, but I don’t know how I should go around solving that.
  I would really appreciate it if you could offer some guidance.

• Approaches To Modifying Game Resource Files

  16 août 2016, par Multimedia Mike — Game Hacking

  I have been assisting The Translator in the translation of another mid-1990s adventure game. This one isn’t quite as multimedia-heavy as the last title, and the challenges are a bit different. I wanted to compose this post in order to describe my thought process and mental model in approaching this problem. Hopefully, this will help some others understand my approach since what I’m doing here often appears as magic to some of my correspondents.

  High Level Model
  At the highest level, it is valuable to understand the code and the data at play. The code is the game’s engine and the data refers to the collection of resources that comprise the game’s graphics, sound, text, and other assets.

  
  
  Simplistic high-level game engine model
  

  Ideally, we want to change the data in such a way that the original game engine adopts it as its own because it has the same format as the original data. It is very undesirable to have to modify the binary engine executable in any way.

  Modifying The Game Data Directly
  How to modify the data ? If we modify the text strings for the sake of language translation, one approach might be to search for strings within the game data files and change them directly. This model assumes that the text strings are stored in a plain, uncompressed format. Some games might store these strings in a text format which can be easily edited with any text editor. Other games will store them as binary data.
  

  In the latter situation, a game hacker can scan through data files with utilities like Unix ‘strings’ to find the resources with the desired strings. Then, use a hex editor to edit the strings directly. For example, change “Original String”…

  0098F800   00 00 00 00  00 00 00 4F  72 69 67 69  6E 61 6C 20  .......Original 
  0098F810   53 74 72 69  6E 67 00 00  00 00 00 00  00 00 00 00  String..........
  

  …to “Short String” and pad the difference in string lengths using spaces (0x20) :

  0098F800   00 00 00 00  00 00 00 53  68 6F 72 74  20 53 74 72  .......Short Str
  0098F810   69 6E 67 20  20 20 00 00  00 00 00 00  00 00 00 00  ing   ..........
  

  This has some obvious problems. First, translated strings need to be of equal our smaller length compared to the original. What if we want to encode “Much Longer String” ?

  0098F800   00 00 00 00  00 00 00 4D  75 63 68 20  4C 6F 6E 67  .......Much Long
  0098F810   65 72 20 53  74 72 00 00  00 00 00 00  00 00 00 00  er Str..........
  

  It won’t fit. The second problem pertains to character set limitations. If the font in use was only designed for ASCII, it’s going to be inadequate for expressing nearly any other language.

  So a better approach is needed.

  Understanding The Data Structures
  An alternative to the approach outlined above is to understand the game’s resources so they can be modified at a deeper level. Here’s a model to motivate this investigation :

  
  
  Model of the game resource archive format
  

  This is a very common layout for such formats : there is a file header, a sequence of resource blocks, and a trailing index which describes the locations and types of the foregoing blocks.

  What use is understanding the data structures ? In doing so, it becomes possible to write new utilities that disassemble the data into individual pieces, modify the necessary pieces, and then reassemble them into a form that the original game engine likes.

  It’s important to take a careful, experimental approach to this since mistakes can be ruthlessly difficult to debug (unless you relish the thought of debugging the control flow through an opaque DOS executable). Thus, the very first goal in all of this is to create a program that can disassemble and reassemble the resource, thus creating an identical resource file. This diagram illustrates this complex initial process :

  
  
  Rewriting the game resource file
  

  So, yeah, this is one of the most complicated “copy file” operations that I can possibly code. But it forms an important basis, since the next step is to carefully replace one piece at a time.

  
  
  Modifying a specific game resource
  

  This diagram shows a simplistic model of a resource block that contains a series of message strings. The header contains pointers to each of the strings within the block. Instead of copying this particular resource block directly to the new file, a proposed modification utility will intercept it and rewrite the entire thing, writing new strings of arbitrary length and creating an adjusted header which will correctly point to the start of each new string. Thus, translated strings can be longer than the original strings.

  Further Work
  Exploiting this same approach, we can intercept and modify other game resources including fonts, images, and anything else that might need to be translated. I will explore specific examples in a later blog post.

  Followup

  • Translating Return to Ringworld, in which I apply the ideas expressed in this post.