[epiar-devel] To thread or not to thread (the video code)
chris.r.walton at gmail.com
Sun Dec 27 02:19:02 PST 2009
I don't have time, but I've got alot to say about the subject. I'll write
out a more detailed email when I get back later.
On Sun, Dec 27, 2009 at 9:27 AM, Christopher Thielen <chris at epiar.net>wrote:
> In response to #1, it looks like Matt already filed the bug (
> http://epiar.net/trac/ticket/36). I've made it a blocking bug for 0.2.0.
> On Dec 26, 2009, at 11:47 PM, Christopher Thielen wrote:
> > I talked to ebos in #epiar last night and he runs Epiar on Debian in a VM
> that runs very slowly, about 8 fps. To fix this, he implemented some
> threading to separate out the drawing code, which is the slowest code. By
> doing this, he says the fps jumps to 10-20 fps.
> > A couple of questions and a debate starter:
> > 1) He said the game actually runs half speed at half fps. This should
> send off red flags right away. Who wrote the current timer we have? We must
> have a separation of game loop counts and real time. All position updates,
> etc. must be based on real time, not on the number of game loops, e.g. so a
> sprite covers just as many pixels per second regardless of whether the
> update loop runs twice a second or 10000 times a second. This must be fixed
> ASAP. It should be done in the Timer code, and we should also interpolate
> the coordinate positions (ask Arke or see Dan Olfson's SDL fixed rate pig
> demo (google that)).
> > 2) Anybody know why, if the video drawing code is in its own thread but
> still drawing just as slowly, we would see more frames per second? This
> makes little sense to me. Somebody please answer it.
> > 3) Here's the debate I want started: should we make a video thread or
> > ebos says yes. It runs faster on his VM, making his life better, and
> helping Epiar.
> > I say no. It's unnecessary to support his VM, or any computer that can't
> run Epiar at at least 16 fps (the minimum accepted imo for playability).
> It's also dangerous to thread unnecessarily. Threading causes timing bugs
> and memory violation bugs and even if you're careful and use a good design
> pattern, it can bite you in the ass. It should be avoided in areas where
> it's not necessary. Since implementing a proper interpolated timer
> (described in my #1) would solve his playability issues and any computer's
> playability issues, it needs to be implemented anyway, so why not just do
> the safe thing that we have to do and not do the dangerous thing that only
> helps one person? Additionally, it requires a lot of changes to the code:
> locking and unlocking variables, etc. I vote a very strong no and might
> reject it from the final tree if I'm not convinced.
> > Thoughts?
> > - Chris
> > _______________________________________________
> > epiar-devel mailing list
> > epiar-devel at epiar.net
> > http://epiar.net/mailman/listinfo/epiar-devel
> epiar-devel mailing list
> epiar-devel at epiar.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the epiar-devel