we used draw the screen at once

we switched to line drawing to more compatible (e.g. palet changes during drawing) and some other reasons

But harekiet can answer this better.

Ah, and another one. Is there a compelling reason for the OPL3 code to use integer math? Would FP-math (or rather, SSE) break anything? I've read a comment which talks about losing precision by intention, so I'm not sure if that would be an alternative...

(Background: the sine table lookup in chan_calc is responsible for lots of L1 cache misses, oprofile tells me. Since hq2x uses lots of mem, the opl code is affected by it. As part of my Pentium3 optimization, I'd like to try moving both pieces to SSE, hopefully eliminating a few lookup tables and thus increasing speed.)

We used to draw the screen at one when it was still running in another thread, but made it the graphics update part of the main thread and if you don't want to delay the rest of the machine too much you split it up in lines.
And the compelling reason why opl3 uses integer math since it works and i can't really care to rewrite it 😀

@MOE: I hate to spoil your fun, but I think that you should not specialize so much on one processor if you want sometimes in future to have your work integrated into DOSBOX (as opposed to a separate patch).
DOSBOX runs on different processors (not only Intel). Some are Intel compatible (Athlon), some not (there is e.g. version of DOSBOX for Apple etc.).

Doing specialized version for just *one* type of Intel processor is IMHO not the way forward. Personally I doubt it will help very much anyway (but I admit I may be wrong here). DOSBOX has one processor dependent part (dynamic core), but this is specifically marked and generally separated (and DOSBOX does not need it).
Making other processor type dependent parts (or even Intel dependent parts) does not help much.

Mirek

Harekiet: thanks alot. I'm still not sure where to go from here, but I will do some testing to see if it could be worth the effort.

Is there anything I should watch when throwing SSE at different code? Most importantly, I'd like to use the intel compiler syntax, i.e. no assembler, but built-in functions that result in the given instruction. GCC understands those functions as well, so it would work cross-OS, only I don't know if borland/ms/... understands it. (Rationale: The compiler knows much better how to order instructions and allocate registers than me.)

mirekluza: Look at the hq2x code. It is cross-platform. And fast. And yet, dosbox isn't fast enough to run on a 733MHz box (my new testing platform) or even 333MHz (my laptop, importqant target for me), so I wanna do something about it. And face it, people are using intel a lot, so my work will definitely not be wasted. And no one is talking about making a version specific to one CPU. SSE is available on all CPU's from P3/Athlon-Tbred upwards. The P2 optimizations were made in a way so that later CPUs or even other architectures gain as well. I ain't that short-sighted.