Tetris in Labview

[CoastalMaineBird]

Wow, small world.

I have a 17-year-old apprentice learning programming from me.

His current project is a remake of a project from 6 months ago - a Tetris game.

He uses a picture control, and draws the squares, then draws the highlighting, just as you've done - looks quite sharp.

He adjusts the background picture based on the "level" of the game, which depends on how many points you've scored.

We're having speed problems with the higher levels, as the drawing has to take place faster, and the re-drawing of the background pic when pieces move takes up more time.

It's a good project, though.

[Sheldon_Stokes]

I actually didn't use my complex draw routine due to speed issues.  For the sake of speed and smooth game play, I am drawing my blocks are filled rectangles which is a couple order of magnitude speed increase over my "Fancy" draw routine.

I spent a bit of time profiling my VI and seeing where the slowdown is.  Pre-making the blocks can save some time, but the conversion from a small picture to data than replotting that data into another picture control is what was killing me time-wise.  I'd love to hear how you can take a small picture and place it at an X,Y position in a larger picture without the flattening and such, and the speed hit that comes with it (without imaq).

I'd also love to hear what you experts think of my overall architecture, and if you have a clever way to eliminate the local I had to use.  Basically, I'd love to hear if I've gone at it the right way, and I'd like to learn for your experience. 

I'll be glad to explain how and why I did what I did if there's interest. 

Sheldon

[CoastalMaineBird]

I actually didn't use my complex draw routine due to speed issues.

One lesson you should learn (which is what I'm teaching my apprentice now) is that before you start tweaking your code for speed reasons, you should know WHERE your bottlenecks are. Optimize those first.

What we found out was that the drawing part (filled square + highlighted edges for 3-D effect) was taking about 10 mSec, but when the background picture was uncovered, the loop time was cramped, taking more than 100 mSec sometimes.

What you should realize from that (and what many beginners don't) is that even if you make the drawing part down to 0, you STILL have a problem. Part of your code may execute faster but you STILL have a problem.

In our case, to make the background pictures, he has taken photos (1024x800 or better) and posted them in the background cluster, shrinking them in the process. So I'm thinking that it has to go thru the squeezing process (1024x800 ==> 600x300?) every time a game piece moves, and that's what's taking the time. We'll see.

In any case, the lesson is the same, KNOW WHERE THE BEAR LIES.

If you can shave 1 percent off a routine that executes a million times, you're likely better off than shaving 90 percent off something that executes once.

[unclebump]

I think you could use the mask input in 7.0 to write the blocks anywhere on top of the background. I have a dartboard example somewhere that places a transparent dart anywhere on the board. Now if I can only find it on this hard drive.

[Ben]

Uncle,

does this help?

http://forums.ni.com/ni/board/message?board.id=170&message.id=126863

Coastal,

My intension was not to lie or deceive in anyway

Ben

[unclebump]

Thanks Ben

Change the path control in this vi to point to the png file after unzipping the file. This should put transparent darts randomly on top of the dartboard picture indicator. 7.0 format.

[altenbach]

Sheldon,

Code looks quite nice!

I only quickly glanced at the code and I am wondering why you even use a picture control. Wouldn't it be easier to simply use a 2D array of colorboxes? This would simplify coding dramatically ('not sure about speed).

There are a few errors in the behavior:

For example notice that in the attached image the times on the left are floating one row up for no reason.

Also, Tetris typically allows you to shift a piece left or right for one "tick" after it reached the bottom. This is important to e.g. slide a piece under an overhang. Your implementation does not allow this.

Message Edited by altenbach on 09-13-2005 08:49 AM

[Sheldon_Stokes]

That's odd behavior, I haven't seen that on my machine.  I'll try to reproduce it.

Sheldon

[DFGray]

Has anyone tried an intensity graph for this?  If you set the color ramp correctly, you can change the colors by simply changing the numbers in the data sent to the graph.  I don't know if this would be faster than the picture control, but it may be worth a try.  It is also fairly easy to change the "resolution" on the fly.  If I have time, I may benchmark it.

[DFGray]

Here is an example of how it could be done.  I didn't put any timing code in, but it sure is fast!