Recherche avancée

Sur d’autres sites (6660)

• Tele-Arena Lives On

  25 février 2011, par Multimedia Mike — Game Hacking

  Readers know I have a peculiar interest in taking apart video games and that I would rather study a game’s inner workings than actually play it. I take an interest on others’ efforts in this same area. It’s still in my backlog to take a closer look at Clone2727’s body of work. But I wanted to highlight my friend’s work on re-implementing a game called Tele-Arena.

  
  
  

  Back In The Day
  As some of you are likely aware, there was a dark age of online communication that predated the era of widespread internet access. This was known as "The BBS Age". People dialed into these BBSes using modems that operated at abysmal transfer speeds and would communicate with other users, upload and download files, and play an occasional game.

  BBS software evolved and perhaps the ultimate (and final) evolution was Galacticomm’s MajorBBS (MBBS). There were assorted games that plugged into the MBBS, all rendered in glorious color ANSI graphics. One of the most famous of these games was Tele-Arena (TA). TA was a multiplayer fantasy-themed text adventure game. Perhaps you could think of it as World of Warcraft, only rendered as interactive fiction instead of a rich 3D landscape. (Disclaimer : I might not be qualified to make that comparison since I have never experienced WoW firsthand, though I did play TA on and off about 17 years ago).

  TA was often compared to multi-user dungeons — or MUDs — that were played by telneting into internet servers hosting games. Such comparisons were usually unfavorable as people who had experience with both TA and MUDs were sniffy elitists with internet access who thought they were sooooo much better than those filthy, BBS-dialing serfs.

  Sorry, didn’t mean to open old wounds.

  Modern Retelling of A Classic Tale
  Anyway, my friend Ron Kinney is perhaps the world’s biggest fan of TA. So much so that he has re-implemented the engine in Java under the project name Ether. He’s in a similar situation as the ScummVM project in that, while the independent, open source engine is fair game for redistribution, it would be questionable to redistribute the original data files. That’s why he created an AreaBuilder application that generates independent game data files.

  Ironically, you can also telnet into a server on which Ron hosts an instance of Tele-Arena (ironic in the sense that the internet/BBS conflict gets a little blurry).

  I hope that one day Ron will regale us with the strangest tales from the classic TA days. My personal favorite was "Wrath of a Sysop."

• Further Dreamcast Hacking

  3 février 2011, par Multimedia Mike — Sega Dreamcast

  I’m still haunted by Sega Dreamcast programming, specifically the fact that I used to be able to execute custom programs on the thing (roughly 8-10 years ago) and now I cannot. I’m going to compose a post to describe my current adventures on this front. There are 3 approaches I have been using : Raw, Kallistios, and the almighty Linux.

  
  

  Raw
  What I refer to as "raw" is an assortment of programs that lived in a small number of source files (sometimes just one ASM file) and could be compiled with the most basic SH-4 toolchain. The advantage here is that there aren’t many moving parts and not many things that can possibly go wrong, so it provides a good functional baseline.

  One of the original Dreamcast hackers was Marcus Comstedt, who still has his original DC material hosted at the reasonably easy-to-remember URL mc.pp.se/dc. I can get some of these simple demos to work, but not others.

  I also successfully assembled and ran a pair of 256-byte (!!) demos from this old DC scene page.

  KallistiOS
  KallistiOS (or just KOS) was a real-time OS developed for the DC and was popular among the DC homebrew community. All the programming I did back in the day was based around KOS. Now I can’t get any of it to work. More specifically, KOS can’t seem to make it past a certain point in its system initialization.

  The Linux Option
  I was never that excited about running Linux on my Dreamcast. For some hackers, running Linux on a given piece of consumer electronics is the highest attainable goal. Back in the day, I looked at it from a much more pragmatic perspective— I didn’t see much use in running Linux on the DC, not as much as running KOS which was developed to be a much more appropriate fit.

  However, I was able to burn a CD-R of an old binary image of Linux 2.4.5 compiled for the Dreamcast and boot it some months ago. So I at least have a feeling that this should work. I have never cross-compiled a kernel of my own (though I have compiled many, many x86 kernels in my time, so I’m not a total n00b in this regard). I figured this might be a good time to start.

  The first item that worries me is getting a functional cross-compiling toolchain. Fortunately, a little digging in the Linux kernel documentation pointed me in the direction of a bunch of ready-made toolchains hosted at kernel.org. So I grabbed one of the SH toolchains (gcc-4.3.3-nolibc) and got rolling.

  I’m well familiar with the cycle of 'make menuconfig' in order to pick configuration options, and then 'make' to build a kernel (or usually 'make zImage' or 'make bzImage' to create compressed images). For cross compiling, the primary difference seems to be editing the root Makefile in the Linux source code tree (I’m using 2.6.37, the latest stable as of this writing) and setting a value for the CROSS_COMPILE variable. Then, run 'make menuconfig' followed by 'make' as normal.

  The Linux 2.6 series is supposed to support a range of Renesas (formerly Hitachi) SH processors and board configurations. This includes reasonable defaults for the Sega Dreamcast hardware. I got it all compiling except for a series of .S files. Linus Torvalds once helped me debug a program I work on so I thought I’d see if there was something I could help debug here.

  The first issue was with ASM statements of a form similar to :

  mov #0xffffffe0, r1
  

  Now, the DC’s SH-4 is a RISC CPU. A lot of RISC architectures adopt a fixed instruction size of 32 bits. You can’t encode an entire 32-bit immediate value inside of a 32-bit instruction (there would be no room for the instruction encoding). Further, the SH series encoded instructions with a mere 16 bits. The move immediate data instruction only allows for an 8-bit, sign-extended value.

  I decided that the above statement is equivalent to :

  mov #-32, r1
  

  I’ll give this statement the benefit of the doubt that it used to work with the gcc toolchain somewhere along the line. I assume that the assembler is supposed to know enough to substitute the first form with the second.

  The next problem is that an ’sti’ instruction shows up in a number of spots. Using Intel x86 conventions, this is a "set interrupt flag" instruction (I remember that the 6502 CPU had the same instruction mnemonic, though its interrupt flag’s operation was opposite that of the x86). The SH-4 reference manual lists no ’sti’ instruction. When it gets to these lines, the assembler complains about immediate move instructions with too large data, like the instructions above. I’m guessing they must be macro’d to something else but I failed to find where. I commented out those lines for the time being. Probably not that smart, but I want to keep this moving for now.

  So I got the code to compile into a kernel file called ’vmlinux’. I’ve seen this file many times before but never thought about how to get it to run directly. The process has usually been to compress it and send it over to lilo or grub for loading, as that is the job of the bootloader. I have never even wondered what format the vmlinux file takes until now. It seems that ’vmlinux’ is just a plain old ELF file :

  $ file vmlinux
  vmlinux : ELF 32-bit LSB executable, Renesas SH,
  version 1 (SYSV), statically linked, not stripped
  

  The ’dc-tool’ program that uploads executables to the waiting bootloader on the Dreamcast is perfectly cool accepting ELF files (and S-record files, and raw binary files). After a very lengthy upload process, execution fails (resets the system).

  For the sake of comparison, I dusted off that Linux 2.4.5 bootable Dreamcast CD-ROM and directly uploaded the vmlinux file from that disc. That works just fine (until it’s time to go to the next loading phase, i.e., finding a filesystem). Possible issues here could include the commented ’sti’ instructions (could be that they aren’t just decoration). I’m also trying to understand the memory organization— perhaps the bootloader wants the ELF to be based at a different address. Or maybe the kernel and the bootloader don’t like each other in the first place— in this case, I need to study the bootable Linux CD-ROM to see how it’s done.

  Optimism
  Even though I’m meeting with rather marginal success, this is tremendously educational. I greatly enjoy these exercises if only for the deeper understanding they bring for the lowest-level system details.

• FFMPEG Undefined Reference to 'avcodoec_open2' in C++

  12 avril 2012, par ALM865

  I have an error when compiling one of my C++ programs after updating the FFMPEG library from 0.8 to 'ffmpeg version git-2012-04-12-277f20c'

  The error I get when I make my program is as follows :

  -------- begin --------
  
  Linking: Analysing_Server
  
  ./source/Encoding_Thread.o: In function `CEncoding_Thread::do_work()':
  
  /home/Analyser/source/Encoding_Thread.cpp:155: undefined reference to `avcodec_open2'
  
  collect2: ld returned 1 exit status
  
  make: *** [Analysing_Server] Error 1

  The relevant lines of my Make file is similar to running g++ as below :

  g++ test2.cpp -lavformat -lavcodec -lavutil -D__STDC_CONSTANT_MACROS

  A stripped down version of my relevant CPP code that throws the error is :

  #include 
  
  #include  
  
  
  
  #define LOG_OUT_STREAM_BUFF_SIZE  200000
  
  
  
  
  
  extern "C"  {
  
    /* The ffmpeg library is completely written in C, so we need to tell the C++ compiler that so it links correctly. */
  
    #include "stdint.h"
  
    #include "libavcodec/avcodec.h"
  
    #include "libavutil/mathematics.h"
  
    #include "libswscale/swscale.h"
  
    #include "libavfilter/avfilter.h"
  
  
  
    int avcodec_open2(AVCodecContext *avctx, AVCodec *codec, AVDictionary **options);
  
    int avcodec_encode_video2(AVCodecContext *avctx, AVPacket *avpkt, const AVFrame *frame, int *got_packet_ptr);
  
  }
  
  
  
  uint8_t m_outbuf[2][LOG_OUT_STREAM_BUFF_SIZE];
  
  unsigned int m_out_size[2];
  
  unsigned int m_OutBuffer_ID[2];
  
  unsigned int m_Buffer_ID; /* This is just a uniqueish stamp we give to each buffer so we can tell when they change.. */
  
  
  
  AVCodecContext * m_CodecContex;
  
  AVCodec * m_codec;
  
  struct SwsContext *m_img_convert_ctx;
  
  
  
  unsigned char* m_DataBuff;
  
  
  
  int Output_Width, Output_Height;
  
  int Output_Bitrate;
  
  
  
  
  
  int main(void) {
  
    //New version of FFMPEG calls this in avcodec_register_all
  
    //avcodec_init();
  
  
  
    /* register all the codecs */
  
    avcodec_register_all();
  
  
  
    /* Initalise the encoder */
  
    m_codec = avcodec_find_encoder(CODEC_ID_MP2);
  
  
  
    if (!m_codec) {
  
      printf("Encoding codec not found\n");
  
    }
  
  
  
    /* init the pointers.. */
  
    m_CodecContex = NULL;
  
  
  
    /* Default values.. */
  
    Output_Width = 1600;
  
    Output_Height = 1200;
  
    Output_Bitrate = 600000;
  
  
  
    /* Create/setup the Codec details.. */
  
    //Changed to work with new FFMPEG
  
    m_CodecContex = avcodec_alloc_context3(m_codec);
  
    avcodec_get_context_defaults3(m_CodecContex, m_codec);
  
  
  
    /* put sample parameters */
  
    m_CodecContex->bit_rate = Output_Bitrate;
  
    /* resolution must be a multiple of two */
  
  
  
    m_CodecContex->width = Output_Width;
  
    m_CodecContex->height = Output_Height;
  
    /* frames per second */
  
    m_CodecContex->time_base= (AVRational){1,25};
  
  
  
    m_CodecContex->gop_size = 10; /* emit one intra frame every ten frames */
  
    m_CodecContex->max_b_frames=1;
  
    m_CodecContex->pix_fmt = PIX_FMT_YUV420P; /* must be YUV for encoding.. */
  
  
  
  
  
    AVDictionary * RetunedAVDic;
  
  
  
    /* open it */
  
    //Changed to work with new FFMPEG
  
    if (avcodec_open2(m_CodecContex, m_codec, &RetunedAVDic) < 0) {
  
        printf("could not open codec");
  
    }
  
  }

  Unfortunately the example under 'doc/examples/decoding_encoding.c' that comes with FFMPEG no longer works because all the functions that it uses are now depreciated. My code is based on the example code and worked fine with FFMPEG 0.8 but does not compile with the newest version of FFMPEG. I have changed some of the depreciated functions to their newer versions but it still doesn't compile.

  Does anyone know why I am getting this error ? or does anyone have a link to an example like 'doc/examples/decoding_encoding.c' using the newest version of FFMPEG ?