Barius

Members
  • Content count

    173
  • Joined

  • Last visited

Community Reputation

325 Neutral

About Barius

  • Rank
    Member
  1. Directed graph problem

    You could model this as a flow problem, where A is the source, B is the sink and all edges have capacity 1. See Wikipedia: Maximum flow problem
  2. From the Perl docs ("perldoc perlre"): Quote: By default, a quantified subpattern is "greedy", that is, it will match as many times as possible (given a particular starting location) while still allowing the rest of the pattern to match. If you want it to match the minimum number of times possible, follow the quantifier with a "?". Note that the meanings don’t change, just the "greediness": In your regex, this means it tries to match the smallest number of characters before "< !--" is encountered, i.e. finds the earliest occurence of "< !--" (I had to put a space to make it show up in my post).
  3. Left To Right

    Balloon Kid is the only platformer-ish game I've played that goes from right to left, and it *did* feel a bit weird - as if you had less space to move in. But that may be more a result of the autoscrolling than the direction.
  4. Opera 9.60 on openSUSE Linux 10.2: -- Opera - Java Console -- Java vendor: Sun Microsystems Inc. Java version: 1.6.0_11 type 'h' for help -- 2 MIDI Devices: Real Time Sequencer *this is a Sequencer instance Java Sound Synthesizer *this is a Synthesizer instance
  5. Why do you think a castle and modern weapons are mutually exclusive? Resident Evil 4 had both.
  6. Programming in the world of tomorrow.

    Quote: The problem is that people think sequentially. Our concious mind is inherently single-threaded. When asked to describe any given procedure, the vast majority of people will break it into sequential steps. Even developers do this. That they describe a procedure in a sequential way doesn't necessarily mean that they think in that way. Perhaps natural language just isn't very good at describing partial orderings, and people will describe something as a sequence of steps even if they implicity know that some of the steps can be swapped.
  7. getline() problems

    Are you using other input methods like "cin >> variable" before this piece of code? If so, there might still be the rest of a line in the input stream, which std::getline then grabs.
  8. LoadLibrary() remplacement

    Couldn't you just use a scripting language like Lua for your AI?
  9. No, not "yeah". I thought camera_offset was the offset of the camera in the world, not the offset of the view window on the screen. The basic way to do this is: - Calculate a view rectangle "viewrect" (world coordinates, pixels) based on the player position (world coordinates, pixels), and adjust it for special cases like the edges of the map. - Draw each object or tile that intersects the view rectangle at camera_offset + object.topleft - viewrect.topleft.
  10. I haven't read all of your code, but I think that the following line is wrong: renderer.Render(Renderer::D2, player.Position() + camera_offset, player.Image_Fn(), clip); If the second parameter of Render is supposed be the position to render to (pixels, screen coordinates), and camera_offset is the top-left corner of the camera view (pixels, world coordinates) and player.Position is the top-left corner of the player (pixels, world-coordinates) then it should be player.Position() - camera_offset.
  11. C++ SDL. Help with surface

    I think you misunderstand surfaces. They're just a bunch of pixels. Blitting an image to the screen just means copying the pixel values, it doesn't magically attach the image to the screen. Blitting the whole screen is really the most simple way to do what you want. There are more efficient ways (google "dirty rectangles"), but they're more complicated.
  12. 1,2,3 are pushed on temporary copies of vec which your conversion operator creates. Quote: It does not matter if I declare it as: operator vector<E> () or operator vector<E>& (). I still get same result. (Obs. I can provide accessor ot vec member variable, or even make it public; but I wanted to use operator () just for using it). If you use "operator vector<E>& ()", it should work, but you need to adapt the main function too, i.e. ((vector<int>&)v).push_back(1);
  13. Quote:Original post by Telastyn A knows of interface. B knows of interface; knows of A. That's exactly what I meant. Having now read your code snippet, that's exactly what it's doing; except it's using a closure instead of an interface, but that makes no real difference. OK, so you have nothing against cycles at runtime. Sorry for the confusion. Although I still think that your structure could be a bit too rigid in some cases. For example, what about a missile tracking its target? Would you really let the common parent of the missile and the target handle the interaction between them?
  14. Quote:Original post by Telastyn Require? No. Serve as a good framework for design? Certainly. And forgive me for my ignorance, but I fail to see the distinction between a tree and a graph lacking cycles. Aside: not all acyclic graphs are trees, for example the graph with nodes A, B, C, D, and edes A->B, A->C, B->D, C->D; but that wasn't my point. My point is that you can have reference cycles at runtime without having dependency cycles in your code. Why does it serve as a good framework for design? You simply assert that it is inherent to OO ("Knowledge in OO needs to be in a tree."). If there are relationship cycles in the problem domain, which OO is supposed to model, and you can represent them without dependency cycles in your code (using interfaces), what advantage does pressing them into some unnatural tree form *at runtime* give you? I can only imagine that it's because of lack of garbage collection. But then this is a consequence of using a language without GC, not a property of OO.
  15. Quote:Original post by Telastyn 'knowledge' in OOP needs to be in a tree. One class (game usually) knows about few classes (and their interactions); each of those knows about a few classes (and their interactions) and so on. Classes may know of their subserviants, but never their parents or siblings. As a general rule, if you find a member method needs to know about a sibling, then it should be a method in the parent that acts on the two classes. As a general rule, if you find a member method that needs to know about parent look towards a delegate for the parent to hook into. No, in general OOP requires no such thing. Show me one book about OO that proposes this. Cyclic dependencies between *classes* are undesirable, but you can break those dependencies using interfaces, that is: you can have cycles of objects referencing each other without cyclic *class* dependencies. Avoiding cyclic references might be a useful compromise strategy in a language without Garbage Collection, but it certainly isn't a general OO principle.