Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

220 Neutral

About Rainweaver

  • Rank
  1. Rainweaver

    Friendly F#: Fun with game programming and XNA

    Nice effort. I don't have a compiler to check for errors and other quirks but I believe you could have used a tad more (active) pattern matching in lieu of if..elif..endif constructs. (e.g. Chapter 5 coroutine impl and AI samples, also in Quadtree class impl). Interesting usage and explanation of units of measure, and coroutine wrapped in a monad. Good luck!
  2. Where do I start? Nowhere. Thanks for your opinions.
  3. Since version 7 you will have to pay 35$ to use Reflector. News on ZDNet The tool is vital for any respectable .NET developer. They could have just open-sourced it, couldn't they?
  4. Rainweaver

    C# Variables imported into a IronPython Script

    You should be able to create a ScriptScope from the IronPython engine and create / retrieve variables. See if this helps: http://www.voidspace.org.uk/ironpython/dlr_hosting.shtml
  5. Rainweaver

    Lua parser

    Try out http://www.scintilla.org/ used in http://www.scintilla.org/SciTE.html -- If you're looking for just a parser, try out http://www.antlr.org/, which should really have a way to output c++. The Lua grammar on their site has a few flaws, though, most notably long strings and long comments are not handled, afaik
  6. You tend to hide interface consumers from changes as much as possible not to break things. You also don't want to expose public member variables very often, unless you're creating simple types such as a Point, or Vector, which for a number of reasons benefit from being as simple as they can, and also exist to merely store state. It really boils down to the degree of modularity you're aiming for. Automatic properties (which are not "empty") are a commodity for people programming against interfaces.
  7. For instance methods, "this" is loaded via ldarg_0, not ldarg_1. I think the method AddTouchLocation should be static and accepting an explicit ref param - forcing a "this" byref into an instance method feels like looking for troubles. I also seem to recall that unbound delegates should perform faster than their instance counterparts, but it's totally speculative.
  8. Rainweaver

    Dynamic water ripples

    Quote:Original post by Flimflam I'm pretty sure the foam you see close to the terrain in World of Warcraft is the result of a depth test. It probably checks the distance between the water and the ground under it and uses the foam texture if is within a certain distance threshold. Nice, thanks. I see foam is also slightly animated (looks like it's made with flat, dish-like particles). I think it'd be efficient as a post-process effect, is it a post-process effect? What about the ripples instead?
  9. I've always been intrigued by dynamic water ripple effects in games. A few years ago I found Humus' demo and I believe I understood how it works (though I had scarce success in recreating it, as I'm not really a graphics programmer). I noticed that World of Warcraft has improved its water rendering (which includes ripples), and it rekindled my interest in understanding how it works with bigger water bodies (bigger as in arbitrary size). I'd also like to know what technique is used to draw foam where the water mesh hits the terrain. Since this is actually two questions, my apologies. Thanks in advance.
  10. Quote:Original post by zz2 Is anonymous delegate that doesn't allocate possible/or not? In article Shawn says: "Note that anonymous delegates come in two flavors. Free standing ones (which do not reference any variables from their parent scope) can be implemented as simple static methods, and will not cause any more allocations than any other kind of delegate." I'm not sure what exactly he means by that. I think he's mentioning closures, implemented with objects. See the "allocating lexical closures part". To reiterate: var myValue = Console.ReadLine(); Func<bool> myfunc = () => { return myValue == "test"; //myvalue belongs to the parent scope }; var ret = myfunc(); Behind the scenes becomes: class MyFuncCall { public string p1; public MyFuncCall() { } public bool Invoke() { return this.p1 == "test"; } } var myValue = Console.ReadLine(); MyFuncCall myfunc = new MyFuncCall(); // object allocation here myfunc.p1 = myValue; var ret = myfunc.Invoke(); Or something to that effect.
  11. Rainweaver

    Components for entities - why?

    Quote:Original post by Echkard Quote:Original post by Rainweaver An entity system is not just about composition, it is also serialization, net communication, message-dispatching...I'm sorry, but there's nothing unique about any of this in an entity system. Your definition of an "entity system" as "anything with objects" in it is not wrong, it's far too loose to even be meaningful. I suggest the following as a good starting point reference on what actually is unique about composite entity systems: Refactoring Game Entities with Components I'm not sure if you're doing this on purpose or you really can't understand what I wrote. I guess the condescending tone made it clear from post 1 that you have nothing to contribute but picking on words to make you look smart. It's okay, I have nothing more to say. I just hope others are as patient as necessary to not let the discussion wither.
  12. Rainweaver

    Components for entities - why?

    Quote:Original post by jyk ...but the 'talking rock that gives out quests' is a good example. Where would this entity fit in a traditional inheritance-based hierarchy? I suppose you could figure it out, but the point is that with a component-based system, you don't even have to *think* about it; creating a talking, quest-giving rock (or any other entity type that's an arbitrary aggregate of disparate characteristics and behaviors) is as easy as creating any other type of entity. Not only this, but with a fixed hierarchy of objects, introducing a new object means recompilation. And if you're using scripts, you're using code as data, which may or may not be a good way to describe and/or store information. Quote: Original post by Eckhard The proper name is "composite design pattern", but some early game developer thought he had stumbled onto something new, and therefore created a separate name for it. The problem is made worse by all the multitudinous ways the term "entity" is used in programming. An entity system is not just about composition, it is also serialization, net communication, message-dispatching, all of this towards the implementation of an entity system in which entities have (brief) lives and relate to each other in their virtual space; in this regard, the english definition of "entity" that swiftcoder mentioned is way better than "composite design pattern". And since there's no One True Way, as you may have realized by now, arguing about definitions is really pointless. Only a rhetorical exercise. Quote: Original post by Telastyn The utilities to provide unsucky interaction between aggregated entities or multiply-inherited base classes or message hooked bits of a whole just aren't there with the tools we have. Programmers can conceptualize what they want, but not how to implement it. I see what you mean, but it can be implemented. Only tiring and bothersome. Runtime code generation, text templates, there are options. Entity systems are not a fad, why would they be? It is not a single pattern, it is not a single way of implementing relationships between game objects, it is not a trend. It's not like you have to implement ESs like there's no tomorrow. They could also be part of the tectonic shift that carries managed code, dynamic languages and indie games into the world of game development. Who knows? Like it? Code it. Not convinced? Use something else. The good of programming. Reinventing the wheel when the wheel doesn't look good enough :)
  13. Rainweaver

    Components for entities - why?

    Heh, I think Kylotan is prepared to counter every argument, hence the question :) Quote:Original post by Kylotan Of late there's been a massive increase in the number of people wanting to move towards component-based systems for their game characters, sometimes confusingly called "entity systems". I look for "data-drivenness", reuse, extreme flexibility. Component-based systems are based on those principles. The downside is that they require a lot of development time, careful design and last but not least, a thought to performance - because resolving complex behaviour at runtime is bound to be slower than just a bunch of virtual calls. Entity is a common synonym for game object. Actor, entity, go, game object, object, prop. Quote: Is there a 'third way', that neither requires monolithic classes in a rigid hierarchy, nor a complex binding of algorithmic Lego? Why is it that, despite so many people being sure that components are the answer to the problem, we have nothing remotely resembling a consensus on how these components communicate (or if they even need to communicate at all)? The third-way is when you know what to hard-code and what to resolve at runtime, basically a mix of what you said, and I can't tell if there's a "fourth way". Why are you surprised about lack of consensus? I'm not, when I see stuff like CORBA, DCOM, ICE, what have you... I for one think that communication is fire and forget, and based on messages. However, you could say that function calls are "messages" to an object (Smalltalk comes to mind). So really, it depends on how you want to approach the problem. I've been trying to write an entity system for three years now (and counting). There are so many issues to tackle it's almost masochistic. So yeah, I keep asking myself if it's worth it. The answer is: it depends :)
  14. Quote:Original post by Wibbs I had already looked at memory streams, but aren't sure how they work with characters as the number of bytes a character takes is dependent on its encoding. You have to agree on encoding with the sender, so that you can decode what you receive accordingly. If it's something you can't control, or you don't know in advance, you have to check if the byte array starts with a "preamble" specifying encoding, otherwise you're forced to come up with funny methods until you receive a string you can tokenize successfully. Otherwise it's just something like this: var bytes = Encoding.Unicode.GetBytes("my data\rmy second packet"); socket.Send(bytes, ...); var str = new string(Encoding.Unicode.GetChars(recvData)); var packets = str.Split(new char[]{ '\r' });
  15. Hello Phil, Have a look here: MemoryStream. I'm not sure about your initial requirement, though. What is it you're trying to do exactly? hth Edit: More info
  • 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!