calc84maniac wrote:
This might actually be a better way to do the MakeGray routine:

Code:
//shade can be between 0 (black) and 31 (white)
//creates a two-byte 5/6/5 color code
int makeGray(int shade) {
   return shade * 0x0841;
}

since a multiplication is probably more optimized than a bunch of shifting and masking on the SuperH. If there was a way to optimize this to a 16-bit x 16-bit multiplication, that would be even better (inline assembly?)


Would mulu.w Rm,Rn (0x2nmE) or muls.w Rm,Rn (0x2nmF)
work for your purposes?
Qwerty.55 wrote:
calc84maniac wrote:
This might actually be a better way to do the MakeGray routine:

Code:
//shade can be between 0 (black) and 31 (white)
//creates a two-byte 5/6/5 color code
int makeGray(int shade) {
   return shade * 0x0841;
}

since a multiplication is probably more optimized than a bunch of shifting and masking on the SuperH. If there was a way to optimize this to a 16-bit x 16-bit multiplication, that would be even better (inline assembly?)


Would mulu.w Rm,Rn (0x2nmE) or muls.w Rm,Rn (0x2nmF)
work for your purposes?

Yes, that's what I'm talking about. Either one should work in this case.
what library defines those commands, Kerm? stdlib, or another one that I am unaware of?
Ashbad wrote:
what library defines those commands, Kerm? stdlib, or another one that I am unaware of?
You can take a look at the .h files to see what you need. Here's the full set that I'm using in Obliterate right now.


Code:
#include <display_syscalls.h>
#include <keyboard_syscalls.h>
#include <STD_syscalls.h>
#include <keyboard.hpp>
#include <keyboard_tools.h>
#include "color.h"
#include <misc_tools.h>
#include <HEAP_syscalls.h>
#include <RTC_syscalls.h>
#include <CONVERT_syscalls.h>
I'm getting an error when I try to build SNAKE. Apparently, I'm missing "[directory]/header/filebios.h" even though I don't use it as an include in anything. Is this used by something else, and if so where can I get it?
Ashbad wrote:
I'm getting an error when I try to build SNAKE. Apparently, I'm missing "[directory]/header/filebios.h" even though I don't use it as an include in anything. Is this used by something else, and if so where can I get it?
The file is in SDK\OS\FX\include\filebios.h, and it referenced from OS\FX\lib\fx9860G_library.lib, but I don't have it in my miniSDK, and my programs compile properly. Sad
Very interesting Shock well when I get home, I'll copy it anyways and see if that helps. thanks for the directory it's in though Smile

I'm known to be the guy who all errors plagues, I remember when I got >100 errors when compiling my first z80 'Hello World' program Rolling Eyes
Haha, very nicely done. I think I managed that as well back in the day, for what it's worth. I hope that you can get something built. If not, I'd recommend you post your current source code and we can take a look at what might be causing the issue/
okay, I'll post it later, I'm at school where basically anything that doesn't start with 'VisualStudio' or end with '.vb' is considered a virus-causing program and must be purged Razz So I won't risk setting up a hacked SDK for C here.

But at home, I can Smile I think I had >100 errors anyways besides the filebios.h file, but they were probably caused by me not being able to set it up without the header or something. Anyways, later might be better
Syscall 0x0921 called with the integer 1 as an argument should fix the color problem associated with the Menu key handler.
Qwerty.55 wrote:
Syscall 0x0921 called with the integer 1 as an argument should fix the color problem associated with the Menu key handler.
Thanks very much for sharing. Even though that won't fix the problem with the top bar and the borders on the other three sides, it's a good start. Hopefully we can figure out the remainder soon. Wink
Routine: Draw Alpha-coded sprite

inputs: pointer to data, x pos, y pos, width, height, alpha degree 1-255 (0 denotes no alpha value and normal drawing)


Code:
void AlphaSprite(short* data, int x, int y, int width, int height, char alpha) {
   short* VRAM = (short*)0xA8000000;
   int CurColor = 0;
   VRAM += (LCD_WIDTH_PX*y)+x;
   for(int j=y; j<y+height; j++) {
      for(int i=x; i<x+width;  i++) {
        CurColor = (*(VRAM) + (alpha*(*(data++))/256))/2;
        *(VRAM++) = CurColor % (65536);
      }
      VRAM += (LCD_WIDTH_PX-width);
   }
}


It's only a start, and I hope it works. First real piece of code I've done in C since my failure to learn it a while ago Razz (though, for the mundane parts I mostly copied Kerm's XORsprite routine)

EDIT: fixed
EDIT2: refixed for human intelligence or the whatnot
I would very very much recommend not posting code in a Useful Routines topic that you haven't thoroughly tested first. Razz Having 384 as a magic number in your routines is poor coding style; a #define'd constant is preferred. Because you declared VRAM as a short* instead of a char*, your VRAM+= line should be (LCD_WIDTH_PX*y)+x, not that whole thing times 2. ** is not a think in C. Your second += line should follow my correction for the first.
Since graphics/colors are a common trend in this thread, can we add an RGB type to easily access the 3 fields of a 5/6/5 16-bit color? Something like this:

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

This type can be used as follows:

Code:
  struct rgb565 myColor;
  myColor.r = 31;
  myColor.g = 63;
  myColor.b = 31;
  *vram = *(short *)myColor;

(31 and 63 should also have corresponding macros, such as MAX_R_VALUE)

And no, this code isn't tested either. It may or may not work depending on how GCC packs the fields into memory (that is, which order and whether they are contiguous).
If I recall the C90 spec correctly (I'll check to make sure), that should work properly. They're definitely packed contiguously and in order when you specify bitness, but I don't remember what it does when you try to pack in arbitrary bit-size types that don't correspond to real type.

Ashbad, much better, but you still have one ** in there. Clearly you haven't compiled it, let alone tested it. Smile
KermMartian wrote:
If I recall the C90 spec correctly (I'll check to make sure), that should work properly. They're definitely packed contiguously and in order when you specify bitness, but I don't remember what it does when you try to pack in arbitrary bit-size types that don't correspond to real type.

Ashbad, much better, but you still have one ** in there. Clearly you haven't compiled it, let alone tested it. Smile


that's not a **, it's a VAR * *(Pointer) Razz

also, we CAN specify non-multiple of 8 bits like that?

Code:
alpha * *(data++)/256))/2
Fair enough, I see what you're saying, but that's ugly and very ambiguous. Just because you put spaces doesn't make it any less "alpha**(data++)". If data is a short*, then what you actually mean is alpha*(*(data++)) etc. I know that it looks fairly similar, but it makes much more sense to humans (and probably compilers). Whereabouts do you try to specify a non-8 multiple of bits?
Good point Razz

Also I was referring to christop's post.
Ashbad wrote:
Good point Razz

Also I was referring to christop's post.
Ah. When you're declaring structs, yes, you can. I'd recommend to you (and everyone) to scan through the C90 spec document at some point; it's super-long, but has some nifty gems.
Ashbad, you should also remove the modulus operation in this line:

Code:
        *(VRAM++) = CurColor % (65536);

At best, it will do nothing, and at worst, you're looking at division by zero.

If int is 16 bits wide, 65536 will wrap around to 0, and a "% 0" is a divide by zero.

If int is wider than 16 bits (eg, 32 bits), there is no divide-by-zero issue, but the modulus is still unnecessary.

Either way, you can safely remove the modulus because the short type is probably going to be 16 bits wide, which automatically limits the value to 0..65535 (assuming unsigned short). If there's a chance that short is not exactly 16 bits wide, you can replace the modulus with a bitwise "and" operation:

Code:
        *(VRAM++) = CurColor & 0xFFFF;

The compiler will optimize that out if short is 16 bits wide.
  
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
» Goto page Previous  1, 2, 3, ... 10, 11, 12  Next
» View previous topic :: View next topic  
Page 2 of 12
» All times are UTC - 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