Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'd suggest you create a Painter class and do the following:</p> <pre><code>public void paint(Painter painter) { painter.draw(x, y, unit_sprite); } </code></pre> <p>That way the units don't have to worry about the existence of a camera. It is none of the unit's business how that works. The unit just needs to know how to draw itself on the global co-ordinate scheme and the painter will understand how that relates to the actual screen co-ordinates. </p> <p>Why is this a good idea?</p> <ul> <li>Reduction of code, each unit doesn't have to worry about translation to the correct co-ordinate frame. All of that code exists once in a single location.</li> <li>Ease of change. For example, suppose that you decide to implement a zoom feature. If each unit does its own translation that would be a pain. However, if all of that logic is in the painter, you can modify the painter to take care of rescaling the images and determining the correct offsets. </li> <li>Decreased dependencies, the units don't know what a camera is, they are simpler because they don't worry about it.</li> </ul> <p>Regarding your proposed solutions:</p> <ol> <li>Storing a reference to the camera on your object assumes there will only ever be one camera. What if you implement something like a split view? This may be unlikely, but by storing the reference you unnecessarily pretty much lock yourself into one perspective.</li> <li>The problem with splitting up the variables is that logically the two pieces are one item. This makes it a bit harder to figure out what is going on, will cause problems if you someday need more parameters, and also gives information to the unit which it really doesn't need.</li> <li>This suffers from the same problems of #1, it locks you into a single camera being used all over the place. The unit shouldn't be responsible for defining how the camera is used.</li> </ol> <p>Regarding performance:</p> <p>The difference is going to be almost nothing. I'm not sure what method will win in a performance battle, but I can tell you if you have performance issues they are going to be somewhere else (I'd guess in actually blitting functions). By combining all the code relating the offsets is a single location, my proposed method will make it easier to implement an optimization. For example, a common optimization is not draw things which are offscreen. If you have 20 functions all calculating offsets and invoking drawing functions, you'll have to go to each of those function and change them. If you use a painter, then you can simply change the painter class to ignore request to draw outside of the visible area and you are done.</p> <p>Regarding static variables in general:</p> <p>I consider static variables (and singletons) to be global variables and thus virtually never use them. Making them static ties me to particular decisions. I'm not smart enough to make all the right decisions up-front and so I need my code to be flexible.</p> <p>Some Guidelines:</p> <ol> <li>If you find yourself needing to access the data inside an object, i.e. the x,y value consider whether you should instead tell that object to do something be invoking a method. I.e. Tell Don't Ask. </li> <li>If an object (like Painter) is only used for a particular task by an object then it should be a parameter not a member variable.</li> </ol>
    singulars
    1. This table or related slice is empty.
    1. POUse of the public static field, good programming practice/fast?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USWinston Ewert
    1. USWinston Ewert
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUse of the public static field, good programming practice/fast?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COWow, thanks for going in depth to answer my question. I will definitely redesign my approach and implement some sort of Painter class. I actually wonder why I did not came up with such a solution so far.
      singulars
      1. PO
      1. USArmoredSandwich
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload