Re: [pygame] Hardware Accelerated Scrolling Text

[Steve Castellotti <steve@theProfessionalAmateur.com>]

Daniel-

	Actually, that was a huge help, there were at least two things I was
doing wrong:

- using DOUBLEBUF and update()  .. I'm now using DOUBLEBUF and flip(),
or just update(), as you've suggested. I'll need to test which looks
best under high load...

- using pygame.time.delay() instead of pygame.time.wait()


	Mainly I'm down to ~10% CPU usage on a P3 1.0 Ghz, which is a major
improvement! delay() must not release the processor, it was just my
assumption that was happening. I'm now able to move 1 pixel at a time,
with a 20 ms delay .. it looks quite smooth.


	Part of what I'm trying to do is display other applications (like live
video) on other parts of the screen, with scrolling text in a another
section. Using a pygame window is the easiest way to do that at the
moment.


	Of course, I still think it should be possible to leverage hardware
accelered blits though OpenGL, and relieve the processor that much more,
but at least now I'm down to a manageable level (c:

thanks again,

Steve Castellotti


On Fri, 2004-08-27 at 05:25, Daniel Dornhardt wrote:
> Hello Steve,
> 
> the 100 % CPU - Issue:
> 
> if you have an inner game loop like
> 
> quit = 0
> while guit == 0:
>     check_events()
>     do_game_logic()
>     paint()
> 
> or any other inner loop which runs the whole time, you are telling the 
> computer to use every available clock cycle for the next step in your 
> program.
> 
> This is quite normal and wanted, normally, because you want to run your 
> game at the highest framerate possible. Most games do that, that's why 
> quake II still uses your cpu to the max, it'll just render more frames 
> in the same time than when it was released.
> 
> But you can give other processes a window to do stuff somewhere in your 
> inner loop. Pygame has a function
> 
> pygame.time.wait(time_in_ms) for this.
> 
> it returns the actually waited time in ms. It isn't super - precise, but 
> a pygame.time.wait(1) in your inner loop will give the os and other 
> processes enough time to do their normal stuff (no more system lagging 
> because of pygame app).
> 
> if you pygame.time.wait() for longer delays i guess you can drop the cpu 
> - usage of your app.
> 
> but normally it's ok for a game to use the max cpu, as long as it gives 
> the rest of the system a little time now and then.
> 
> for smooth scrolling you should use double buffering,  add DOUBLEBUF to 
> your display init:
> 
> surface = pygame.display.set_mode((640,480), FULLSCREEN|DOUBLEBUF)
> 
> and use
> 
> pygame.display.flip()
> 
> to update the screen.
> 
> If you don't use double buffering, you should only 
> pygame.display.update() the region(s) which changed, so if you know the 
> scrolling text is in the middle of the screen, just update the area 
> where the screen is changed. If the top and bottom third of the screen 
> is black anyways, just update the middle third and triple your framerate.
> 
> The last thing, which is a little more complicated, is making the whole 
> application timer - based, which leads to the best results on computers 
> with different speeds anyways.
> 
> Let a timer run in your main loop,  and give the moving stuff (your 
> text) a speed of, let's say, 20 pixels per second, that would be one 
> pixel each 50 milliseconds.
> 
> Calculate the movement by dividing the milliseconds elapsed through the 
> scrollingspeed (elapsed / 50) and place the text where it should go 
> after that calculation.
> 
> Now it moves at the same speed no matter which framerate is used and 
> should appear smoooth and nice and everything.
> 
> Sorry if you already tried all that and it wasn't useful in some way, 
> you should give some example code in that case.
> 
> All the best and everything
> 
>     Daniel