Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Function help!

Author
Message
someguy99
16
Years of Service
User Offline
Joined: 7th Dec 2008
Location:
Posted: 7th Dec 2008 13:37
Hello,ive just started with DarkBASIC.
When i run this code:
`------simple music function----
set display mode 1024,768,16
sync on:sync rate 60

FUNCTION MUSIC()
load music "snd\main_theme.mp3",1
play music 1
loop music 1
ENDFUNCTION

MUSIC()

OK,so when i run this,i get the error "Runtime Error at line 11.Program ran into a function declaration".Why am i doing wrong???
TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 7th Dec 2008 14:33
Hello and welcome!

From now on, please highlight your code and press that button at the top right "code" to put your code into a code snippet:



OK, the program runs from the top to the bottom, right? So after turning on the sync, you run into the function declaration.

So, to build your program properly, your subroutines and functions have to be at the end of your program, where the program actually never reaches it. This is how you should build your program:



You always have to have a "END" just after your last bit of code before the subroutines and functions start.

So, your program should look like this:



TheComet

Peachy, and the Chaos of the Gems

someguy99
16
Years of Service
User Offline
Joined: 7th Dec 2008
Location:
Posted: 7th Dec 2008 15:10
Ok,so what i understood is the functions and subroutines should be kept in the end.
And also,i should always have a main loop,even if im only playing music which has a loop command.Right?
steve paul thomas
16
Years of Service
User Offline
Joined: 4th Nov 2008
Location: United Kingdom
Posted: 7th Dec 2008 16:23 Edited at: 7th Dec 2008 16:49
If your program opens, does a bunch of stuff then closes again (a "script") then you *might* not need to worry about a Do...Loop.

However, since you're probably not writing a script and you're actually making an application/game for a human being to use then you'll want to keep the program running until they decide to quit it.

The best way to do this, is as The Comet described:


Comet said:
Quote: "



You always have to have a "END" just after your last bit of code before the subroutines and functions start."


Be sure to put the "end" command in. As TDK said on the TDK's Programming Tutorials For Beginners [DBC/P]:

Quote: "
End Of Program

This is simply the word END which stops your program from running. Placed on the line following the LOOP line, it should never be executed as there is no way to get out of the Do…Loop to even reach it.

However, if program control ever reached this point, then it would crash through any code which follows - something you don't want as it would cause an error if all your subroutines follow.

So, putting it in doesn't do any harm - I do it out of habit…"



I've just made a program to illustrate this. Don't worry it doesn't do any harm, it just gives you warning about the potential catastrophe that could be caused by your program crashing through subroutines:




Alternatively, since you're just playing some music and nothing else, then you could achieve it with the following code:



I've REMarked out the "set display mode..." , "sync on" and "sync rate 60" commands since you're not actually drawing anything to the screen. So, in 3 commands you can play and loop music until the user presses a key.

This code is really only useful for demonstration. For actual programs, try to stick to the layout that The Comet described. Also, if you haven't run through TDK's excellent tutorials yet - then I would highly recommend them to you. You'll find them here:

TDK's Tutorials

- spt

I don't Adam and believe it!
someguy99
16
Years of Service
User Offline
Joined: 7th Dec 2008
Location:
Posted: 7th Dec 2008 18:12
Thanks.
Another question:
Is there a point in using subroutines when there are functions?
Caleb1994
16
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 8th Dec 2008 02:33
functions are more for things that you do alot over and over but with different numbers or variables like a distance function:



That would be a simple bullet collision code
with that you can use the same function with all your different enemies or whatever you wanted collision with. with subroutines its just what ever it is. and with a function the variables inside a function are not global as in whatever functions you have in you function will be gone when the function is ended unless it has a return value (in the above example it would be enemylife#) then the function call would be Variable=Function() see hope that helped
steve paul thomas
16
Years of Service
User Offline
Joined: 4th Nov 2008
Location: United Kingdom
Posted: 8th Dec 2008 05:40 Edited at: 8th Dec 2008 05:52
Pretty much what Caleb1994 said.

Functions

Functions are great for isolated tasks. You can write a function at the bottom of your program or you can use DBC's "include" command to include it from another DBA file that you have written.

You might use a function where you need to perform a task on some data and then return the result of that task back to your program. Returning data is optional though.

This example looks at the current value of myvar and multiplies it by two, finally the main loop increases the value of myvar. Run it and see what happens




Subroutines

You would use subroutines as neat little blocks of code that perform a particular action, such as what do when the user presses the fire key. Here's an example:



Run the program.

1) Press the spacebar then release. "Cannon is firing" is displayed for 2 seconds (2000 milliseconds) then it disappears and control return to the Main Program Loop (the cannon is not firing anymore)

2) Hold down the spacebar, and you'll see that the cannon continues to fire. Whilst the spacebar is held down then spacebar() will equals 1 and therefore _fire_the_cannon will keep getting called.


Basically, subroutines exist to keep your Main Program Loop as neat and easy to follow as possible.

Therefore, all the code that you want to happen when a certain condition is met, should ideally be located in a subroutine. That is a general guide, at least. Chapters 2 and 6 on TDK's Tutorials page cover this.

Also after you have read those, Obese87 has written a good guide on layout and style. Check out this thread:

Tutorial: How To Write Well Presented And Efficient Code (Second Edition)

Hope those help explain things

I don't Adam and believe it!
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 13th Dec 2008 18:43 Edited at: 13th Dec 2008 18:48
You don't always need a loop, if you only want to go through one cycle of the program for instance. DB will automatically end the program when all the lines have been executed, but as you've discovered function declarations and subroutines cannot be executed so you need to tell DB when to END the program.

Your music function is better suited as a subroutine. To explain why I'll first explain what functions and subroutines are (apologies if I repeat what others have said).

You see subroutines are like small programs; they usually perform a single task or "routine" as the name suggests, this makes it easy for you to call the same routine into action again and again without executing (or typing) unneccessary code. You essentially ask the computer to "look up" the routine whenever you need it. Even if a routine is only going to be used once, you should still write it as a sub to improve the legibility of your code; also, having a descriptive name for a subroutine allows the reader to grasp its purpose at a glance.
Here's an example: the first snippet will be written without subroutines, the second with them...


Good practice is to write out your code like the first example, grouping similar commands like I've done, then once you feel you have a group that looks like a subroutine make it into one like in my second example. I still code this way most of the time.

Ok, so we've seen how subroutines work, now onto functions.
Whereas subroutines never change, functions are always changing (their outputs that is), they are essentially formulas and I'll use a very well known formula to show you how a function is used...

We can define any size rectangle we want and the function will tell us what its area is. Imagine what complex and amazing things we could get the computer to do with functions!
The area function is an example of what I call a "base level" function; it doesn't rely on any other functions or arrays to work, and that means it's very versatile. If we ever wrote another program that needed the area of a rectangle we could simply use this one we made earlier! Try to write some functions like this, they'll save you lots of time on future projects. When you have a few functions under your belt you might want to store them in a function library; this is simply a DB file that contains only functions, you then use the #INCLUDE command (along with the address of your library) in any of your programs, and you can use all your functions as if they were in your current program!

Hope that helps.

A small program that works is better than a large one that doesn't.

DBC Challenge Rank: Rookie
Quirkyjim
16
Years of Service
User Offline
Joined: 18th Oct 2008
Location: At my computer
Posted: 14th Dec 2008 18:31
In my opinion, I use functions when what you're doing includes different values and is used over and over again with varying values. Subroutines take up the rest.

~QJ
TDK
Retired Moderator
22
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 15th Dec 2008 23:40 Edited at: 15th Dec 2008 23:40
Think of it like this:

In simple terms, a subroutine (or procedure) is exactly the same as a function apart from two things...

1. The way you call them.
2. How variables behave inside them.

Many people say you should always use functions rather than procedures, but off the top of my head I can't think of much you could do with a function that isn't possible with a procedure.

As far as speed is concerned, there's little if any difference between them so that isn't a factor in deciding which to use.

The way you call a function makes them good for creating your own commands. For example, take the following small snippet:



If you want to place lots of text in various colours at different positions on the screen, you could create a new command (function) to do it:



So, to print "Blue Text" in blue at 200 across and 200 down you would then use:

ColourText(200,200,0,0,255,"Blue Text")

You could still do the same with a procedure - you would just set the required variables up (remember they are global) and then use Gosub.

The function does allow you however, to include the call in a DB statement. If your function for example returns a value, it allows you to do things like:

If MyFunction(XPos, YPos) < 100 Then Gosub DoSomething

This would not be possible with a procedure.

Variables also have to be passed to a function in brackets because all variables inside a function are local - in other words, are totally separate from those with the same name outside the function. Compared to procedures (where all variables outside the procedure can be seen within it), this can be a hinderance in some situations.

The big downer with functions is that you can only pass a single variable back from a function, though you can 'cheat' using arrays. Procedures on the other hand can modify ANY variables and they remain altered on exiting from the procedures .

At the end of the day, it doesn't really matter which you use.

Personally I always use procedures unless using a function makes a task easier, in which case I use them instead.

TDK

Login to post a reply

Server time is: 2025-06-07 20:58:50
Your offset time is: 2025-06-07 20:58:50