15bit to 16 bit

[refractor]

[R0B]

I think I remember hearing about this from somewhere else. I will probably just make an ipaq version and a nonipaq version. If you notice, ziosoft ran into the same problem with their tiger woods golf, and that is why there is two versions. Try to switch to landscape on the e200, and the screen becomes all garbled.

[R0B]

[refractor]

[R0B]

[billcow]

[refractor]

[R0B]

Those are some very interesting concepts that you have taught me. Now, here is the thing. Because of the way casio has their vram set up(it's 240x320, not 320x240), you have to perform a rotated blit for landscape mode, which means that every pixel is 480 bytes apart in a row (this is in landscape mode). So, is there a way to copy 2 pixels at a time with this setup?

[refractor]

Well, the screen is still usually a linear buffer... i.e. a contiguous chunk of memory.

So, it really shouldn't shouldn't matter the orientation of the screen. Just because GAPI tells you you have to do stupid things like move the pointer along 480 to access the "next" pixel horizontally doesn't mean that you have to play by its rules and actually do it.

Ask GAPI to give you the start address of the screen and the orientation, and then shove a full, contiguous row/column into it (depending on the orientation), and move along to the next row/column (on the iPAQ you don't even need to move along to the next row, but on some devices you might). All you've got to do is watch out for variations in the "pitch".

If you're plucking pixels from a rotated buffer it should be fairly simple to pick them out two at a time, transform them and plot them.

If you always try and load and store in the same "grain" as the memory/cache-lines you're going to produce fast code.

If you start loading and plotting 16-bit pixels one at a time, all over the memory it's going to be slow as hell. You need to try to do at least one side of things (loading or storing) contiguously in memory.

Cheers,

Refractor

[R0B]

[refractor]

You might not be grabbing pixels from contiguous blocks, but you should be able to store them contiguously. Even if you load eight individual pixels from your (rotated) source using LDRH then transform and store them using a STMIA you're going to gain speed, IMO. Essentially you want to implement a simple form of write-buffering.

You should at least try and combine the operations, otherwise you're just loading and processing the same data over again (and a screen-full of data is much larger than the cache so the cache isn't going to help).

Cheers,

Refractor

[britcode]

[billcow]

[refractor]

Non-contiguous is bad because on a cached area of memory, every read loads an entire 32-byte cache line (and stalls the data bus while it's doing it). The same kind of thing goes for writing - if you're writing contiguous blocks of memory to a buffered area then the write-buffer is used and you get less stalls on the data-bus.

As billcow says, though, the screen on most systems isn't actually cached, or buffered, so writing to the screen isn't affected as much as writing elsewhere... but IMO it's almost always worth doing it "properly".

Cheers,

Refractor

[Varkentje]