TheBuzzSaw

Members
  • Content count

    310
  • Joined

  • Last visited

Community Reputation

143 Neutral

About TheBuzzSaw

  • Rank
    Member
  1. OpenGL Vulkan is Next-Gen OpenGL

    I don't think it's fair the way people are bagging on Khronos and assuming Vulkan will just end up garbage. We obviously cannot ignore history, but we also cannot assume the same thing will happen over and over. OpenGL was mangled by terrible market forces and people from previous eras. Vulkan is built from scratch and has no legacy to uphold (outside of being compatible with GL ES 3 hardware). I have great faith that Vulkan will be a significant game-changer for the better. I'm beyond excited to play with it.
  2. @Alberth Agreed. Avoiding the pointers entirely is the best. :D
  3. Criticism of C++

    C++ is indeed flawed. I think it would actually be quite easy to replace. I'm serious. You know why C++ hasn't been replaced yet? It's because every language that begins life as a competitor to C++ is seduced by some outside agenda that suddenly pulls it out of the running. The truth is no one wants to make a hardcore systems language. Halfway through making their "C++ killer language", they switch to an applications language, add garbage collection, remove pointers, mandate "safety", mandate exceptions, etc. For example, I can easily admit that C# is a better language than C++: it's more readable, easier to organize, more fun to use, etc. But at the end of the day, it's a garbage collected language that ties my hands with regard to low level constructs (or forces me to use tons of attributes and/or unsafe code to accomplish simple things in C++).   The way I see it, there's little point in criticizing C++ at this level until someone wants to step up and actually strive to build a replacement. I hope to do that one day. I'm actually working on a lexer/parser of my own. I'm sure I'll do a terrible job as my background is not in programming languages, but I want to set the ball in motion. So, what beef do I have with C++? Lots of things. I just wanna go down the list and fix them.   Replace text-oriented #include/#define with proper module/macro system and a proper namespace/package system Bring naming conventions out of 1970 Have nicely standardized int16/int32/int64 (instead of typedefs tucked away in the library) Hopefully introduce a handy build system (new kind of make file) Actually allow zero-cost abstractions (force inlining, etc.) Add nice portable libraries for things like SIMD and networking Expand enums to full fledged data tables etc etc etc With all that said, are there actual C++ competitors out there? I don't really count Rust. The syntax is ugly as sin, and the obsession with safety is unappealing.
  4. I'm late to responding to this. Busy with the holidays and whatnot...     This. Is. Terrifying.   Code should not be littered with shared_ptr everywhere (as function parameters, etc.). These classes are about [i]ownership[/i]. If a function is going to run a few operations on a given pointer, it should be accepting a T*, not a shared_ptr. Your goto container should be unique_ptr. Only when you discover you have 2+ actual resource managers that need to monitor a particular instance should you reach shared_ptr/weak_ptr. In short, if you have "not found a use for unique_ptr", you're doing something wrong.
  5. insights and tips on hi performance game programming

    He places a particular emphasis on "the joy of programming", which I think is so important. Yeah, C and C++ can do all these things, but they do them in silly, unstable, outdated ways. I absolutely would jump to a new language if for no other reason than to eliminate #include and the rest of the prepocessor. It is an absolute win/win -- no more forward declarations, and compile times go way down.   I think we'll be forever trapped by compatibility with C (too much existing useful software), but we can make progress in a new direction with a language designed for the 21st century.
  6. How to keep the trolls out of online gaming

    A fundamental problem with trying to address "trolls" is in trying to address the general concept of playing with strangers. Frustration always emerges from unmet expectations. When you play with someone you do not know, you are bound to have disagreements on how the game "should" be played. Basically, I think the concept of playing with strangers is pretty stupid (short of entering a tournament to prove you are objectively the best player). I make sure that my real-life friends are getting into the game with me. Obviously, that cannot ALWAYS be the case, so I try to participate in guilds and sub-communities where possible. It's definitely good to address trolls as best you can; no one likes a community overrun by jerks, but eventually players need to accept that playing with strangers leads to inevitable frustration. We just have this general idea that "playing with people is more fun than playing with robots". Well, it's true that human players make for more interesting gameplay, but too many games bank on that mentality alone. I'm not a troll, but I will never enter a community that forces me to expose my real identity. These are games, not applications for travel visas.
  7. GLSL and lighting

    The instant you start using shaders, you tell the fixed functionality pipeline to go away. That includes everything: textures, lighting, etc. So, by using shaders, you assume full responsibility for how the final scene is rendered. The good news is that you now have dozens of other better lighting algorithms at your disposal. The bad news is you get to code it yourself.
  8. I have actually run into the same thing. I am not sure if it is worth stressing over, but I would like to know if I am doing something wrong. I have a GL error after the window is created before I've done any drawing of any kind.
  9. Realism Vs Fun

    My argument against food in games is that I already have to feed the real human me in reality. I also have to feed my daughter and my dog. Please do not make me feed my digital hero too.
  10. The Start of Something Great

    Well shoot. Dedicate one team member to full time media production: YouTube documentaries.
  11. The Start of Something Great

    SIXTEEN friends? I can barely scrape up an interested crew of two!
  12. Finally, a place that allows private repositories with git. [url="http://arstechnica.com/open-source/news/2011/10/atlassians-bitbucket-code-hosting-service.ars"]http://arstechnica.com/open-source/news/2011/10/atlassians-bitbucket-code-hosting-service.ars[/url]
  13. "Quests" vs "Favors"

    [quote name='Acharis' timestamp='1317234522' post='4866883'] Unneeded complexity. Make everything a quest but add visual icons to them (main storyline quest, 1 star side quest, 2 star side quest, etc). [/quote] Heh. I fail to see the difference. You say it's unneeded complexity, and then you reintroduce the complexity by adding symbols. I haven't even said anything about UI elements; I've made no indication that quests and favors would be in completely separate places.
  14. Square or Hex board?

    I definitely favor hex. The zig zag "problem" is one thing you have to work around, sure, but I find it a mere annoyance compared to the issues with squares. Squares primary advantage is that it is simple to understand and built art around. However, it is difficult to address the distance problems. With squares, you either have to allow diagonal movement (faster than the other directions) or disallow it (now you're down to 4 directions as opposed to hexagon's 6). Everyone else has pretty much said all this... but I vote hex.
  15. "Quests" vs "Favors"

    I am toying around with the idea of separating the concept of quests as we know them in games into two types: quests and favors. I have two ways of dividing them, and I am unsure of which I like better. I am interested in your feedback. My first idea is to [b]separate them by size[/b]. Basically, a "favor" would be your short term go-kill-10-rabbits or bring-me-my-medicine objective. It is something small and simple that you can probably do in one sitting. In contrast, a "quest" would be a grand adventure involving many characters, traveling to far locations, etc. It would help the player distinguish the size and nature of the mission by knowing that it is not a mere "favor". However, thinking about that separation is when my second idea struck. My second idea is to [b]separate them by relevance[/b]. Basically, the divide would be a subtle indication of which objectives are tied to the main storyline and which ones are tangents for extra reward. Need to level some? Do a few favors for people. Ready to proceed? Grab the next quest. Which system would you prefer? Or which makes more sense in your mind? All feedback is welcome.