Self Contained Fuctions

Blitz3D Forums/Blitz3D Beginners Area/Self Contained Fuctions

QuickSilva

(Posted 2004) [#1]

Is it possible to create truly self contained functions? Take the following example, we have a player library that creates, updates and draws the main character in our game and we have a seperate bullet library that creates, updates and draws our bullets. Both are included at the start of our game. We already have a problem if we try to run these two seemingly seperate functions without one another as the player library checks to see if the user has pressed fire (in the PlayerUpdate() function ) and then calls the CreateBullet() function if he\she has. This is the problem, how can the two truly be seperated so that they both work without each other? Suggestions welcome.

Jason.

WolRon

(Posted 2004) [#2]

Didn't you answer your own question?

Don't call the CreateBullet() function if it doesn't exit.

QuickSilva

(Posted 2004) [#3]

It does exist though, just in another library. Thats the problem, the player library needs the bullet library to operate and I am looking for a way to seperate them all so that they can each work indepently. Just really want to see if it can be done. Surely it`s possible? I could just add the bullet functions into the player library but that would defeat the object of what I want to do.

Jason.

WolRon

(Posted 2004) [#4]

I now repeat myself:
Don't call the CreateBullet() function if it doesn't exist.

Either create a way for each library to check if another library is present (and if not, then don't call upon those libraries),

or

seperate the CreateBullet() part from the player library and just have the player library return an event to the main program stating that the fire button was pressed. Then the main program can decide whether or not to actually call upon the bullet library.

If I am not answering your question, then I do not understand the problem.

Rob Farley

(Posted 2004) [#5]

The problem is the way you've written them.

You need an additional control function. The control function will call your player function to move forward and call your bullet function to shoot.

skidracer

(Posted 2004) [#6]

Since when were players and bullets "seemingly seperate"?

They aren't. You might think trying to make such abstractions will simplify your program design but I think you will find such thinking will turn out to be a complete distraction from what I presume you are trying to do which is write a game.

Shifty Geezer

(Posted 2004) [#7]

You need to sit down and think about the structure of your functions and how you want to use them. You can create completely separate functions that aren't dependant on the presence of other functions, but it's all in the design.

eg. You've got a generic player control function and shoot bullet function. At the moment the player_move function calls the shoot_bullet function. Now when you try to use the player_move function in another program without bullets, it won't work.

What you'd need is a redesigned player_move function that doesn't call shoot_bullet, and when you want the player to be able to fire the bullet a different calling process is needed. AS WolRon sayd, don't use the shot_bullet function in another function if you can't guarentee it'll be available.

I would suggest something like seperate functions for player update and player control. Have one function to move and update the player graphics, another to read the user's input, and a third to control bullets. Then use you input_control function to call the other two.

If player move
move_player()

If player shoot
move_player()
shoot_bullet()

There's no specific answer as it all depends on your design, and that is one of the key elemtent to successful programming.
Being clever at finding workarounds, optimizations and so forth is important, but being able to come with elegnat, logical designs for libraries and program structure is an equally important and totally different art. Using functions effectively is more about being an Architect than an Engineer.

Ross C

(Posted 2004) [#8]

I agree with Skid. Sometimes trying to make things too modular can work against you.

Zethrax

(Posted 2004) [#9]

One way to make managing dependancies easier (though not automatic) is to use If statements that take a constant expression as a parameter to control whether code is compiled or not. Blitz will collapse these If statements down so that only the parts of the code that can ever be run will actually be compiled.

For example, this code:-

Graphics 800, 600, 0, 2
Const RELEASE_VERSION = True
If RELEASE_VERSION
	do_this = True
Else
	do_this = False
EndIf
Print do_this
WaitKey
End

Compiles exactly the same as this code:-

Graphics 800, 600, 0, 2
do_this = True
Print do_this
WaitKey
End

As verified by this checksumming program:-

; Prints a checksum of the test program file, which should be compiled as an executable called 'test.exe' and should be in the same folder as this program.


Graphics 800, 600, 0, 2

the_filepath$ = "test.exe"

the_file = ReadFile ( the_filepath$ )

If the_file ; The file was successfully opened for reading.

	the_filesize = FileSize ( the_filepath$ )

	data_buffer_bank_handle = CreateBank ( the_filesize )

	ReadBytes data_buffer_bank_handle, the_file, 0, the_filesize ; Load the data bytes from the file into the buffer bank.

	CloseFile the_file

		 ; -- Calculate a checksum for the loaded file data.
		the_max_pos = the_filesize - 1
		For i = 0 To the_max_pos
			the_checksum = the_checksum + PeekByte ( data_buffer_bank_handle, i )
		Next
		;^^^^^^

Else ; The file could not be opened for reading.

	Print "UNABLE TO OPEN FILE ERROR"

EndIf

Print the_checksum

WaitKey

End

MSW	(Posted 2004) [#10]

It can be done...but you will need to structure it all differently.

Prolly the simplest way is to use "messageing"...basicly create a message board (useing a bank, array, or even types)that the seperate functions can "post" and "retrieve" messages to/from...

Update_controls() finds the player presses the fire button and a "user fire" message is posted on the board.

Update_player() finds a "user fire" message, sets up the correct animation, etc..and posts a "create bullet AA, 256,72,north" message.

Update_bullets() find the "create bullet AA, 256,72,north" message...and creates a bullet of type AA, places it at 256,72 faceing north.

Obviously this would require something of a seperate messageing library that each function would need to call upon...additionaly a seperate "header" file could be used to store the messages themselves (this way the actual functions can simply pass array index numbers to the messageing function, and the messageing function can pass generic numbers back...while the actual interaction being set up and directed by the "messageing header file"

actualy sounds more complex then it really is...but it can be quite powerfull if implamented correctly, for example:

You can send a message to Update_controls() telling it to "sleep"...in which case the function does nothing except return (unless it finds the user has hit the 'esc' key...then which it posts a meassage to the Update_game() function that the user has done so)...in this manner another seperate function can be called, say Update_demo() which in turn reads from a game demo file stored on the hardrive or in a bank, and posts the appropriate messages to the Update_Player() function...which has no idea, nor cares, that it is running from a demo and not real time player input...

Course this isn't going to be the optimal way performance wise either.

Shifty Geezer

(Posted 2004) [#11]

Being a structured programming fiend, I wince at this suggestion :)

QuickSilva

(Posted 2004) [#12]

Rob Farley :

"You need an additional control function. The control function will call your player function to move forward and call your bullet function to shoot."

Could you give a small example of this please Rob?

Jason.