Advertisement Jump to content
  • Advertisement

a light breeze

Member
  • Content Count

    86
  • Joined

  • Last visited

  • Days Won

    1

a light breeze last won the day on March 29 2018

a light breeze had the most liked content!

Community Reputation

65 Neutral

About a light breeze

  • Rank
    Member

Personal Information

  • Website
  • Role
    Creative Director
    Game Designer
    Programmer
  • Interests
    Art
    Audio
    Business
    Design
    Production
    Programming
    QA

Social

  • Github
    rainerdeyke
  • Steam
    Rainer_Deyke

Recent Profile Visitors

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

  1. One general tip for not causing offense when including a minority character is to include two character from the same minority, and give them completely different personalities. That way it's clear that their personalities are aspects of these individual characters, and not intended as some sort of generalization across a whole group.
  2. a light breeze

    Time to Vote!

    The problem isn't so much the pixel art itself, as the jpeg compression artifacts. Jpegs and a pixel art do not mix. That said, some more color contrast between the tents and the background certainly wouldn't hurt.
  3. a light breeze

    Time to Vote!

    Did you post these as jpegs or is that just this website? Either way, it's painful to look at. That said, the middle one.
  4. a light breeze

    Keeping players' energy in sync

    If the server lags, then the game lags, obviously. Not much you can do about it, but at least all aspects of the game lag at the same time, so the game stays in sync. One tick per frame, so if the server runs 60 fps, then 60 ticks per frame. You might be able to get away with less than 60 fps, but probably not as low as 1 fps. Also, the client doesn't query. The client passes input on to the server and passively waits for the server to tell it what it needs to know. No need for round-trip communication when a unidirectional stream will do. Count frames. If the server runs at 60 fps, then one second of game time is exactly 60 frames. If the server lags because it cannot keep you, one second of game time is longer than a second of clock time. If you're running a stress-test on your server, a second of game time may be shorter than a second of clock time. The only part of your server that should look at actual physical time is the part that runs the game simulation at a steady fixed fps, and even that part of the server would be better served with a timer that isn't affected by leap seconds. And any part of the server that runs seasonal events based on real-world dates, I guess.
  5. a light breeze

    Keeping players' energy in sync

    Standard answer 1: run all game logic on just the server. The server notifies the client when the game state changes. Do not trust the client with any game state, ever. Standard answer 2: run your game logic at a fixed frame rate. Do all timing in terms of frames. The server send a "tick" to each client once per frame, and the clients only update the game state when they receive a tick. It is therefore relatively easy to keep the server and the clients perfectly synchronized. Either one of these would fix your immediate problem. Both of them are good ideas. (And don't ever use datetime objects for game logic. What if the game is paused? What if the game state is saved and later restored? What happens when the time zone changes, such as at the start or end of daylight saving time? What happens when you get a leap second?)
  6. a light breeze

    Dynamic/static allocation of an array c11

    ...and at the cost of turning O(n) performance into O(n log n).
  7. a light breeze

    Dynamic/static allocation of an array c11

    Don't use a recursive function for floodfill. Do something like this instead: std::vector<vector<int, 2> > points; points.push_back(pos); while (!points.empty()) { vector<int, 2> p = points.back(); points.pop_back(); if (pixels[p] == color) { pixels[p] = new_color; points.push_back(p + vec(0, -1)); points.push_back(p + vec(0, 1)); points.push_back(p + vec(-1, 0)); points.push_back(p + vec(1, 0)); } }
  8. a light breeze

    Using Content from a Book

    I'm not sure I agree with the advice here. If you just use the puzzle without giving credit, then the authors of the book have no way of knowing if you got it from them or another source. By giving credit or by contacting the authors, you are opening yourself up to legal action by admitting that you got the puzzle from them. Example: the composer John Cage is famous for his piece 4'33", which consists of 4 minutes and 33 seconds of silence. Musician Mike Batt included a minute-long silent track on one of his albums, jokingly credited John Cage as a co-composer, was sued by the John Cage Trust for using 4'33" without permission, and ended up paying a six-figure sum to settle the lawsuit. Had he not given credit to John Cage, he probably wouldn't have been sued at all. After all, John Cage does not own the concept of silence.
  9. Sounds to me like this would favor high leadership heroes over everything else, assuming a 1 hero per army limit. And if leadership can be improved by leveling up your heroes, then it becomes all the more important to save all your leveling opportunities for your high leadership hero, to the point where all of your other heroes are more of a liability (because they use up leveling opportunities) than an asset.
  10. That's only the case for logical or (a || func()), not bitwise or (a | func()).
  11. Calling just about any function once-per-pixel is going to be slow as molasses in debug mode because functions are never inlined in debug mode. Luckily you can bypass all of these expensive function calls by writing directly to memory: std::vector<sf::Uint8> SfmlFilm::ToRgba(const std::vector<Spectrum>& image) { std::vector<sf::Uint8> rgba(GetWidth() * GetHeight() * 4); auto p = &rgba[0]; for (auto spectrum : image) { const auto max = 255; *p++ = static_cast<sf::Uint8>(spectrum.r * max); *p++ = static_cast<sf::Uint8>(spectrum.g * max); *p++ = static_cast<sf::Uint8>(spectrum.b * max); *p++ = max; } return rgba; }
  12. You have a lot of individual variables that would work better as a container of some kind. public void equipBandit(Item item) { int slot = item.getEquipmentSlot(); // Or make it a string, I don't care. if (slot == -1) { throw new IllegalArgumentException("Invalid Item"); } if (this.equipment[slot] != null) { Main.organ.addAmount(this.equipment[slot], 1); } Main.organ.addAmount(item, -1); this.equipment[slot] = item; }
  13. 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.
  14. 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.
  15. 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.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!