Jump to content
  • Advertisement
Sign in to follow this  
Experiment-626

Sprite/Entity Screen Wrap

This topic is 2536 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

Hi all...

When a sprite/entity is going to wrap on the screen, should the engine be the one to detect if it will wrap or should the entity check itself if it will wrap? I suppose this question is asking should I (the sprite/entity) be the one to determine if I can go through the wall or should nature (the engine) determine it. This is more of a philosophical question I guess. lol blink.gif

Share this post


Link to post
Share on other sites
Advertisement
i think it is a little bit about the design of your sprite and engine.

but it would then be the engine that decides what happens IE collisions rendering etc

but it would proberbly be a better idea to have the engine handle as much as you can give it, rather then handing that control to the object.

just my 5 cents.
:) :) :)

Share this post


Link to post
Share on other sites

i think it is a little bit about the design of your sprite and engine.

but it would then be the engine that decides what happens IE collisions rendering etc

but it would proberbly be a better idea to have the engine handle as much as you can give it, rather then handing that control to the object.

just my 5 cents.
:) :) :)


I agree but I am having a hard time passing the information to the wrap function to affect the object that needs to wrap.

Share this post


Link to post
Share on other sites
I'll assume that "wrapping" means that when an entity leaves one side of the playfield it enters from the opposite side and it is drawn in both places, like the player's ship in Asteroids.
The main differences between putting this behaviour in the entity or in the engine are:
  • If the entity is in charge, it has to be able to authoritatively tell the engine that it moved to another point. Allowing only the simulation engine to alter entity positions is better for data integrity.
  • If the engine is in charge, it can simply look at entity positions, figure out which ones wrap and where, tell the entity that it moved instantaneously from A to B, and draw the entity (or tell the entity to draw itself to draw itself) both at A and at B.
  • If the entity is in charge, it needs all sorts of vague and complicated information from the engine: is it a wrapping level? Should I wrap or move beyond the screen area? In case I have to wrap, where are my wrap borders?
  • This complicated information is likely to be accessed and processed repeatedly for multiple entities that wrap themselves, while the game engine can figure it out in advance, maintain a list of entities that are meant to wrap, and check them against shared borders.

Share this post


Link to post
Share on other sites
I think your better off encapsulating any movement behaviour within the object itself if you want to retain Object Oriented design that is easy to follow (remember you'll probably want to revisit this code at some point in the future).. This isn't a bad thing especially when your learning.

Actually sorry I've made an assumption that your using an OO language and you haven't said this!

Still - put it in the sprite code :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!