Jump to content
  • Advertisement

a light breeze

  • Content Count

  • Joined

  • Last visited

  • Days Won


a light breeze last won the day on March 29

a light breeze had the most liked content!

Community Reputation

57 Neutral

About a light breeze

  • Rank

Personal Information

  • Website
  • Role
    Creative Director
    Game Designer
  • Interests


  • Github
  • Steam

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. a light breeze

    understanding viewport opengl

    It's a question of priorities. You're saying (if I understand you correctly), "either write platform-specific code or use a framework". I am saying, "out of these two options, using a third-party library (not necessarily the same as a "framework") is the better choice." We both agree that these two are the only options, because it is flat-out impossible to write platform-independent OpenGL code without using a third-party library of some sort. Note that SDL doesn't abstract away OpenGL unless you use the 2D rendering API (which I would not recommend). It just creates the window and OpenGL context for you and feeds you input events. So using SDL isn't an alternative to using OpenGL with C++, but a tool for using OpenGL in C++ more effectively.
  2. a light breeze

    understanding viewport opengl

    I'm going to have to disagree with that. The easiest way to get started on OpenGL is to use one of the many libraries (such as SDL) that hide all of the hairy platform-specific code. I would use SDL (or one of its many alternatives) even if I were targeting only a single platform, but it also provides platform independence basically for free. Writing platform-dependent code is a bad habit that can be difficult to quit. If you're just getting started, it's best not to pick up that habit in the first place. Plus, using SDL is actually easier than using the Windows API.
  3. Short version: functions found through argument-dependent lookup usually have priority over names found through other methods, so the friend operator is shadowing (i.e. hiding) the operator in the global namespace. Putting the overload in the logging namespace allows it to be found with argument-dependent lookup, which prevents it from being shadowed. See also: unqualified lookup rules.
  4. Just put your overload into the logging namespace. As a general rule, you should never put operator overloads in the global namespace. Always but operator overloads in the same namespace as (one of) the type(s) on which they operate. In this case, that's class logging::log in the logging namespace.
  5. a light breeze

    Struggling to fill 3D city themed game

    Do you need all buildings to be unique? If so, how unique do they have to be? Can you take a building, move some parts around, and call it a new building? Can you build a "kit" of pieces which can be recombined into lots of different buildings? Can you reuse a model and just change the texture, or the other way around? Can you recolor your textures to create new textures with minimal effort? Can you simplify your art style to increase the speed at which your buildings are created? Lots of potential options that might or might not work for you.
  6. a light breeze

    Graphics VS Story VS Gameplay

    The easy, obvious answer is that I want all three aspects to be great. And there is such a glut of great, cheap games available that I really shouldn't have to compromise. But if I have to choose, I would say story (including world-building) > gameplay > graphics. I can tolerate some really shitty graphics. I can even tolerate bad gameplay (so long as it merely dull and not frustratingly difficult). But nothing pulls me out of a game faster than bad storytelling. I am especially suspicious of game developers who try to downplay the need for story with a "gameplay über alles" attitude. Not only do their games generally suck in the story department, but I rarely find their gameplay enjoyable either.
  7. a light breeze

    Should timers in an engine be on separate threads?

    If you're talking about using a thread for the timer, to avoid this specific QueryPerformanceTimer bug, while keeping the rest of the program single-threaded, then yes, the additional complexity due to threads is basically negligible - but doing this so is also completely pointless, because you could just set the thread affinity of the main thread instead and get the same benefit for less complexity. And, yes, every programmer is going to have to eventually make the jump to multi-threading if they're serious about performance. Nothing about the OP's post indicates to me that they are ready to make that leap, but I could be mistaken.
  8. a light breeze

    Should timers in an engine be on separate threads?

    Do not use threads at all unless you really, really know what you're doing. Threads are unfortunately sometimes necessary for performance reasons, but the cost of using threads (in terms of extra effort spent programming, extra effort spent testing, extra effort spent debugging, extra bugs that you won't find despite your best efforts at testing and debugging, and even potentially performance) is huge.
  9. a light breeze

    Help Me Decide on Storefront/Boxart with Voting

    A looks good. B looks too empty. C looks too purple. I have mixed feelings about D and E, but I don't think either one compares favorably with A. I think you want box art to look somewhat busy. A busy picture invites the viewer to spend more time looking at all of the details, which is more time that your box art has to convince the viewer to buy the game. However, your box art might benefit from a clearer visual hierarchy. Take the characters closest to the camera and make them bigger relative to the characters further back. The text in E is blurry and painful to look at when viewed at full resolution. The text in the others looks clean but unnecessarily pixelated.
  10. a light breeze

    Requesting a code review

    Fixed time-step trades a little up-front complexity for a lot less complexity later on. As such, I think it is almost a good idea to use it, and to use it early. Consider, for example, a rotating turret that rotates at a fixed speed and shoots whenever it reaches a 90° increment. With fixed time-steps, this is trivial to implement: def update(self): self.angle += angle_increment if self.angle % 90 == 0: self.fire_projectile() Simple, intuitive code. With variable time-step, the equivalent code would look something like this: def update(self, delta_time): while int(self.angle / 90) != int((self.angle + delta_time * angle_increment) / 90): new_angle = int((self.angle + delta_time) / 90) * 90 time_consumed = (new_angle - self.angle) / angle_increment delta_time -= time_consumed self.angle = new_angle projectile = self.fire_projectile() projectile.update(delta_time) self.angle += delta_time * angle_increment Lots of hairy math, difficult to read, difficult to debug.
  11. a light breeze

    Requesting a code review

    There's a fair amount of code duplication between players one and two that could be eliminated by having an array of players instead of separate playerOne and playerTwo variables. It's not a big deal for a small project like this, but imagine what would happen if you wanted to allow two-player competitive matches. Or computer-vs-computer attract-mode matches. Or more than two players.
  12. a light breeze

    Which artstyle works best? (3 versions of world-map)

    I don't like the first one. The borders don't look natural at all. If you're going to with a low-res approximation of the borders, own up to it and go with option 2 instead. Option 3 looks the best. Since you haven't posted any sprites, I can't tell how well it will work with your sprites.
  13. a light breeze

    Quaternions, how does ki = j?

    There's your error. You can't move from j(ijk) to ij2k. j(ijk) = jijk = (ji)jk and ij2k = ijjk = (ij)jk, which are not equivalent for quaternions. ij = k and ji = -k, so j(ijk) = -ij2k.
  14. a light breeze

    OOP is dead, long live OOP

    I tend to think of the runtime-configurable design in the "bad OOP" example as a compromise between the flexibility of a true scripting language and the performance of the hardcoded "good OOD" approach. Like many compromises, it feels unsatisfactory because it cannot fully deliver on either of its promises. That doesn't necessarily make it a bad design - it is actually quite successful as a pattern for those cases where a true scripting language is too expensive and the hardcoded approach is too rigid. (Which is not to say that a better compromise is not possible. I just find the argument that "rigid approach A is better than flexible approach B because it is faster" unconvincing. Flexibility is a value in and of itself that is often more important than performance.)
  15. Do absolutely everything that you can possibly do on the server, on the server. Ideally you shouldn't even be rendering on the client. Just send all input events to the server, and send the rendered video stream back to the client. (Note: rendering on the server consumes a lot of bandwidth that a lot of users don't have, so this is not really practical yet unless you don't mind severely limiting your audience. However, technology marches on, so expect this to become the main delivery system for online games within the next decade.)
  • 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!