PocketMatrix

From my reading, Digby meant:

"Test both ways and see which is faster rather than assuming one way is better".

(And I concur as always ).

You want to look at circular buffers though (well, sort of circular buffers). If you always plot in one or two chunks, then you never actually have to move memory around - for your example, you just plot row 5 as one chunk then plot rows 1-4 after it... no movement of memory necessary. Just keep a record of the next row you need to zap/change.

E.g. (space denotes moving the address in the source)

12345
5 1234
45 123
345 12
2345 1
12345

No movement necessary.

(And if you're actually reading stuff from screen-memory to write it back to screen memory, performance is going to be abysmal because the screen isn't buffered or cached on most devices).

Cheers,

Ref.

The buffers I'm using are not the real screen buffer, I understand what you mean about scrolling buffers, and thats what I would use, but Im introducing new data all the time e.g:

12345
23456
34567
45678
56789

etc etc (the rotated section gets drawn over, i.e where the 1 would be in line 2, gets replaced with a 6... etc.

(I could not move the rotated data that will get drawn over, but at the moment I'm leaving the funcs generic....)

-B

But if you're only moving the screen down or up then it doesn't matter if you're adding new rows... just add them where the row you've just removed was and you've still got a single buffer (if segmented) screen-sized buffer that you'll never have to move/copy in memory...

smarty pants....

that could get messy with left and right shifting as well, my brain is not up to thinking about that this early in the morning....

you would have to have an x and y offset's into the buffer.... might not be too bad as long as you can do somthing simple to work out the writing to the buffer, i.e one it gets to the end, going back to the start.....

then what about copying the said buffer to the screen buffer...? I normally use a memcpy... this would have to be replaced with a custom func to handle it!

-B

You're right; with X shifts involved, it gets a little messier.. but not that much. I think you'll be alright if you're plotting into your "buffer" in rows and you have an "extra" line at the end of the buffer. That way, you *still* have a contiguous block of memory to shunt into the screen memory.. well in one or two chunks anyway

For the X, it's the same way of updating as the Y - you just plot to the last column(s) that went off the screen. Then you just use the offset to dump the buffer into screen memory and there's your X-Y scroller without any extraneous memcpys (and only a little bit of extra handling working on the buffer wrap-around... which is definitely faster than a large memcpy).

I'd advise getting some paper and drawing lots of pictures ... So long as you can start at any point and draw a full 320 pixel row you're alright. Columns are a little trickier and may need a wrap-around adding (like if(column>240) {column-=240;}).

For the sake of speed, I'd probably lose a bit of scrolling granularity on the PocketPCs and scroll 32-bits at a time = 2 pixels. The 1-2 pixel jump probably isn't all that visible and it'll be much faster plotting 32-bit chunks rather than worrying about aligning things or plotting 16-bits at a time.

Anyway, I'm sure you can work it out. I'm off to bed.

Cheers, g'night ,

Ref.

Atm speed is not a "huge" factor, and my "game" is pushing good frame rates on my e-125, I suspect it may only be an arm game in the end but. Once I add music, sound and the final touches, it's bound to slow it down..... (beside this game is just a "quickie".... (see other post on random 2D Platform generation)

-B

Brendan - there's never a real excuse for not doing it "properly", IMHO

AngelDeLaMort - sounds weird. I can understand 32-bit being slower if you gave memcpy a non-32bit-aligned source/destination... but other than that it should be faster. Post the assembler if you want and we can ogle it.

Cheers,

Ref.