Closed razzeee closed 7 years ago
Comment by gamester17 on 4 Oct 2003 13:38 UTC
Logged In: YES user_id=630186
According to eabair (MAMEoX) VMM could relativly easy be implemeted as long as the dev know where to hock it up, so guess/hope will not be too hard to hock up in MPlayer's code? http://sourceforge.net/tracker/? func=detail&atid=554245&aid=737393&group_id=78713
Maybe you can take a look at VMM and how MAMEoX does it?
Comment by nuendo on 12 Apr 2004 02:23 UTC
Logged In: YES user_id=692875
Butcher added a VM system for large subfiles yesterday.Now it is possible to use subs even if they are 60MB of size.
Reported by Gamester17 on 4 Oct 2003 11:17 UTC
Support for larger .sub (VobSub) subtitle files
This is a Feature Request for support of larger uncompressed VobSub (.sub) subtitle files to be supported in XBMP. Currently VobSubs only work if they are smaller than about 4MB in size due to Xbox/XBMP running out of memory and XBMP loads the entirely sub file into RAM.
Maybe support for larger subs could be prissible if harddrive paging was implemented and/or .sub's was only read in chunks of maybe 256KB or 1MB at a time? I believe harddrive paging would only be needed if the sub is located on CD/DVD or a network share, if the sub was on Xbox local harddrive it could be read in chunks right away, ...maybe that could work of network and/or CD/DVD as well (I don't know).
PS! Kawa-X is using harddrive paging?, maybe could do it like it? This is how Mr K, the author of Kawa-X explained it to me:
"The principle is simple. First the data is read from the rom files, and processed in a suitable form, and it's wrote back in 256kb chunks on the Z: drive. Why 256kb ? cause it's fast to read or write that amount of data, and yet it contains a sufficiently significant amount of data (2048 tiles in the case of NeoGeo)
Then, in the case of KawaX, 20mb are allocated in RAM, and divided in 256kb chunks. Each of them will eventually recieve the content of one of the files. Such a chunk is called a page. So, at a given time, we always have 80 pages loaded in RAM.
During emulation, the following occurs: Instead of accessing directly a byte array that would contain the ROM, I call a function giving it the offset I need, and that will return a pointer to the relevant data The function checks if the needed page is loaded. Yes ? good, we return a derivated pointer. No ? We load the needed page from Z: to the least recently used page in central RAM.
Least recently is decided this way: when one page is accessed, its flag is set to 0, and at the end of each frame, all pages are incremented. So at a given time, the page with the highest flag is the one that was used the longest ago, and will be ditched first when needed."
Migrated-From: http://trac.kodi.tv/ticket/57