I've thought about that, actually, and think at least having toroidal would be cool. Can you explain how klein bottle and moebius strip would work?
merthsoft wrote:
I've thought about that, actually, and think at least having toroidal would be cool. Can you explain how klein bottle and moebius strip would work?
Either the top/bottom or left/right edges would be "twisted" across their center-line.
merthsoft wrote:
I've thought about that, actually, and think at least having toroidal would be cool. Can you explain how klein bottle and moebius strip would work?
Take a look at this online GoL demo that shows some cool geometries and examples of a bunch of nifty stamps. 
Bug:
Bdisp_EnableColor(1) in GoL is missing, colors are not properly drawn. The color edit screen gets jumpy with fewer colors.
GetKey is a blocking function, resuming after pressing {MENU} keeps the program stopped.
Bdisp_EnableColor(1) in GoL is missing, colors are not properly drawn. The color edit screen gets jumpy with fewer colors.
GetKey is a blocking function, resuming after pressing {MENU} keeps the program stopped.
AHelper wrote:
Bug:
Bdisp_EnableColor(1) in GoL is missing, colors are not properly drawn. The color edit screen gets jumpy with fewer colors.
Not a bug so much as that syscall wasn't known when I made this.
Bdisp_EnableColor(1) in GoL is missing, colors are not properly drawn. The color edit screen gets jumpy with fewer colors.
ibid. wrote:
GetKey is a blocking function, resuming after pressing {MENU} keeps the program stopped.
Same thing. This was (maybe still is? I dunno) the best way to handle quitting, since the other key routines don't handle the Menu key. merthsoft wrote:
AHelper wrote:
Bug:
Bdisp_EnableColor(1) in GoL is missing, colors are not properly drawn. The color edit screen gets jumpy with fewer colors.
Not a bug so much as that syscall wasn't known when I made this.
Bdisp_EnableColor(1) in GoL is missing, colors are not properly drawn. The color edit screen gets jumpy with fewer colors.
ibid. wrote:
GetKey is a blocking function, resuming after pressing {MENU} keeps the program stopped.
Same thing. This was (maybe still is? I dunno) the best way to handle quitting, since the other key routines don't handle the Menu key.Heh, I know that the game was out from before knowing as much as now, but I just wanted to poke the info as a possible update.
Well, I have been doing some testing, and here is a way to handle the menu key:
Code:
if(GetKeyWait_OS(&kcol,&krow,2,0,0,&key))
{
if(kcol == 4 && krow == 9)
{
// Returned from pressing menu
Bdisp_EnableColor(1);
// clear and redraw
}
}I have tested all of the parameters. When pressing menu, it blocks until you get control again. Anyone know how to make this function not block (tiny timeout)?
Yeah, I should probably go through the game and Minesweeper, and update them with the new information we have. As for the key routine, I've got no idea what the best way to handle that is.
I think just replacing getkey with the above function should work. I can try recompiling your source later on with that, but I was already doing some testing myself, and calling with mode == 2 handles the menu and blocks for < 1 second. Going back to using mode == 0 after the menu key works.
I'd recommend that method strongly, though. 
Register to Join the Conversation
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
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