I don’t quite see how SDL_RWops would help here… You’d either
need
Well the first idea was: to create new thread for reading. There i
could create SDL_RWops structure for file where pointer for read
function should point to my function. First i count how much time
is read called and then count from it the value for delaying
something like this:
read(…)
{
if (have to wait)
wait_some_time;
read_another_bytes;
}
And then to use standard SDL_Image
extern DECLSPEC SDL_Surface *IMG_LoadJPG_RW(SDL_RWops *src);
it will use my delayed reading no?
The RWops are direct calls, so I don’t see how this would buy you
anything. If you call IMG_Load*_RW() from within the main thread,
that thread will be blocked until the leading and decoding is done,
no matter how the actual reading is performed.
You have to move “the whole package” to that other thread. (I think
SDL_image is thread safe, but I’m not sure. Forget about using SDL
blitters and stuff, though.)
Set up two lock-free FIFOs or something, and have the main loop
request images from the other thread. The loading thread would just
read requests off the FIFO, load the files and send the surfaces back
to the main loop through the other FIFO.
You can use my “sfifo” for this (check the mixed page on my site), but
of course, it’s lock-free and thus non-blocking, so if the loading
thread ever goes to sleep, you have to use other means of waking it
up. SDL sync primitives should cover that part. Alternatively, just
poll the request FIFO a few times/second when you have nothing else
to do. Not too sexy, but it’s an easy way to get started.
[…]
And yes, I think you’ll need an extra thread for this, or you’ll
have serious trouble getting smooth animation on most platforms.
but using threads means sometimes to have serious trouble in
: debugging.
Well, it does mean trouble at times. For example, you might not even
have a debugger that can handle threads properly. (Never could get
that to work on Mandrake - even installed the latest gdb from source.
Haven’t had any problems after I switched to Debian… Weird.)
My other idea was to read few bytes every time.
Yes, that could work in theory, but unfortunately, it depends totally
on the file system read-ahead doing what you want - and trust me, it
doesn’t. As soon as you hit the file system at the wrong time, you
simple have to wait until it decides to get your data. This could
mean tens or hundreds of ms.
In jpeglib - theres
a function to push bytes and then you get decompressed.
Cool…
But you are
right, the threads might be better because the disk might "seek"
for a while and then smoothnes goes away.
Yep. And I think it would be a lot easier to just plain load, unwrap,
chop or whatever you want to do in a worker thread, sending the data
off to the main loop as it’s ready.
BTW, there’s actually an advantage to “hog” the CPU quite a bit in the
loading thread. (So don’t be too careful about being nice, basicall!
This kind (ie burning lots of CPU and never sleeping) of behavior
is penalized by any serious OS, resulting in the dynamic priority
being lowered, so other threads can breathe when they occasionally
wake up. That is, the main loop will get higher priority than the
loader thread, and prempt it as intended, even if you can’t set
priorities explicitly. (And you can’t with the SDL API. And it’s not
much point either, as the OS scheduler will just undo your tweaking
anyway, if you try to give the hogs higher priority or something.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Tuesday 04 February 2003 11.47, obr at nri.cz wrote:
On Mon, Feb 03, 2003 at 06:46:34PM +0100, David Olofson wrote: