Jump to content
  • Advertisement
mrpeed

Is it bad design for one function to call other functions?

This topic is 412 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This function detects if a gameobject has moved or has had its sprite changed. It then calls one of two functions (or none), to draw a piece of the games background over the gameobjects current location or previous location. Should functions like this be avoided? Is this good or bad design? Does it violate SRP?

Also, how would something like this be unit tested?

#clean up the display...
def blit_background_over_dirty_rects(self):
		for gameobject, data in self.relevant_data.items():
			if data['location'] != gameobject.rect.topleft: #gameobject moved...
				self._blit_background_over_gameobjects_previous_location(gameobject)
			elif data['sprite'] != gameobject.sprite_manager.current_sprite: #gameobjects sprite changed...
				self._blit_background_over_gameobjects_current_location(gameobject)

 

Share this post


Link to post
Share on other sites
Advertisement

Code calls other code all the time.  That by itself is not an issue.

However, usually code should follow commands that do a bunch of work rather than micromanage the details of the work.  In your case it is probably faster to redraw everything with a single render command rather than to check every single object for details of if it happened to move.

 

Share this post


Link to post
Share on other sites

Agreed with frob.

It's quite normal for a function to call other functions.  We build functions to accomplish specific tasks and then put them together to create more complicated things happen.  If functions didn't call other functions it would be very difficult to compose complex programs in a nice way.

However, your specific design seems a little odd in this case.  Rather than each object updating and redrawing itself, you would more commonly update the logical position of all items (or all items within view if you've gotten far enough to be managing things off screen as well), and then redraw the entire screen with all objects in their updated positions.

Share this post


Link to post
Share on other sites

Is redrawing the entire screen every frame the common approach? Even if there are areas on the display that haven't changed? I'm using Pygame and I've read that you should only redraw the area of the screen that has been changed for performance reasons, though I'm not sure if this is unique to Pygame or even relevant to to Pygame anymore.

Share this post


Link to post
Share on other sites

OOP and Functional Programming are two different approaches to solving problems. OOP is just all the rage right now. What you are describing sounds like Functional Programming. You can read about it here:

http://www.codenewbie.org/blogs/object-oriented-programming-vs-functional-programming

I'm not a graphics expert but as far as I know most graphics APIs flip between two pieces of memory...the visible 'buffer' that is being rendered and the back 'buffer' that is redrawn all the time. When the API is done drawing on the back buffer it cycles the back buffer to the visible buffer. So point being...as long as you are redrawing the back buffer probably no issue.

Share this post


Link to post
Share on other sites
13 hours ago, mrpeed said:

Is redrawing the entire screen every frame the common approach? Even if there are areas on the display that haven't changed?

Yes.

 

13 hours ago, mrpeed said:

 I'm using Pygame and I've read that you should only redraw the area of the screen that has been changed for performance reasons

This is because Pygame is based on ancient technology that is embarrassingly out of date.

 

13 hours ago, mrpeed said:

I'm not sure if this is unique to Pygame or even relevant to to Pygame anymore

Pygame is one of the only systems that expects to draw to the screen using old technology. Pygame uses SDL 1.2.  SDL.1.2 uses DirectX 5, specifically DirectDraw for graphics. DirectX 5 is literally 20 years old, written for a time when a typical screen was 640x480 and graphics cards were esoteric add-on units.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!