Re: CoreGraphics questions
Re: CoreGraphics questions
- Subject: Re: CoreGraphics questions
- From: <email@hidden>
- Date: Sun, 10 Jun 2001 14:50:42 -0600 (MDT)
Cool, I was hoping for a Cocoa way. Another question:
I was piloting a spaceship in my game by moving it on kEventRawKeyDown and also
kEventRawKeyRepeat, but there was a noticable delay between moves which I
assumed was my slow blitter, but then I tried moving a few times in a for loop
and there was no delay between moves, so I decided the blit is very fast, but
the key repeat rate is what is slowing it down. So, is there some way to receive
RawKeyRepeats more frequently? Or, can i begin a while loop when I receive a
RawKeyDown and quit the loop on a key up:
if(event==RawKeyDown)
{
while(keyStillDown)
{
move;
blit;
}
}
I wouldn't normally be so concerned, but since this is a game it needs to be
pretty fast.
Thanks,
Harold Cooper
email@hidden
email@hidden
email@hidden
http://physoft.n3.net
On Sun, 10 Jun 2001, Andreas Monitzer wrote:
>
> I'm trying to write a simple game for OS X using CGDirectDisplay. I
>
> set a 640x480x8-bit mode and then create a corresponding buffer (unsigned
>
> char*)
>
> Currently, to blit, I map the base addresses of the screen and buffer to
>
> double
>
> pointers and then copy from the buffer to the screen. This appears to be
>
> faster
>
> than <mem.h>'s memcpy, but it still seems sort of slow. Is there a faster
>
> way to
>
> blit?
>
> I am also unsure of how to handle events. Currently, I am using carbon
>
> events to
>
> receive kEventRawKeyDown, which works, but I want to move sprites around
>
> during null events soon, and I don't think event timers will be fast
>
> enough. Is
>
> there a very simple way to check for keyboard events in a loop? I might
>
> use a
>
> WaitNextEvent loop, but it seems so un-OSX, and I rad somewhere that it is
>
> implemented via Carbon Events anyway. So: what's the best way to handle
>
> key
>
> presses if I don't care about other apps (since the user can't see them
>
> anyway)
>
> Basically, I'm looking for any tips for a newbie OS X game programmer.
>
>
I'd subclass NSApplication and implement sendEvent:(NSEvent*)anEvent (don'
>
t forget to do a [super sendEvent:anEvent];, otherwise there will be
>
strange problems). That's the cocoa way of doing it (and that's how Quake
>
]|[ was implemented by Omnigroup).
>
>
andy
>
--
>
Description forthcoming.