On Mon, Mar 17, 2008 at 6:50 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > problems with the arrow keys that I could find. The only thing I > wondered about is that changing the direction the sprite faces also > makes it moving ahead one square.
Most rpgs I know of work this way, so Michael is working within the standard. Although maybe the standard is not so good :) To Michael, I think you are making a great start with this, and the code looks very clean and well designed. Scrolling the screen can be tricky if you have never done it before, but it is not too complicated. The biggest loss with screen scrolling is that (at least if you are smooth scrolling) dirty rects basically go out the window - the entire screen becomes the dirty rect when it is scrolling. The main idea, is to have a camera offset value, and then every time you draw you subtract that value from the x and y of what you are drawing. This way, most of your code doesn't have to be changed, as you are working with the same coordinates for everything. The only code that has to change are the blits. screen.blit(image,[x,y]) becomes screen.blit(image,[x-cam_x,y-cam_y]) Test this step of the code, before you worry about scrolling, by setting the cam_x and cam_y to different values. Once you have this, you can detect where the player is going to be drawn (player pos minus camera offset) to determine if the screen should be scrolled. Here's some pseudo code for that: screen_x = player_x - cam_x screen_y = player_y - cam_y screen.blit(player,[screen_x,screen_y] if screen_x>(screen_width-100): cam_x+=scroll_speed if screen_x<100: cam_x-=scroll_speed if screen_y>(screen_height-100): cam_y+=scroll_speed if screen_y<100: cam_y-=scroll_speed Then, the camera will scroll when the player is 100 pixels from any screen edge. This is of course not directly applied to your project, but you should be able to figure it out. I hope to see more of this project in the future. The world can never have too many rpgs :)
