RLP Bitmap rotation demo

Archive
1

As requested in http://www.tinyclr.com/forum/17/2944/ I’ve put the demo source on http://code.tinyclr.com/project/295/rlp-bitmap-rotation-demo/

Enjoy!

2

Great demo!

Thank you!

3

My assembly isn’t what it once was so when you posted up your example I managed to modify it to work on my 480x272 screen and then pretty much stopped there.

However I was looking at it again today and I think I’ve got a good enough understanding to make my new project (Game Slate) 100% RLP rendered. :smiley:

I won’t have a chance to check this out for awhile (busy, busy schedule) but if the code works it’ll mean full alpha support on graphics and I may even release the render bit open source.

Thanks again!

4

Building an alpha blending engine was also on my todo list, but somewhere at the end :slight_smile:

Are you using an EMX?

On EMX it feels like memory access is too slow to build a decent gfx engine.

Maybe question for GHI, is it possible to render to internal CPU memory and copy the buffer to the screenbuffer? Or even better, is it possible to use the internal memory as LCD buffer?

5

I am using the EMX and I agree that the memory access is a bit slow (your demo really slows down at 480x272) but I think it will be enough for what I have in mind, or at least faster than managed.

  1. Setup a byte array for the screen (all drawing will be done here)
  2. Setup a flush methods (full & area) for the array

With this things like Pyxis 2 should see an increase in rendering speed plus the ability to put in alpha-blending, which on the managed side just takes too much time.

As for Game Slate I’ve found [italic]most[/italic] of the rendering time on maps with large numbers of sprites is spent just going through loops. Leveraging RLP will let me do all that collision detection faster as well. Not to mention full alpha-blended sprites. :smiley:

I think the combination of these things might be something nice to see and with clever flushing should make up for the RLP overhead & memory access speed. Honestly I think an whole new version of Pyxis will eventually be on it’s way where the entire API is over in RLP using loops, timeouts and events.

Here’s my SetPixel code; if this is correct then I do actually understand what I’m doing and the flushes and other methods should work fine as well

#include "type.h"
 #include "LPC23xx.h"
 #include "RLP.h"
 
 #define SUCCESS                0
 #define ERR_ARG_COUNT        -1
 #define ERR_ARG_SIZE        -2
 
 #define LCD_BASE_ADDR        0xFFE10000
 #define LCD_UPBASE           (*(volatile unsigned long *)(LCD_BASE_ADDR + 0x0010))
 
 #define LCD_PIXELS_X        480
 #define LCD_PIXELS_Y        272
 #define LCD_PIXELS_TOTAL    (LCD_PIXELS_X * LCD_PIXELS_Y)

int LcdSetPixel(unsigned int *generalArray, void **args, unsigned int argsCount, unsigned int *argSize)
{
    WORD * p = (WORD *)LCD_UPBASE;
    WORD color = 0x0000;
    
    // Use supplied color (if any)
    if ((argsCount == 1) && (argSize[0] == 2))
        color = *(WORD *)args[0];

    // Adjust the value of p
    p += (*(int *)args[1]) + (*(int *)args[2] * LCD_PIXELS_X));

    asm volatile (
	"mov    r3, %0"            "\n"    // screenbuffer
	"mov    r1, %1"            "\n"    // color
	"strh   r1, [r3]"          "\n"    // Store the color
	: // No output registers
	: "r"(p), "r"(color) // Input
	: "r1","r3","cc" // Clobbered registers

    return SUCCESS;
}
6

I would calculate the offset in asm. See my post ‘bottleneck’ for a putpixel implementation. You could multiply with the width of your display instead of using the shift trick.

Also keep your eye on the generated asm code by the compiler in the lst file. Somethimes when changing c code order or style can generate shorter code.

7

By the way GCC, generates horrible code when optimization is not turned on so always use optimization options, even -o1 makes big difference

8

Thanks for the tip!