Computer Science Canada

[TUTORIAL] Pimp my program

Author:  Magix [ Wed Jun 23, 2010 5:08 pm ]
Post subject:  [TUTORIAL] Pimp my program

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

Author:  Insectoid [ Wed Jun 23, 2010 6:57 pm ]
Post subject:  RE:[TUTORIAL] Pimp my program

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

Author:  USEC_OFFICER [ Wed Jun 23, 2010 7:49 pm ]
Post subject:  RE:[TUTORIAL] Pimp my program

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

Author:  Magix [ Fri Jun 25, 2010 1:23 am ]
Post subject:  RE:[TUTORIAL] Pimp my program

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.

Author:  Cezna [ Fri Jun 25, 2010 8:55 am ]
Post subject:  Re: RE:[TUTORIAL] Pimp my program

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

Author:  Magix [ Fri Jun 25, 2010 10:38 am ]
Post subject:  RE:[TUTORIAL] Pimp my program

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.

Author:  Insectoid [ Fri Jun 25, 2010 11:11 am ]
Post subject:  RE:[TUTORIAL] Pimp my program

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.

Author:  InfectedWar [ Mon Jul 12, 2010 9:10 am ]
Post subject:  Re: RE:[TUTORIAL] Pimp my program

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 =(

Author:  Cezna [ Mon Jul 12, 2010 8:30 pm ]
Post subject:  RE:[TUTORIAL] Pimp my program

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.
Smile

Author:  mirhagk [ Wed Sep 15, 2010 8:22 pm ]
Post subject:  RE:[TUTORIAL] Pimp my program

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.

Author:  Insectoid [ Wed Sep 15, 2010 8:30 pm ]
Post subject:  RE:[TUTORIAL] Pimp my program

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


: