0 Members and 1 Guest are viewing this topic.
int keydown(int basic_keycode){ const unsigned short* keyboard_register = (unsigned short*)0xA44B0000; int row, col, word, bit; row = basic_keycode%10; col = basic_keycode/10-1; word = row>>1; bit = col + 8*(row&1); return (0 != (keyboard_register[word] & 1<<bit));}
The size of float based routines is really quite negligible and they don't use any extra ram because the entire executable is stored in flash. You could use a fixed point float in this situation but I would advise against them in this situation as the best way to write them out would be to use pre-defined macros such as TWO_POINT_FIVE which would be 0x00028000 in a 32 bit fixed point notation. The other alternative here is to specify when calling the function what size you would like to scale it to instead of providing a scale factor. Perhaps in this situation 2 different functions ought to be developed. One for rather straightforward scales that can be easily implemented such as x.5, x2, x4 and so on. This would be called as 2 raised to the x power. For example passing 0 as the scale will result in a sprite with no change in size while 1 will be x2, 2 as x4, 3 as x8, and so on. That would also mean that -1 would be .5, -2 as .25 and so on. The second routine would require much more overhead and be called with either a float factor or specify the new image size. If this sounds good I can start work on the first routine and have that out in not too long.
Quote from: z80man on November 01, 2011, 01:46:58 amThe size of float based routines is really quite negligible and they don't use any extra ram because the entire executable is stored in flash. You could use a fixed point float in this situation but I would advise against them in this situation as the best way to write them out would be to use pre-defined macros such as TWO_POINT_FIVE which would be 0x00028000 in a 32 bit fixed point notation. The other alternative here is to specify when calling the function what size you would like to scale it to instead of providing a scale factor. Perhaps in this situation 2 different functions ought to be developed. One for rather straightforward scales that can be easily implemented such as x.5, x2, x4 and so on. This would be called as 2 raised to the x power. For example passing 0 as the scale will result in a sprite with no change in size while 1 will be x2, 2 as x4, 3 as x8, and so on. That would also mean that -1 would be .5, -2 as .25 and so on. The second routine would require much more overhead and be called with either a float factor or specify the new image size. If this sounds good I can start work on the first routine and have that out in not too long. Bump-bi-di-bump the topic for asking someone to realize zoo-msacled sprite drawing function. That could be very useful to some animations..I think always that 2^factors would be easier and faster to use...moderator edit: fixed
I think you put your answer inside the quote Eiyeron
void CopySprite_Palette_Alpha_Nibbles(unsigned char* data, unsigned short* palette, int x, int y, int width, int height) { unsigned short* VRAM = (unsigned short*)0xA8000000; unsigned short* ptr = VRAM + y*LCD_WIDTH_PX + x; int i,j; unsigned char nibble; //Get the color's index to use. for(j=0; j<height; j++) { for(i = 0; i < width; i+=2) { nibble = (*data)>>4; We get the first pixel if(nibble) //First index is alpha. *ptr = palette[nibble]; //COpy from the palette nibble = (*data) %16; We get the second pixel if(nibble) //On the road again *(ptr+1) = palette[nibble];/* else *(ptr+1) = palette[0];*/ // FOr tests ptr+=2; //We go furtherer on the VRAM data++; //Idem } ptr += LCD_WIDTH_PX-width; // Go one line lower. }}
Sorry to go off topic, but z80man, PLEASE could you tell me how you got a gb emulator on your casio, and is there a way to run ti games on a casio?Edit: oh wait, I was on topic, lol, but is there something like ti-boy for casio prizm that converts file to calc format rather than running it as an emulator, or maybe even an emulator (I want Pokemon but emulators are usually too slow but I'm sure GBC will be fine with Prizm if can't use that method)
void CopySprite_Palette_Alpha_clipping(const unsigned char* data, const unsigned short* palette, int x, int y, int width, int height){ unsigned short* VRAM = (unsigned short*)VRAM_ADRESS; unsigned short* ptr = VRAM + y*LCD_WIDTH_PX + x; int i,j; int real_width = x+width > LCD_WIDTH_PX ? LCD_WIDTH_PX - x : width; int decal = x < 0? -x : 0; if(real_width <= 0 || decal >= width) return; for(j=0; j<height; j++) { ptr += decal; data += decal; for(i = decal; i < real_width; i++) { if(*data) *ptr = palette[*(data)]; ptr++; data++; } data += width - real_width; ptr += LCD_WIDTH_PX-real_width; } }
Author
Topic: Prizm Useful Routines -- post here! (Read 30254 times)
