Bluddy

Bluddy
Name	Yotam Barnoy
Team Member since	2009-09-22
Working on	PSP platform PSP Optimization
Personal webpage/BLOG	-
Email	-

Worked On

• PSP
  • Suspend/resume support
  • Plugin support (ELF loader)
  • Console-oriented virtual keyboard
  • D-pad directional support
  • Eliminating the evil undead flickering bug (it was a tough one)
  • Refactoring, redesign and cleanup

Working On

• PSP Optimization
  • Rendering speedup - done
    • Made the wait for vsync not slow down the main thread, by using callbacks. Turns out the callback mechanism that's tied to the GU is unable to call waitForVblank, but the regular callback mechanism can. This reduced the wait from 15ms on average to 3ms, part of which is due to the fact that by notifying the callback I think we switch context to another thread. Not a huge deal.
  • Timidity
    • A lot of work. May improve speed over midi, but it'll be the last optimization.
  • MP3 using Media Engine
    • I made a hack that'll do it, but unfortunately nobody knows how to use it for 22kHz mp3s, which is all of our MP3s. This means I need to reverse engineer the PSP FW in order to figure out how to do this properly (the PSP FW knows how to use the ME for 22 kHz files). So this is going to be hard too.
  • Video Speedup
    • Smush can be sped up for aligned platforms, and VFPU cache can be used in PSP
    • Check other codecs for possible speedups using VFPU
  • Other speedups
    • Tests
      • cached vs uncached access
      • how long does changing priority take?
      • how long do different length MS reads take?
      • how much reading is done by MP3 rendering/movie playback? How much will we need to cache?
      • how many ticks per second? Can we do it more efficiently than SDL?
    • Improve memcpy: alignment, rotation
      • Possibly use VFPU's cache for even better performance.
    • Caching of MS is sorely needed
      • Implement cache that reads while other threads don't (mutex) and fills up memory with file data. First stage will be like PS2: just read ahead.
  • No More SDL!
    • Improve SDL audio output
      • SDL blocks when outputting audio. This is the thread we do most work in, so don't block.
        • Unfortunately, it wasn't the kind of blocking that the name of the function would imply. It just means that it blocks if we try to play and the audio's already playing. This is still the only way to render sound properly, possibly due to tiny delays when context switching.
        • Our thread is still more efficient than SDL. Also, we can control the priority. We can also make the thread consume and another low priority thread the PCM producer for possibly higher efficiency.
        • Check if the timer (which is under heavy use in CoMI) also causes the clicking issue in that game because of long sound rendering. Maybe we can play with priorities, or maybe we need to put context switches in the timer/music/main code.
      • Also, SDL creates threads that ALL have VFPU bit set. That's not efficient when switching contexts.
      • Additionally, change priority so that MP3/MIDI rendering is in same priority and is fairer while getting called back is higher priority.
      • Maybe add a task switch in the Mixer to allow main thread to do stuff if there's a lot of mixing (and it's all from memory).
    • Replace SDL Timer
      • All we need is a simple sleeping thread

To Do

• PSP
  • MP3 playback with Media Engine
  • Optimize speed in general
  • Optimize video playback speed
  • Use libTimidity for music
• Generic virtual keyboard: take my keyboard and make it available to all. Involves switching from bitmaps to vectors.
• Generic ELF loader