Difference between revisions of "User:Bluddy"

From ScummVM :: Wiki
Jump to navigation Jump to search
 
(18 intermediate revisions by the same user not shown)
Line 3: Line 3:
     name=Yotam Barnoy|
     name=Yotam Barnoy|
     memberSince=2009-09-22|
     memberSince=2009-09-22|
     workingOn=[[PlayStation_Portable|PSP platform]]<br>Refactoring and Cleanup |
     workingOn=[[PlayStation_Portable|PSP platform]]<br>PSP Optimization |
}}
}}


Line 16: Line 16:


== Working On ==
== Working On ==
* PSP
* PSP Optimization
** Optimization
** Rendering speedup: done and makes vsync super accurate (better than PC)
*** Adding PSP profiling support to the trunk - done
** MP3 using Media Engine: done
*** Moving all buffers to uncached space
*** Turn into thread for better efficiency (allowing music more processing time without slowdown)
**** Doesn't seem like a great idea. Some parts of the code need the buffers to be cached, particularly if they access small pieces. Audio buffers absolutely MUST be cached for decent speed.
*** But will threading really help? It's pretty complicated. What about syncing?
**** Memcopy can be greatly improved with alignment, rotation of unaligned bits, and using the VFPU cache.
*** Correct small bug with seeking (already corrected in mainstream mp3 decoder). Clean up messy code.
*** Possibly adding PSP MP3 HW support
** Video Speedup
**** About 8% speedup in some games
*** Actually harder than expected: it's hard to find codecs that do the kind of work that the VFPU will improve
**** Looks like HW MP3 can only handle 2 MP3s at a time... should be enough usually.
*** Check other codecs for possible speedups using VFPU/alignment
**** Actually it should be able to do better with the libAudio implementation.
** Tests: done
**** I just found that the SDL 'mixer' blocks when playing audio! That's the thread we do all the work in!
*** how much reading is done by MP3 rendering/movie playback? How much will we need to cache? done. Reads chunks of 15-25KB preceded by small 4KB reads. Whole MP3 loads are a problem (200KB+).
***** Also, SDL creates threads that ALL have VFPU set. That's not efficient when switching contexts.
*** How often do we read from the memory stick when we're going fast (movies)? Can we use a thread to do async reading? Is there enough time between reads?
*** Speeding up video decompression using vector unit
** Improve memcpy: alignment, rotation
**** Doesn't seem likely for smush - not much parallel processing
*** Memcpy is done. Not sure how to improve it with VFPU.
*** Possibly speeding up music processing somehow?
*** Memmove can also be improved -- needs reverse memcpy.
**** Timidity may be a good option here
** No More SDL: done.
** Threads for audio: consumer and producer
*** Again, is this really helpful? It may allow lowering of priority, but only temporarily? What about syncing?
* Aspect Ratio: done
* Replace stdio with PSP functions: done.
** Turns out it's a huge speed boost!
* Timidity
** A lot of work. May improve speed over midi and sound better.


== To Do ==
== To Do ==
* PSP
* PSP
** MP3 playback with Media Engine
** Groovie video is slow
** Optimize speed in general
*** Seems like problem is in Groovie engine. Sounds start out fine and then get crackly.
** Optimize video playback speed
** Use libTimidity for music
** Use libTimidity for music
* Generic virtual keyboard: take my keyboard and make it available to all. Involves switching from bitmaps to vectors.
* Generic virtual keyboard: take my keyboard and make it available to all. Involves switching from bitmaps to vectors.
* Generic ELF loader
* Generic ELF loader
** Already done in GSOC. Solve issue with loading one plugin at a time.
* MP3 header processing for faster seeking and getting the file length.
* Image Viewer
== Ideas ==
* PSP may some day be unable to load ScummVM plugins as they are, because it's shifting towards accepting only PRX files (ie. PIC code). Some solution will be needed to adapt the current plugin code for PIC in the main executable.
** Idea: dump the symbol table of the main executable into another file. When loading plugins, load this into memory. Create a symbol in memory using ld script that will indicate where in memory the main executable was loaded. Finally, relocating the plugins will obviously be more work since we don't have ld to do some of the job for us. We might need 2 MipsPlugins: MipsComplete and MipsIncomplete.
** Alternatively instead of dumping the table, just copy the executable into the plugin directory and rename it base.plg.

Latest revision as of 20:01, 11 October 2010

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 and makes vsync super accurate (better than PC)
    • MP3 using Media Engine: done
      • Turn into thread for better efficiency (allowing music more processing time without slowdown)
      • But will threading really help? It's pretty complicated. What about syncing?
      • Correct small bug with seeking (already corrected in mainstream mp3 decoder). Clean up messy code.
    • Video Speedup
      • Actually harder than expected: it's hard to find codecs that do the kind of work that the VFPU will improve
      • Check other codecs for possible speedups using VFPU/alignment
    • Tests: done
      • how much reading is done by MP3 rendering/movie playback? How much will we need to cache? done. Reads chunks of 15-25KB preceded by small 4KB reads. Whole MP3 loads are a problem (200KB+).
      • How often do we read from the memory stick when we're going fast (movies)? Can we use a thread to do async reading? Is there enough time between reads?
    • Improve memcpy: alignment, rotation
      • Memcpy is done. Not sure how to improve it with VFPU.
      • Memmove can also be improved -- needs reverse memcpy.
    • No More SDL: done.
    • Threads for audio: consumer and producer
      • Again, is this really helpful? It may allow lowering of priority, but only temporarily? What about syncing?
  • Aspect Ratio: done
  • Replace stdio with PSP functions: done.
    • Turns out it's a huge speed boost!
  • Timidity
    • A lot of work. May improve speed over midi and sound better.

To Do

  • PSP
    • Groovie video is slow
      • Seems like problem is in Groovie engine. Sounds start out fine and then get crackly.
    • 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
    • Already done in GSOC. Solve issue with loading one plugin at a time.
  • MP3 header processing for faster seeking and getting the file length.
  • Image Viewer

Ideas

  • PSP may some day be unable to load ScummVM plugins as they are, because it's shifting towards accepting only PRX files (ie. PIC code). Some solution will be needed to adapt the current plugin code for PIC in the main executable.
    • Idea: dump the symbol table of the main executable into another file. When loading plugins, load this into memory. Create a symbol in memory using ld script that will indicate where in memory the main executable was loaded. Finally, relocating the plugins will obviously be more work since we don't have ld to do some of the job for us. We might need 2 MipsPlugins: MipsComplete and MipsIncomplete.
    • Alternatively instead of dumping the table, just copy the executable into the plugin directory and rename it base.plg.
Retrieved from "https://wiki.scummvm.org/index.php?title=User:Bluddy&oldid=14877"