I remember writing an extensive tutorial on basic things not too long ago because I was bored, below is a copy-paste of that. I think you will find it useful.
Before I do that, let's check out your code.
Main:
do
Gosub Pong_setup
If Upkey()=1 then b=b-1
Sprite 2,a,b,2
If downkey()=1 then b=b+1
sprite 2,a,b,2
loop
return
Putting this in a subroutine is useless if you're not calling it.
do
Gosub Pong_setup
If Upkey()=1 then b=b-1
Sprite 2,a,b,2
If downkey()=1 then b=b+1
sprite 2,a,b,2
loop
The name you've given to that subroutine does not match it's function accurately.
Gosub Pong_Draw_Field would be more accurate.
Why sprite it twice?
do
Gosub Pong_Draw_Field
If Upkey()=1 then b=b-1
If downkey()=1 then b=b+1
sprite 2,a,b,2
loop
Missing comments...
rem start of main loop
do
rem draw the paddles
Gosub Pong_Draw_Field
rem get input from user
If Upkey()=1 then b=b-1
If downkey()=1 then b=b+1
rem draw paddles to the screen
sprite 2,a,b,2
rem end of main loop
loop
Okay, it's starting to look like something usable now.
Let's discuss screen settings. Here are the commands:
sync on
sync off
sync rate
backdrop on
backdrop off
sync
Alright, so what does each command do? Turning
sync on will give you control of when to render to the screen. When sync is on, the screen will only be updated when you use the command
sync. By default the sync is off, which causes the screen to be refreshed after every single command. This is very rarely needed, and I can tell you right away that your pong game does not need automatic refreshing. You can try this code to see what it does:
sync on
do
set cursor 0 , 0
print "This is text"
rem sync
loop
end
Run that. No text, huh? Try turning the sync off. You will see text again. After that, try turning the sync back on and take the "rem" away from the
sync command. Text text will be rendered to the screen.
What does
sync rate do? This command defines how fast you can update the screen per second. Here's an example:
sync on
sync rate 60
do
cls
set cursor 0 , 0
print screen fps()
sync
loop
Try changing sync rate to 30 and see what happens.
Never go over 60 frames per second unless you know what you're doing. It does not make any sense because the monitor physically can't refresh faster than 60 frames per second. You'd be wasting GPU power.
Alright, so what is the backdrop? The backdrop is pretty much the picture you see on your screen. If we turn the backdrop on, this will cause the backdrop to clear itself before every screen update. The backdrop is off by default, which means that the backdrop isn't cleared before updating, which causes the new data being printed to the screen to accumulate.
Run this to see:
backdrop on
print "awesome"
print "sauce"
print "is"
print "awesome"
wait key
end
You should only be able to see "awesome". Turn the backdrop off, and you will see everything again. Note that we don't have to call
sync because sync is off by default.
Alright! So with that out of the way, your game requires sync to be on and backdrop to be on, so put this at the start of your code:
rem setup screen
set display mode 800 , 600 , 16
sync on
sync rate 60
backdrop on
color backdrop 0
hide mouse
And add the
sync command to your main loop so we refresh the screen once every loop:
rem start of main loop
do
rem draw the paddles
Gosub Pong_Draw_Field
rem get input from user
If Upkey()=1 then b=b-1
If downkey()=1 then b=b+1
rem draw paddles to the screen
sprite 2,a,b,2
rem refresh screen
sync
rem end of main loop
loop
Right, the rest you should be able to get working by yourself. Here's that tutorial I promised:
----------------------------------------------------------------------------------
First off, let's talk about
indentation. Indentation is when you press "tab" to move sections of code further to the right. There are rules you need to follow in order to do correct indentation. It's very simple: Every command that has a "partner" to it will trigger an indentation. Examples of these commands are:
if...endif
do...loop
repeat...until
for...next
open to read...close file
lock vertexdata for limb...unlock vertexdata
And an example with correct indentation:
a = 1
b = 3
if a = 1
if b = 3
for t = 1 to 5
print "I live in a giant bucket"
next t
endif
endif
Why does this help? Imagine you forgot to use an "endif" somewhere in your huge amount of code. All the compiler will do is say "GAY! NESTING ERROR AT LINE <insert garbage number here>!!" and jump to a line that has nothing to do with the actual error. If you indented correctly, you will easily be able to see where you have an indentation too much, or too little. That's one of the major reasons why it's useful, the other reason is that it's so much easier to read because it reflects the logic.
Absolute and Relative File Names
This is an absolute file name.
load image "C:\Program Files (x86)\The Game Creators\Dark Basic Pro Free\Dark Basic Pro\Projects\Unit 22 Game\background.png",1
This is a relative file name.
load image "background.png",1
How does this help? The most important thing is that your program, when using absolute file names, will only run if you have placed it in the folder "C:\Program Files (x86)\The Game Creators\Dark Basic Pro FRee\Dark Basic Pro\Projects\Unit 22 Game\". Well that isn't useful if you want to give it to people who want to play it, right? That's where relative file names become useful. If the executable program is in the same directory as the image, you only need to use:
load image "background.png" , 1
If you decide to make a directory in that folder called "images" and place your image in there, you just change it to:
load image "images\background.png" , 1
It's as simple as that.
Comments
As some guy I can't remember the name of once said,
"Good comments are half the code". This is both literally and ideologically true, as you do write much more, but if you leave a program for 6 months and return to it, you'll praise the lord and kiss Adam's apple like a bag of potato chips (I have no idea where this metaphor is going) for having written comments. A non-commented program is a programmer's worst nightmare because you easily forget why you did something in a particular way. Comments will help you remember. There are many ways to make comments in DBP, the standard BASIC syntax is the keyword "rem". But you can use these as well:
rem this is a comment
// this is a comment
` this is a comment
You don't necesseraly have to write comments for every single line of code, but try to group your code and explain as much as possible. Here's an example of good grouping:
rem load the player object
load object "GANGMANSTYLE.x" , 1
position object 1 , 0 , 0 , 0
rotate object 1, 0 , 90 , 0
texture object 1 , 3
set object effect 1 , 1
rem let the user know that he will have no hope with this program
print "You. User."
print "A pile of camel's diarrhea is going to be more successful"
print "than this game."
See how there isn't a comment before every command, but there is a comment explaining what each section does.
Arrays
Said to be one of the scariest types of variables in existance, but they are vital if you want to have more than one of the same thing in your program (such as more than 1 asteroid). This is why you must understand the concept of an array. Here's an example of how to define and fill an array:
rem define our array
dim MyArray$(5) as string
rem fill the array with useless garbage (also known as RAM abuse)
MyArray$(0) = "My dog ate a sausage"
MyArray$(1) = "Donuts are my best friend"
MyArray$(2) = "Beware, for I know kung-fu, Ninjitsu, and other Japanese words!"
MyArray$(3) = "Today I ate food."
MyArray$(4) = "Why do I always talk about food..."
MyArray$(5) = "I suppose it reflects the current state of my stomach"
So let's print that to the screen:
print MyArray$(0)
print MyArray$(1)
print MyArray$(2)
print MyArray$(3)
print MyArray$(4)
print MyArray$(5)
Well that was a waste of coding space... Here's where arrays get cool. You can compress the latter by doing this:
for t = 0 to 5
print MyArray$(t)
next t
Arrays don't have to be strings, they can be floats, integers, bytes, booleans, words... Anything a normal variable can be.
User Defined Types
These help structure and group together variables that have things in common. If you wanted to create a player UDT (user defined type), this is how you'd do it:
rem declare player structure
type PlayerVT
PositionX as integer
PositionY as integer
Dead as integer
Shooting as integer
endtype
rem define player
global Player as PlayerVT
rem now we can change the player's values:
Player.PositionX = 1
Player.PositionY = 4
Player.Dead = 0
Player.Shooting = 1
See how all of the elements between the "type...endtype" commands can now be used inside the player variable? This is really cool because it's really easy to add variables just to the player later on, and it keeps all of your variables really structured.
Oh and if you're wondering what the "VT" stands for, it's a habit of mine so I know that it's a type and will be used for a variable, hence "
Variable
Type". If it were for an array, I'd use "AT" for "
Array
Type".
TheComet
"Why geeks like computers: unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep." - Unknown
