Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
The short is indeed always 16 bits on the Prizm, and I think there are very few platforms that would be awkward enough to have a short that is not 16 bits wide, I hope. Smile
KermMartian wrote:
The short is indeed always 16 bits on the Prizm, and I think there are very few platforms that would be awkward enough to have a short that is not 16 bits wide, I hope. Smile

The one platform that I am most familiar with that doesn't use 16-bit shorts is the PDP series of minicomputers. Some of those used 18-bit shorts and 9-bit chars. Very Happy
But even that shouldn't be too awkward to use in C unless you do a lot of heavy bit twiddling. As a bonus, you get 36-bit longs, which have 16 times the range as 32-bit longs (32 billion).
Ah yes, the infamous 9-bit byte PDPs. Smile Sadly, it seems that an inordinate number of mt programs do end up doing odd bit-twiddling tricks; maybe I'm (too) used to working in low-level languages. Anyway, getting this show back on-topic, I have a CopySpriteMasked routine that treats one specified color as "transparent":

CopySpriteMasked

Code:
void CopySpriteMasked(const char* data, int x, int y, int width, int height, int maskcolor) {
   char* VRAM = (char*)0xA8000000;
   VRAM += 2*(LCD_WIDTH_PX*y + x);
   for(int j=y; j<y+height; j++) {
      for(int i=x; i<x+width;  i++) {
         if ((((((int)(*data))&0x000000FF)<<8) | ((((int)(*(data+1))))&0x000000FF)) != maskcolor) {
            *(VRAM++) = *(data++);
            *(VRAM++) = *(data++);
         } else { VRAM += 2; data += 2; }
      }
      VRAM += 2*(LCD_WIDTH_PX-width);
   }
}
Generate pseudo-random number

input - 32bit integer for upper and lower bounds

this is based on the famous '128bit shifting' technique, and is considered highly random enough.


Code:
int Rand32(int lower, int upper) {
  static int a = 123456789;
  static int b = 362436069;
  static int c = 521288629;
  static int d = 88675123;
  int t;
 
  t = a ^ (a << 11);
  a = b;
  b = c;
  c = d;
  return (d = d ^ (d >> 19) ^ (t ^ (t >> 8)))%upper + lower;
}
What's the source for your algorithm for that, Ashbad?
it is based on this: http://en.wikipedia.org/wiki/Xorshift

also,

Test a pixel of CURRENTLY rendered VRAM image

inputs: X and Y position
outputs: short holding color value


Code:
short GetPXColor(short x, short y) {
   char* VRAM = (char*)0xA8000000;
   char a = *(y * LCD_WIDTH_PX + x * 2);
   char b = *(y * LCD_WIDTH_PX + x * 2 + 1);
   short c = a << 8 + b
   return c;
}
Not bad. My getpoint looks like this:


Code:
//gets color of point (x0, y0)
int getpoint(int x0, int y0) {
   char* VRAM = (char*)0xA8000000;
   VRAM += 2*(y0*LCD_WIDTH_PX + x0);
   return ((((int)*(VRAM)) << 8) & 0x0000FF00) | (((int)*(VRAM+1)) & 0x000000FF);
}
hmm -- would the addition I do have any difference when compared to your or-ing? could it possibly interfere with the topmost 8 bits?
More importantly, I fail to see why you're both using char* when accessing 16-bit chunks in the native byte order. Provided there's no odd alignment requirement on VRAM (which seems unlikely, given that GetVRAMAddress returns a void*), this would be a little faster:

Code:
unsigned short getpixel(int x, int y) {
    unsigned short *VRAM = (unsigned short *)0xA8000000;
    return *(VRAM + (y * LCD_WIDTH_PX) + x);
}

And maybe if you want to extract color channels from a pixel..

Code:
typedef struct {
    unsigned r : 5;
    unsigned g : 6;
    unsigned b : 5;
} color_t;

color_t getpixel(int x, int y) {
    ...
    return (color_t)*(VRAM + (y * LCD_WIDTH_PX) + x);
}
well you can't blame me, I'm a C newbie, I wasn't really aware you could do that Razz *turns to Kerm*

also in that case, new routine:

Invert Colors in Rectangular Area

inputs: shorts for x position, y position, length, and width
outputs: look at your screen! Cool (if you actually render it)


Code:
void InvArea(short x, short y, short height, short width)
   unsigned short *VRAM = (unsigned short *)0xA8000000;
   for(short a = 1; a>width; a++) {
      for(short b = 1; b>height; b++) {
         *(b + y * LCD_WIDTH_PX + a + x + (VRAM++)) ^= 0xFFFF;
      }
   }
}
Tari wrote:
More importantly, I fail to see why you're both using char* when accessing 16-bit chunks in the native byte order. Provided there's no odd alignment requirement on VRAM (which seems unlikely, given that GetVRAMAddress returns a void*), this would be a little faster:

Code:
unsigned short getpixel(int x, int y) {
    unsigned short *VRAM = (unsigned short *)0xA8000000;
    return *(VRAM + (y * LCD_WIDTH_PX) + x);
}

And maybe if you want to extract color channels from a pixel..

Code:
typedef struct {
    unsigned r : 5;
    unsigned g : 6;
    unsigned b : 5;
} color_t;

color_t getpixel(int x, int y) {
    ...
    return (color_t)*(VRAM + (y * LCD_WIDTH_PX) + x);
}


What's with the Getpixel syscall? You could just read the word straight from memory.
Qwerty.55 wrote:
What's with the Getpixel syscall? You could just read the word straight from memory.


That's exactly what we're doing Razz
Um, then you might want to change the name to avoid confusion with the real Getpixel syscall.
that's why ours are called 'GetPXColor' and 'getpoint' Razz and Tari's was just an example he made in ~30 seconds, to show us a point.
Okay. Shouldn't that be: Return (384*Y+2*X+0xA8000000)?
GCC will optimize it for us. Plus, the way you did it doesn't specify it as a pointer, or size of return.
Well, the point is that (0xA8000000+(384*Y)+X) won't point to the proper word. You have to account for the 16 bit color size, which requires ROTL X (or X*2).
But it does when I make VRAM a unsigned short*, since that's how C pointer arithmetic works.
Ah, so C expands the arithmetic?

It seems unnecessarily complicated to force to programmer to remember types, but it's convenient for source size I suppose.

EDIT: Since Ashbad posted his RNG, here's an LCRNG in [partially] optimized Assembly.


Code:
SH3 Assembly:
   MOV R2,R3
   SUB R0,R3
   MOV $20,R4
   DIV0U R0,R1
Startdiv:
   ADD $FF,R4
   DIV1 R0,R1
   TST R4,R4
   BT/S Startdiv
   ROTCL R2
   DMULU.L R2,R3
   STS MACL,R3

   ROTR R0
   BF/S LoadX
   MOV $17,R3            // Load A
rngStart:   
   DMULU.L R1,R4
   MOV.L @(dd*4+PC), R0   // Load M
   STS MACH, R2
   
   MOV R2,R3
   SUB R0,R3
   MOV $20,R4
   DIV0U R0,R1
Startdiv2:
   ADD $FF,R4
   DIV1 R0,R1
   TST R4,R4
   BT/S Startdiv2
   ROTCL R2
   DMULU.L R2,R3
   STS MACL,R2
      
   RTS
   $05F5 E101
LoadX:
   MOV @(dd*4+PC),R1      // Load X_0
   BRA rngStart
   NOP
   $02D6 3A86


The answer is in R2, if you care to extract it.
first custom test routine here Smile

Print Custom Character

inputs: an x position, a y position, a bit mapped image of the character, color to draw the character, if it is to draw white in non-mapped spaces, and the dimensions of the character
EXAMPLE BIT MAPPED CHARACTER (the letter A):
[0,0,1,0,0]
[0,1,0,1,0]
[0,1,1,1,0]
[0,1,0,1,0]
[0,1,0,1,0]
outputs: look at your screen Smile (unless you don't render it)




Code:
void PutCustC(*bool map, short x, short y, short width, short height, short color, bool DrawWhite) {
     short* VRAM = (short*)0xA8000000;
     VRAM += (LCD_WIDTH_PX * y) + x;
     for(short a = 0; a>width; a++) {
               for(short b = 0; b>height; b++) {
                         if(*(y + b * width + x + a + map)) { *(VRAM++) = color; }
                         elseif(DrawWhite) { *(VRAM++) = color; }
                         else { VRAM++; }
               }
               VRAM += (LCD_WIDTH_PX-width);
     }
}
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 12
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement