Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

509 Good

About Drigovas

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Drigovas

    How much paper is in your life?

    2 years ago I made a real effort to eliminate as much paper from my life as possible. The main reason is, while it was easy to read if you had it in your hand, it was hard to find, and I had a tendency to lose things or misplace things. It also ended up taking up an enormous amount of space, and made my frequent moves much more painful. I scanned things that I had to keep, I stopped buying paper books, I stopped magazine subscriptions in favor of online sources, I moved all my banking and bills online. I have a few books that I could not get in digital form [few enough that I can carry all of them at the same time, myself]. I have a checkbook that I haven't opened in about 10 months. I have a tiny bit of cash with me that I carry for emergencies. I have a bit of junk-mail in my garbage. I have paper towels, paper plates, and toilet paper. Other than that, I am 100% paper-free.
  2. Just use the enumerator outside of the foreach construct. Iterate through it manually, and you get indexing.IEnumerable<T> ev = f(...); int index = 0; var enumerator = ev.GetEnumerator(); while(enumerator.MoveNext()) { doSomething(enumerator.Current,index); index++; }
  3. Drigovas

    On leaving .NET

    I can certainly see what you're saying. In programming in general, I've seen generally two camps: 1) Don't implement anything that you don't absolutely have to, and 2) Implement everything yourself, from scratch, unless you are literally tripping over an existing solution [just think of how many damn replacements have been written for things like std::vector in c++]. There doesn't seem to be a lot of middle ground. One of the advantages of standard libraries is that you have ready-made solutions to find, that are pretty much in your face. The bad part about large and robust standard libraries is that a lot of people kind of think that this is all there is to the world, and don't really look elsewhere. It sort of fosters this lack of collaboration, because people never really get pushed to the point where they need to choose between either not accomplishing anything at all, or venturing out onto the web to find ready-made third party solutions. Of course there are still problems that need to be solved. But sort isn't one of them. This is sort of the problem that I found with .NET. It has a lot of stuff, which is great. It allows a programmer to not have to go and LOOK for third party solutions for almost everything. If you do use a third-party thing, chances are it also uses stuff from the .NET library, so you don't need to worry about really learning how to communicate with this new module you downloaded [things as simple as a standard implementation/representation of a list or ip address or whatever, is so useful]. The .NET library is however annoyingly deficient in certain ways, but not really so glaringly deficient for you to think "Ok, I really HAVE to seek outside support". Even simple things like priority queues, have been implemented a thousand times, because they aren't in .NET, but are just simple enough to implement that for someone who doesn't really know about any .NET communities, it's easier to just type one out instead of getting involved. If you consider something like C++, it took the failure of the STL to make Boost really interesting, and get people involved in boost, and thus invovled in general. If the STL was better, a lot of people wouldn't have gone looking for alternative container types. Personally I love C#, as a language. I love it partially because of the tools I get to use with it, and I like that it is more structured than something like python, but better defined and less error prone compared something like C++. I honestly don't value open-sourceness in most of my tools. I just want to be able to get them to do what I want to do with them, so closed-sourceness in the .NET library isn't an issue for me. Seriously though, the .NET COMMUNITY is deficient.
  4. So before going into how to do it, perhaps you should consider a hypothetical, to make sure what you're going after is actually what you want. Consider the situation where there is a change in ground level of two pixels vertically. Something like this: x x xxxxxxxxxxxxxxxxxxxxxxxxYour character goes to run over it. How do they make it over? To put it in perspective, two pixels is likely too small a feature for many people to see against a busy background, and the character is likely 100+ pixels tall. And on that note, how do you represent a 'slope', or a 'triangle' in a per-pixel fashion that allows your collision detection scheme to let a player run up and down the slopes? The point is, when a player encounters a pixel-tall collision, should they climb over it, or should they stop just as if they had encountered a 100-pixel tall collision. Also, if your player moves at many pixels per frame [as is completely realistic for a sonic game], should the player be able to run straight through skinny obstructions [being completely on one side in one frame, and completely on the other side in the next frame]. These points are why games typically use geometric shapes instead of pixels. If the character is represented as an ellipsoid, the player can slide up slopes because simple dynamics calculations would allow that. In terms of how to do per-pixel checking more efficiently, perhaps organizing your pixels into a quad tree or some such would allow you to more rapidly cull away pixel regions that will result in no collision detected. That way, you perform fewer checks.
  5. Drigovas

    Just starting out

    Quote:Original post by chao226 you could also try bloodshed dev c++Really, please don't also try bloodshed dev c++. There is a huge list of reasons why, but really it boils down to two big ones: 1) it is not current, and 2) it is FAR inferior in terms of features compared to vs2010/codeblocks/eclipse, all of which are free.
  6. Drigovas

    Thy favorite creation

    I wrote a very flexible and somewhat high performance ILP solver in C# over the course of about a week, back in C# 2.0-era, to learn the language. It's my favorite because I've used it in many, many other projects. It has turned into a real work horse for me, and over the years I've improved it greatly and made it more efficient. It is pretty much the go-to tool for about 70-80% of problems that I look at and say to myself "uhg, I really don't want to have to write a solution for this right now. If only there was an easy way that wasn't horribly inefficient". I've used it as the back end for everything from compiler optimization problems, to AI in my game projects, to data number crunching. All sorts of optimization problems, really.
  7. Drigovas

    what would you take up arms for?

    Honestly, my loyalty to my country is flimsy at best, and in most cases, likely nonexistent. I am currently in the USA, and if I thought Canada could offer me everything I have now, plus a ham sandwich, I'd happily turn my back on the US.
  8. Drigovas

    What's the best weapon in a Zombie Outbreak?

    Depends on the kind of zombies. If we're talking about 28 days later like zombies, which have effectively human life spans but are crazy, I'd opt for either a boat/bus, followed by a[n] ocean/desert. Drive boat/bus to middle of ocean/desert, hang out for a few weeks. Time and exhaustion will be my weapon. If we're talking those zombies who are effectively invincible [never starve out], save for getting shot in the head, a bus would likely still be my primary weapon. It's big and heavy enough to not really slow down from squishing a zombie. Other than that, pretty much whatever gun I can carry out of a gun shop/walmart and stuff into a bus. A bus is also something that you could likely weld a lot of scrap to, to firm it up a bit. If we're talking the old-style utterly invincible zombies..... not much good weapons will do you.
  9. 1: Operators as part of interfaces, or demands that operators be defined as part of a generic type constraint. Constructors as part of interfaces, or demands that a non-empty constructor be defined as part of a generic type constraint. 2: Either Allow for an interface implementation to be satisfied implicitly if it is marked as an 'implicit' interface type [if it has all the methods for a given interface, it can be treated as being of that type]. Or Allow for existing types to implement new interfaces in a fashion similar to how extension methods can be added to existing types. Honestly, there is a lot with regard to generics that can really use some tweaking.
  10. Drigovas

    NPC's hitting on players

    So in Fable 2, did the npc's hit on you, or wait for you to approach them? Did they initiate the conversation? I never played it.
  11. There are a fair number of games out there where it is possible for a player to have a relationship with a npc. It has been my observation that these games tend to depend on the player to initiate, and largely drive, the conversation relationships. But what about npc's that initiate conversation, or hit on players, or drive the conversation with the player assuming the roll of the person being picked up? On one hand, this seems like an interesting avenue that would add a bit more to a scene. On the other hand this seems like it may be a short cut to weirding players out, or making them uncomfortable, very similarly to how some people get uncomfortable if certain people hit on them in real life. What do you think? And if it were to be written into the game, what could be done to minimize the discomfort the player experiences if they are approached by an npc that they wouldn't like to approach them? Is it best to just leave the player to assume the initiating roll in these things?
  12. Drigovas

    Why should people learn to program?

    People shouldn't learn to program. ....someone had to do it.
  13. Drigovas

    Locking with threads

    Both of those methods will block. Calling lock inside a try-block doesn't make it non-blocking. What you're looking for is TryEnter. The 'lock' keyword is effectively short-hand for something more verbose. See here for details on the lock statement. Lock resolves down to Monitor.Enter() [plus some more stuff]. If you want to attempt to lock something, but detect if it is already locked and then not perform that action instead, use TryEnter.
  14. Drigovas

    public vs private c++ questions

    Personally found this particular pattern to be so common that it was worth just creating something along the lines of a 'bounded value' type, then just making the thing public. So many of my functions were just "assert(x); y = x;", a lot like what you see there. Things that really were effectively public, but resulted in more typing for me [and I hate things that result in more typing for me]. Looked something like this [not complete code, but will express the idea]:template <class T, T lowerBound, T upperBound> class BoundedValue { T value; void SetValue(T v) { assert(v >= lowerBound && v <= upperBound); value = v; } public: BoundedValue& operator = (T v) { SetValue(v); return *this; } operator T() const { return value; } BoundedValue(T v) { SetValue(v); } };Helps out a lot actually in doing bound checking. Got one for lower/upper bounds too. Pretty handy thing to have in a tool box. Real simple too.
  15. Drigovas

    Cockroaches in Canada

    I now know to never tell any of you any of my fears. Wow. Took only one post to put up the hugest, nastiest bugs you could muster after, in the original post : Quote:I have a phobia of large insects, I can't even look at pictures of them on the internet.Never show any vulnerability, even for a second.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!