Prizm Game of Life (PrizmLife) - Cemetech | Forum

merthsoft
1
Administrator Emeritus (Posts: 3774)

03 May 2011 04:22:19 pm Permalink

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?

elfprince13
2
OVER NINE THOUSAND! (Posts: 11816)

03 May 2011 04:42:08 pm Permalink

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.

KermMartian
Site Admin (Posts: 63331)

03 May 2011 04:43:28 pm Permalink

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.

AHelper
1
#FlyTheW (Posts: 2366)

19 Jan 2012 11:35:32 pm Permalink

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.

merthsoft
1
Administrator Emeritus (Posts: 3774)

19 Jan 2012 11:37:53 pm Permalink

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.

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.

AHelper
1
#FlyTheW (Posts: 2366)

20 Jan 2012 12:52:38 am Permalink

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.

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)?

merthsoft
1
Administrator Emeritus (Posts: 3774)

20 Jan 2012 09:57:23 am Permalink

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.

AHelper
1
#FlyTheW (Posts: 2366)

20 Jan 2012 10:27:17 am Permalink

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.

KermMartian
Site Admin (Posts: 63331)

20 Jan 2012 11:39:14 am Permalink

I think I do something like that in my games. Smile

I'd recommend that method strongly, though.

AHelper
1
#FlyTheW (Posts: 2366)

20 Jan 2012 02:34:32 pm Permalink

KermM, I would warn that Tetrizm doesn't always clear the screen after returning from {MENU}, but this isn't the right topic Wink

At least someone else agrees on that code.