I'm using a Dell 2001FP LCD display, so not quite a TV, but it does have direct s-video input and can sync to either NTSC or PAL. I also don't have a camera handy so I'll try to describe thoroughly...
For NTSC:
The left 3 columns are duplicated on the right side and there is extra black space...
Your makefile is set up to build C++ source, not C. You need to set CC and CFLAGS instead of or as well as CXX and CXXFLAGS. (if you still want to use the makefile)
One of the conveniences I don't like so much with make... There's implicit rules that hide what's going on...
Sorry, I'm a little confused by your message -- are you replying to me?
What I'm saying is, the blitter has to clip to the drawing surface, because if it didn't it would write to bad places in memory. (unless it's a lower-level blitter, in which case you have to clip yourself before calling...
Where? Is your buffer larger than the screen?
If you have a buffer the same size as the screen and your blitter already clips to the buffer then you'd have to be drawing a LOT of sprites to see any benefit. And if you've got enough sprites for that to matter, you probably need to group them...
There has to be a faster way to do this than with alpha, though perhaps it might take directly fiddling with hardware registers. :/ Maybe something with the gamma tables?
If you're only drawing surfaces parallel to a screen edge, you can use Bresenham's algorithm to interpolate between screen and texture space using entirely integer math. As I understand it, this was used in Doom to make it run fast enough on the pitiful machines of the time.
I'm not completely...
They add the distance to x and y for the specified angle...
Is this overly complicated?
Any way to optimize these functions?
Don't use angles in degrees. Use angles in 256ths/512ths/1024ths of a revolution. Then use table-based sin/cos that returns a fixed-point value. You only need one...
You might consider using a struct, eg:
CODE
struct Pair
{
int firstPart;
char secondPart;
};
struct Pair *pair = malloc(sizeof(struct Pair));
pair->firstPart = 4;
pair->secondPart = 'L';
free(pair);
To be more precise, you need to pass the pointer that you got from malloc to free. You...
If you want hardware layer composition, you have to use YUV for the lower layers. If we had documentation for the hardware JPEG/MPEG decoding stuff, that may even be useful (since they're natively in YUV). As it is, the cost is too high and the benefit too low.
You are passing in the value of the pointer, but you can't change the pointer knowing only its value. You could just as easily pass in a pointer that doesn't have any address:
CODE
int i = 4;
repoint_existing_pointer(&i);
What you need to do is pass in the address of the pointer so the...
There's a way to get GCC to insert the fixups for you, but I don't remember exactly what the incantation is. It's the same as doing temp = (*(source+1)<<8)+(*source); anyway, just automated.
It's generally bad form to read multibyte values directly out of a file by casting, since it's not...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.