[TUTORIAL] Pimp my program

[Magix]

Recently, I've noticed many programs in the submission section that are poorly made, with little time spent on the graphics. Just because Turing is so basic doesn't mean you can't get some cool graphics out of it. In this tutorial I'll teach you what you can do with Turing, to make a simple program a lot better. This includes fixing basic bugs, and adding graphic quality.

For this tutorial, I'll take a noob program (self made) and I'll fix it up, and show you common mistakes. Here is the code for this program...

Turing:

var WinMain : int                                          %Main Window WinMain := Window.Open ("graphics:450;450,nobuttonbar")     %Set Window setscreen ("title:Noob Version")                            %Set title %Variables var chars : array char of boolean      %For user imput var px : int := maxx div 2              %Player x-position var py : int := maxy div 2              %Player y-position var xv : real := 0                      %X velocity var yv : real := 0                      %Y velocity loop     Draw.Box (10, 10, maxx - 10, maxy - 10, black)  %Draw Border     Input.KeyDown (chars)                   %Input     %Movement     if chars ('w') then                     %Up         yv += 1     end if     if chars ('a') then                     %Left         xv -= 1     end if     if chars ('d') then                     %Right         xv += 1     end if     if chars ('s') then                     %Down         yv -= 1     end if     %End Movement         if chars (KEY_ESC) then                 %Exit         Window.Close (WinMain)         exit     end if         %Set Velocity     if xv > 0 then                          %Reduce x-velocity         xv -= 0.5     elsif xv < 0 then                       %Reduce x-velocity         xv += 0.5     end if     if yv > 0 then                          %Reduce y-velocity         yv -= 0.5     elsif yv < 0 then                       %Reduce y-velocity         yv += 0.5     end if     %End Velocity set         %Snap to borders     if px < 20 then                         %Border (x-minimum)         px := 20         xv := 0     elsif px + 20 > maxx then               %Border (x-maximum)         px := maxx - 20         xv := 0     end if     if py + 20 > maxy then                  %Border (y-maximum)         py := maxy - 20         yv := 0     elsif py < 20 then                      %Border (y-minimum)         py := 20         yv := 0     end if     %End border snap         %Set player co-ordinates     px += round (xv)                        %Move X     py += round (yv)                        %Move Y     %End of player co-ordinate setting         %Draw     drawfilloval (px, py, 10, 10, black)    %Draw Character     %Delay     Time.DelaySinceLast (30)                %Delay     cls                                     %Clear Screen end loop

Just for time-saving purposes, I'll assume that the movement part is fine, so that I can focus on bug fixes. Normally, others don't make movement procedures as good as this, but using this will allow me to best demonstrate everything I am talking about. If one was to run the above program, they would notice a few things...

1. the program flickers
   
2. running from any edge to the opposite edge results in a "flicker" where the ball appears past its border
   
3. the graphics are very bland
   

For now, these three things are all I have time to talk about.

1.Program Flicker

The reason behind this is easily traceable. At the moment, every action the program takes is shown on the screen. If I were to add a random "put Hi" right before or after the cls command, it would be seen flickering every time the program runs through the look. This is not what we want. What we want is for the loop to process, calculate all positions, update position (of player) then show these changes on the screen. Fortunately, this is easy to do. There is a "setscreen" command that hides everything on the screen until it is specifically told to display the current arrangement of the program. Go to the very beginning, where it sets the WinMain window properties...

Turing:

WinMain := Window.Open ("graphics:450;450,nobuttonbar")     %Set Window

The command to hide the screen value is a simple "offscreenonly", meaning that all calculations and processes are carried out offscreen. With this edit, the line will look like this...

Turing:

WinMain := Window.Open ("graphics:450;450,nobuttonbar, offscreenonly")     %Set Window

Alternatively, this can be done in a seperate line after it. The could would be...

Turing:

setscreen ("offscreenonly")

Now if you were to run the program, you would see the original position of the player, but if you try moving, you will see nothing. This is because we haven't told the program when to update the screen. This is also a very simple task. The command that tells Turing to update the screen position is "View.Update". Wherever it is placed, Turing will update the screen, the continue calculating and running off screen. The placement of this "View.Update" is very important. If done after the cls, we will only see a white screen. Usually, the best position for it is right before the cls command. Therefore, the last 3 lines change from this...

Turing:

Time.DelaySinceLast (30)                %Delay     cls                                     %Clear Screen end loop

to this.

Turing:

Time.DelaySinceLast (30)                %Delay     View.Update     cls                                     %Clear Screen end loop

If you run the program now, you will notice the flicker is gone. The "offscreenonly" and "View.Update" have fixed the problem. This fixes the screen flicker problem, but we still have other problems to take care of.

2. Edge Detection Issues

If you run the program from one edge to the opposite, you will notice a flicker where the circle passes the border. Let's debug the program together and find out what is wrong. One way is to see the algorithm, and understand how the computer processes the information. The algorithm for this program (in a very basic form and only the main loop) would be...

1. Draw Border
   
2. Movement Control
   
3. Set Velocity
   
4. Snap to borders
   
5. Set player co-ordinates
   
6. Draw Player
   
7. Update Screen
   

Now lets see what is going through the computer when velocity is 5, and Player X position is one less than the maximum X, and the player is holding the right arrow key
Lets say for this example that the maximum X value is 450 and the maximum Y value is also 450. The player is at (449, 230)

1. Draw Border - unaffected by variables
   
2. Movement Control - Since they hold right, the X-velocity is increased by 1
   
3. Set Velocity - Since the velocity is now 6, which is > 0, it is reduced by 0.5, making it 5.5
   
4. Snap to borders - The recorded co-ordinates of the player are still (449, 230). Since 449 is less than 450, the computer doesn't change anything.
   
5. Set player co-ordinates - 6 is added to the co-ordinates, so the player co-ordinates are (455, 230) - Note that 455 is greater than the maximum.
   
6. Draw Player - The player position is drawn.
   

Have you spotted the issue? The player is snapped to the borders after the incorrect player co-ordinates are drawn. Therefore, the solution is simple. Move the "Snap to borders" right after the player co-ordinates are set. As you can see from above, the code for the "Snap to Borders" part is...

Turing:

%Snap to borders     if px < 20 then                         %Border (x-minimum)         px := 20         xv := 0     elsif px + 20 > maxx then               %Border (x-maximum)         px := maxx - 20         xv := 0     end if     if py + 20 > maxy then                  %Border (y-maximum)         py := maxy - 20         yv := 0     elsif py < 20 then                      %Border (y-minimum)         py := 20         yv := 0     end if     %End border snap

Now cut this from the code, then find the following line.

Turing:

%End of player co-ordinate setting

Paste it to the line immediately following this.

Now run the program, and you'll see that all the major problems have been solved. This is great!!




I will finish this tutorial (on graphics) later. Please be patient and check back. Leave comments, ideas, and suggestions. If you notice anything wrong, don't hesitate to add on to this tutorial

[Insectoid]

I think Pi at Sea Survival wins for most visually appealing game made in Turing.

[USEC_OFFICER]

I have to agree with you. (Though some of my (yet) unreleased games are pretty good looking)

[Magix]

Well I don't think that counts for "Graphic Quality". For me, graphic quality means using the actual built in functions of Turing. A great example of this would be Turing.

[Cezna]

Magix @ Fri Jun 25, 2010 1:23 am wrote:

Well I don't think that counts for "Graphic Quality". For me, graphic quality means using the actual built in functions of Turing. A great example of this would be Turing.

???
Did you mean to say Turing GUI or something? (I hope you didn't)

Anyway, I agree, I always spend far too long making my programs look nice with menus and GUI, usually to the detriment of the program itself (as this leaves me with less time to fix bugs, *sigh*, and oh how many there are...)

[Magix]

Oh ho ho. no. No. Not the GUI ever. Just find Windsurfer's "Forces" game, and play it. Then you'll know what I mean.

And yea, GUI in turing just doesn't work.

[Insectoid]

What, you mean unless you use Draw.Box or whatever it's not quality? I'd rather use images where I could 'cause it's easier, neater and unless you put in a LOT of effort, looks better.

[InfectedWar]

Cezna @ Fri Jun 25, 2010 8:55 am wrote:

Magix @ Fri Jun 25, 2010 1:23 am wrote:

Well I don't think that counts for "Graphic Quality". For me, graphic quality means using the actual built in functions of Turing. A great example of this would be Turing.

???
Did you mean to say Turing GUI or something? (I hope you didn't)

Anyway, I agree, I always spend far too long making my programs look nice with menus and GUI, usually to the detriment of the program itself (as this leaves me with less time to fix bugs, *sigh*, and oh how many there are...)

Arrg i'm completely opposite, I focus on the code and functionality and do the graphics last. I know for a fact if you do the graphics first it will be hard to get anything else done =d In the I end I always try to convince some friend to produce the graphics.

I know a friend in our cs class that always does graphics first and all I can say is he never gets the program done or 100% functional =(

[Cezna]

I sometimes get to thr point where I am adding in the full, detailed, extensive graphics for something before I have even begun to code the functionality for the bit of code the graphics is for.

However, I find that doing it this way allows me to have a good graphics structure set up before hand so that I'm not going back trying to get all of the the graphics for the functions I want crammed into a space.

I also find that it is easier to adapt functionality to fit graphics rather than the other way around (still without sacrificing any functionality), and I not only get everything done doing it this way, I almost always have time to add more than originally intended to improve the program.

But this is just me and my silly coding ways.

[mirhagk]

Well I personal care nothing about graphics, I do enough to make it look decent, and maybe steal a picture or model from someone else (actually only royalty free pictures) but to me graphics is the last thing, because if your game has bad graphics, who cares that much, if your game has huge glitches, well then that's really bad.

[Insectoid]

I agree with mirhagk. Graphics are cool in grade 10 and 11, but after that, figuring out algorithms and general concepts is more important.