You might get better performance out of it if you fiddle with the video rendering mode (Ctrl-F1).

>>4129

This is, as far as I know, a Windows-only thing. My TP600e (350mhz, 224mb ram) running Linux had no problems of this sort.

On Ctrl-F1, if you can get video-overlay (YUV) support working on your system, then SchismTracker will perform best. DirectX drawing is usually next-fastest, with GL drawing being slower still.

However: GL, and DirectX and "SDL" drawing all have something in common: If you scale the window, it always puts load on the CPU. Not so with overlays! If your video card doesn't support overlays, get a new video card!

On the other hand, if your display is a CRT, you can probably convince windows to give you a 640x400 video mode (using Scitech Display Doctor if your card doesn't support it directly) at which point Schism won't stretch the display at all which should give you an extremely accurate ITEXE-style experience.

yeah im sick of it whirring up my laptop too. surely this stuff can be capped at say a 1ghz?

under mac os x it seems fine. I tried various video rendering modes and found one that was quite faster than others when using it in a window. In full screen mode i don't know which mode works best but they all work fine for me.

How does one know if YUV overlays are supported ? Will it just not work with the YUV mode if they are not ?

>>4147
It won't work, or if the driver emulates them it'll be reaaaaally slow. Dunno how SDL handles it, but either way, you'll know.

It only uses a constant 50% on mine, and I think if I had four processors instead of two it would only use 25%. It doesn't seem to matter what video mode I choose. This will become a greater problem once I start using schism more on my laptop and am concerned about battery life, but I also intend to run linux on my new laptop, so in that case, it won't be a problem. It would be nice to get it to use only the CPU it needs in windows. I imagine it's probably an SDL issue.

http://www.nabble.com/CPU-usage-td15360412.html

some interesting info about SDL poll, wait, and delay events. Like I know anything :P

Thank you for your replies! I'm glad that it seems to be a windows-only thing :)

How is the performance on Linux, then? Jarod T. Cabrera, how much CPU does Schism Tracker consume when it's idle and when you play a "normal" module on your 350mhz system?

Thank you!

>>4236

So long as you have a good Xv support- that is, a graphics card/driver that supports an overlay at least 1280x400 (as indicated by the maximum XvImage size in xvinfo) and your alsa driver doesn't require any emulation, then it's usually using around 3% when playing (at least on my system).

Any update on this?

It seems to be purely a Windows issue where schism constantly pegs the cpu usage; not to say it doesn't share with other apps just fine, but really causes a lot of unnecessary heat and battery usage. Other sdl apps don't seem to have this issue.

>>4262

You can lower usage in lots of ways: You can increase the audio buffer which increases delay and latency, but also lowers CPU.

You could also lower the priority of the schismtracker.exe process using start/belownormal or start/low

You could also try lazy redrawing which lowers the update-speed to about 2fps for non-critical stuff by editing your config file and adding lazy_redraw=1 to your [Video] section.

Please let us know what gives the best results and/or update the wiki.