@Zheng 随便写着玩的，见笑了

Type

opengl software

before you run the game. If that solves the problem, then the most possible explanation of the upside-down text is that your OpenGL driver does not work properly with MATLAB. You must either upgrade your driver/card, or stick to the software renderer.

Alternatively, you can run

opengl hardware
f = figure(1); title('Rightside up'); set(f,'Renderer','OpenGL');

and see if the problem could be reproduced.

The following link may help
http://www.mathworks.com/support/solutions/en/data/1-91JU4U/?solution=1-91JU4U
------------

Anyway, I do believe that a submission should be judged based on its overall quality instead of minor bugs that are not even caused by the program itself. So I would never rate until I truly understand what the program does, how to use the program and what causes the problems (if any). If you do find a bug in the program, a more constructive idea would be to report the bug with details so that the author could correct it, rather than leaving a bad remark that doesn't give much info.

Then again, I was just speaking from a developer's point of view; not even trying to change your style of criticism. do what you believe is correct.

If you mean the voices I heard when the snake hit itself or when the game is over, yes the sounds do work (What does it say when the snake hits the wall? It sounds like "dooh" but I cannot make anything out if it).

I think you are right about the apple's shadows. I pictured in my mind what the game would have looked like if the shadows of the apple are added, and it does not appear good.

It seems that you have a great team and you guys really had fun. I envy you guys. When I tried to write a game, I never get to work with a team...Anyway, you guys should keep going and make more things like that.

I think this game is even better than your RISK game.I can't tell if there is any bug in the code since I don't know much about the rules of this game. However, based on what I see, the graphics and the interface is just amazing.

The only annoying part is that it is contingent on the maxfig+figstate functions which can only be downloaded from somewhere else. Is it possible to corporate them into your own zip file?

Very good one! Probably the best-looking Tetris on this site(Although it runs a little sluggish on my laptop.)

I believe its performance could be improved by using 1~2 image objects instead of 19x9 patch objects: Regard the whole playfield (including the 'frame' and all the 'fixed' blocked at the bottom) as an image object and the currently falling block as another. Or you can treat everything as one image object, since the background is just one simple color.

"Has anyone an idea about setting a fixed time a block has to wait before it moves down one line?"

There are many ways to do it. You can either make use of a "timer" function, which runs in a given interval. Or use a structure such as the following:

fall_interval = 1.2

start_time = tic;
last_time = start_time;

while 1
current_time = toc(start_time);
if current_time-last_time>=fall_interval
block_fall();
last_time = current_time;
end
process_keyboard();
...
end

start_time is the time when a block starts to fall; last_time is the time when a block moved down; current_time is...current time.

This structure can be further improved. For example, it is not perfect to set last_time = current_time. Because if the fall_interval = 1.2
Then "last_time" (the expected time when the moving occurs) should be one of the following numbers: 1.2, 2.4, 3.6, 4.8,... Maybe you can add a counter to record how many lines have a block moved down since it appeared, and calculate the time the last fall "should have occurred".

If you want, you may check my game "Stellaria" to see how timing is handled.

Good luck

Nice job. Althought it might be even better if you could include a short manual. I have to actually look into the code to find out what the control keys are and what the point of this game is (never played it before, sorry).

Well done! (Though I could see some discontinuity in the car's movement)

Okay, I know exactly what you are talking about. I designed the game in such a way that the game runs in the same speed on any machine. If an occasional lag happens, the game would try to skip some frames so that it could 'catch up'. If you pause the game and the internal clock is still ticking, the game would think it has encountered a super-long lag and after you resume playing, it would run 5 times as fast as normal until it catches up to where it should be.

The timing of the game relies solely on on tic/toc pair:
stageStartTime = tic;
...
currentTime = toc(stageStartTime);

Unfortunately, stageStartTime is just a number, not an object you can 'pause'. The only workaround I came up with is to record how much time the game has been paused, then after the game is unpaused, add the duration of the paused time to stageStartTime so that toc would behave as if the pausing has never happened.

I did have this problem at the early stage of development. I thought I have already solved it...Anyway, I'll check it out agian

Thanks for the comment Dave, but I failed to reproduce the same bug on my machine. Does it happen every time you pause the game?

Hi Dave,

I am afraid you have to add all the 'subfolders' (at least these three: Math, Stages, Util\midi) into your search path list.

Sorry for the inconvenience.

Mingjing