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.

Newcomers DBPro Corner / setting up the game in a function! argg!

Author
Message
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 26th Feb 2008 21:15 Edited at: 26th Feb 2008 22:04
Link
Hi all,

Ive got around 10 functions already and ive done some quite cool things but ive got a problem now.

Im my function: DoGetInit(.....)
i am calling: Start_Game()
which is a function here:

-edit-I Forgot to mention, the above function is truncated - im just showing you the bits of code that im having real trouble with.

..Problem? yes of course: all im getting is the "game started" at the top which i put there for debugging - the actual 3d backdrop (standard blue backdrop) appears but i dont get any objects created etc?

Is there something im missing?

I was going to do this:

Function DoGetInit(...)

If requirements met: start_game()

endfunction


Function Start_Game()
setup everything here including making objects etc

do
print "the game code is here"
loop
endfunction

-Any ideas, someone must be using this method?

Paul
Back to top
Profile PM Email
Vesper103
16
Years of Service
User Offline
Joined: 21st Feb 2008
Location: Beloit WI
Posted: 26th Feb 2008 21:21
Link
....I don't see any objects being created in your code at all... I see a light and setting up the camera? is it in a different function?? if it is then maybe your computing your camera wrong and its looking in the wrong place. Set your camera to be controlled with arrow keys, and "look around" for your object. it may be a simple issue of not setting the camera right.

Your signature has been erased by a mod - please limit your signature to 600x120
Back to top
Profile PM Email Website
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 26th Feb 2008 22:12
Link
ok good point i will try this!

yeah i am setting up objects just ive truncated that out as i know it works

all the game code worked before i tried shifting it into a function..

Paul
Back to top
Profile PM Email
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 26th Feb 2008 22:20
Link
..ok ive narrowed this down to a simple problem.

if i put "sync" after certain parts of code then i can see everything..

at the top i've got "sync on" - is this why.

i think maybe im running before i can even crawl, i dont really understand the concept of "sync" i understand it displays whatever's changed - but is there no way to have it like automatically "sync" ??

Paul
Back to top
Profile PM Email
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 26th Feb 2008 22:57
Link
That would do it.

Either change your "sync on" to "sync off" (which lets the program do the sync for you, or add just "sync" to the end of your main program loop.


Don't think, just code.
Back to top
Profile PM Email Website
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 26th Feb 2008 23:03
Link
right sync off - then remove all my references to sync in the code yeah?

Paul
Back to top
Profile PM Email
spooky
22
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 26th Feb 2008 23:14
Link
No, no, no !!!

Let me explain. If you sync off, this basically lets the graphic card and DBPro to update screen when it feels like it and this causes lots of unwanted stuff.

You should SYNC ON and ideally use the VSYNC flag of SET DISPLAY MODE, or use full-screen exclusive mode. Then you need to add a SYNC, usually the last line of main game loop just before the LOOP command.

This gives you complete control of when screen will update and will be in sync when monitor redraws the screen.

If you dont VSYNC and force a higher refresh rate than monitor can handle, then you will get 'tearing', specially noticable when large objects pan across screen. This is because you are effectively seeing multiple frames at once.

Boo!
Back to top
Profile PM Website
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 26th Feb 2008 23:55
Link
..ok im going to have to read this again in the morning but it sounds good if nothing else! cheers

Paul
Back to top
Profile PM Email
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 27th Feb 2008 00:35
Link
Not having seen all of your program I'm going to have to make some assumptions - the main one being that your program is entirely made of functions.

If this is true, I just can't see the point. I've seen programs which start with a function which then calls another and so on. Why, is totally beyond me because functions weren't designed to be used like that.

The main problem is with variable scope. Functions use local variables, so you have the added complication of having to pass variables to them and only being able to return just one.

Yes, you've got local variable declarations in DBP, but if you used procedures - and functions when appropriate - you wouldn't even need global variables.

I have a feeling that's maybe part of the reason you are having problems.

TDK_Man

* TDK's Game Programming Forums - Open To All - DB & Team Request Boards *

Back to top
Profile PM Email Website
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 27th Feb 2008 00:56 Edited at: 27th Feb 2008 01:01
Link
hmm - i might of overkilled functions but i think it makes for a more universal project, i obviously dont know but i would of thought if i now wanted to change the way my game operates i can just send different values to those functions and achieve totally different results?

i'll look into procedures and stuff.

anyway cheers for your help.. tdk i've sent you an email as i think you might be able to help me without me spamming forum

Paul
Back to top
Profile PM Email
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 27th Feb 2008 16:32
Link
Quote: "if i now wanted to change the way my game operates i can just send different values to those functions and achieve totally different results?"


Doing the same and changing values with procedures is exactly the same - but without you having to pass those new values to the functions - the procedures can already see them!

TDK_Man

* TDK's Game Programming Forums - Open To All - DB & Team Request Boards *

Back to top
Profile PM Email Website
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 27th Feb 2008 19:35
Link
i think i understand what your saying but now maybe if you can appreciate i dont know how to make a procedure - im going to have to do some more investigating is all im saying..

cheers anyway will look into it

Paul
Back to top
Profile PM Email
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 27th Feb 2008 20:15 Edited at: 27th Feb 2008 20:19
Link
Quote: "i think i understand what your saying but now maybe if you can appreciate i dont know how to make a procedure - im going to have to do some more investigating is all im saying.."

Procedures aka Subroutines aka Gosubs are just snippets of code that are called within the main loop but reside outside it.

Procedures are basically like functions except they don't require input or return a value. They keep your code easy to read and well organised. Procedures can be called more than once.

Your Setup function would be better as a procedure
e.g.



See how much easier that is to read. Your program becomes easy to follow as you can read the procedure names and understand what they do without having to read all the code.
Remember to put a "Return" at the end of your procedures so that DB knows when to return to the main program loop, it will carry on from just after the procedure call.


In DBP over-using functions is not such a problem as you can declare global variables, but that does cause a slight problem in itself. If you define a global variable you obviously can't use the same variable name as a local inside a function.

I'm sure there must be other reasons for being economic with functions.

Back to top
Profile PM Email
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 27th Feb 2008 20:22
Link
ok so next:

when the code in the project runs (top - bottom)

will it run the sub procedure without calling it?

the reason i think/thought i liked functions is because i could 'call' it as and when i wanted it.

is this exactly the same with a sub procedure?

Paul
Back to top
Profile PM Email
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 27th Feb 2008 20:35
Link
@Paul08
If you let the program run into the procedure it will run it as normal code, not sure what happens when it hits the return command though?

This is why you should have "END" after your main loop and before your gosubs and functions, then you avoid any risk of running code when you don't want to or running into a function and crashing.

You can call procedures whenever you want them. I think the whole idea behind procedures is that it is an action that is defined, basically the computer knows how to run a "setup" in my example, so when I want to setup I just call that procedure.

Not sure if I am talking jibberish there.
I'll try and use a metaphor: You probably learnt how to butter bread when you were pretty young, and every time you've needed to butter bread you've simply called up that procedure and ran through the steps.

You'd use a function if you wanted to be able to spread a number of different things on the bread; so you could input either "butter" or "jam" or any other kind of thing you'd want to spread and you'd take that parameter and perform the correct action.

don't know if talking about bread makes it any clearer but ho hum

Back to top
Profile PM Email
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 27th Feb 2008 20:43
Link
the theory is no problem - thanks

so ex:

rem main game loop

do

actions in game

loop

rem end so dont go into procedures functions etc
end

setup:
do setup stuff here
return


-where does return go>? top of code or just back to "setup:" ?

Paul
Back to top
Profile PM Email
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 27th Feb 2008 20:46
Link
The return sends the program counter (is that the right word?) back to just after you called the procedure. DB acts like the entire procedure has been condensed into that one line (the call).

Back to top
Profile PM Email
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 27th Feb 2008 22:01
Link
lovely, simmilar to a php include("") then

Paul
Back to top
Profile PM Email
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 27th Feb 2008 22:02
Link
Excerpt from tutorial number 2 here:

http://forum.thegamecreators.com/?m=forum_view&t=99497&b=10

Quote: "What Are Subroutines (sometimes called Procedures):

These are vital to keeping your programs running smoothly. You can write programs without them, but once you have used them, you wouldn't dream of going back to being without them!

Basically, you can think of a subroutine as a little stand-alone program which you can call on at any time. The code in a subroutine is something that can be called many times in your program - and hence prevents you having to retype the code each time you need it.

If you needed to print ten lines of text in three different places in your program, rather than have thirty lines of code, you would put the ten lines into a subroutine and use a single line of code to call the subroutine whenever you needed the ten lines printed.

Alternatively a subroutine can simply be code that you may only need once, but just want to keep in a separate location making your program tidier.

Subroutines start with a label and end with the line 'Return'. The command GOSUB is used to call the subroutine and as the calling line is stored, the Return bit at the end knows where to jump back to after the code in the subroutine has been executed. For this reason, you should never exit out of a subroutine by using GOTO, though calling another subroutine from a subroutine is OK as it too will return automatically.

On return from a subroutine, control is passed to the line immediately after the GOSUB line.

Although a subroutine is a separate block of code to the code in the main program Do…Loop, it is still classed as part of your main program. As such, all variables in your main Do…Loop are available in a subroutine and any alterations made to them in the subroutine are seen by your main program."


The only real difference between a subroutine called with Gosub and a function is that they don't use local variables and as such don't have to have variables passed to them as parameters.

This is because procedures are classed as being part of your main program and can access/alter any of them.

Quote: "If you let the program run into the procedure it will run it as normal code, not sure what happens when it hits the return command though?"


Not exactly true - doing this will generate an error as both functions and procedures should never be run without being called.

TDK_Man

* TDK's Game Programming Forums - Open To All - DB & Team Request Boards *

Back to top
Profile PM Email Website
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 27th Feb 2008 22:30 Edited at: 27th Feb 2008 22:31
Link
Right i thought i had it but when you say

Quote: "
"...and a function is that they don't use local variables and as such don't have to have variables passed to them as parameters."
"


whats the difference then, between:
DoSomeAction()

Function DoSomeAction()
code here
endfunction

and:

gosub DoSomeAction

gosub:
code here

im not really that bothered - i dont want to seem ignorant or anything but my functions are working well with what im doing at the minute (when they work right and i dont screw them up)

i will go into using procedures, but a function that doesnt need any variables passed to it, and a procedure are VERY simmilar ( yet in dbpro editor i can collapse a function to tidy it away )

oh yeah - a function wont be able to access a local variable set in another area of the code thats outside the function! RIGHT its clicked!

Paul
Back to top
Profile PM Email
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 27th Feb 2008 23:13
Link
That's right!



TDK_Man

* TDK's Game Programming Forums - Open To All - DB & Team Request Boards *

Back to top
Profile PM Email Website
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 28th Feb 2008 04:47
Link
This is Why my DBPro "Init" Routines Are GO SUBroutines versus functions.... but aside from my inits - its functions or nothing... unless I want to get really EVIL nasty and nuts... I'll use a GOTO... LOL

Gosub Initglobals
...main program...

...far below...
InitGlobals:
GLOBAL giMyInt
giMyInt=100
..etc etc.
RETURN


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
Paul08
16
Years of Service
User Offline
Joined: 20th Feb 2008
Location: Oxford, UK
Posted: 28th Feb 2008 18:56
Link
..like i said though i absolutely love the way i can collapse a function and hide it away?..

Paul
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-09-27 12:24:24
Your offset time is: 2024-09-27 12:24:24