• Content count

  • Joined

  • Last visited

Community Reputation

475 Neutral

About NEXUSKill

  • Rank
  1. The template paradox

    Yes, this is the case, this class is meant to be inherited by other classes that need to be serialized and they must set themselves as the template parameter. Though it is true that this class declaration by itself does not force its data to inherit from it, it could be the same class with the same type, but that would be pretty pointless in my project. It goes just as unbird said.
  2. The template paradox

    Oh god I laughed so hard when I read the pattern name! xD
  3. The template paradox

    each class implements its own specialized serialization, they inherit many common methods from this class and any loaded resources are held in a static hash implemented in the base serialization class.
  4. The template paradox

    I just wrote this, it works perfectly, but I don't know what to make of it in terms of what the concept means...   public class SerializedData<DataType> where DataType: SerializedData<DataType>   This is a template class in which its template type must be derivate of the same clase with the same template type.... sounds terribly weird
  5. spriteBatch.Draw slow?

    Then I'd go with phil_t's explaination, spritebatch is not meant for point sprite particle systems, there are samples in xna's resources webpage that implement point sprites, particle sistems both in 2d and 3d, look it up.
  6. spriteBatch.Draw slow?

    Could you post your test update and draw methods? I've seen severe errors in implementation born out of bad examples, first clue would be if you are executing the End method for every particle, that would be VERY bad, there are other common errors though. EDIT: Also no, SpriteBatch is not a shader, it does HAVE a shader, which you can have access to through the XNA resources, you'll find it under sprite batch default shader or something like that, what srpite batch is, is a batchnig and sorting abstaction algorithm, so you don't have to deal with those things yourself, which works wonderfully until you WANT to deal with those things yourself.   It takes away the tedious task of figuring out what is in front of what and if used correctly it optimizes instructions to the graphics card.
  7. Auto update systems - yes or no

    Well there are a few factors to take into account, mainly the nature of the software and the target audience/consummer. If the consumer is likely to be tech savy, they'll want to be given a certain degree of control, if not, they'll likely expect you to do everything for them.   Personally I hate resident processes, such as the google updater or the adobe auto updater, I hate a program being there running consuming my computer's resources while I'm not even thinking about their software, adobe reader is probably the worst example of this, you open it what, once every coule of months? meanwhile adobe has a resident software active on your computer full time, why? why does that need to be there? Steam on the other hand, can be set so it doesn't start at bootup and will only update when you start the program.   Thats another issue for me, unless the update is absolutely required for the software to function, when I open the program I want to use it, making me wait for an update is an inconvenience, if the update is optional, I would prefer to delay it to when I close the application and no longer care about it. Thats the way I handle windows updates, I apply them once I decide to shutdown the computer, not when I want to use it. Taking the user to a website is pretty old school and annoying, its not even necessary, you can trigger the update download and instalation without going anywhere, do that.
  8. Against most of wat was said above (probably, for what I can gather since I didn't read it all), none at all. In my experience, in order to do things right, you must first do them wrong, at least one time. The first thing a GAME programmer should do (this most likely does not apply to other more structured programming tasks) is to make a working prototype. On one hand the designers need to have a working prototype to test their ideas as soon as possible, they may not want it, they may not ask for it, they may even refuse to use it after you made it, but you should do it just the same. Why? because before you can design anything thoroughly, you must understand its deepest inner workings, and you can't just sit and think for hours until you got it all in your head, make drawings and write and re-write designs until its just perfect. You are gonna forget something. And even if you do get a clear design that looks good on paper, you still don't have any empirical evidence to support your theories and most likely at some point someone is going to want you to change it, maybe even yourself.   So make prototypes, the best way to understand everything involved in the inner workings of a system is to implement said system. Once you got it working, make note of its flaws, its dependancies, profile it, and then go to the design process with all that knowledge that no amount of thinking can magically conjure up.   If you are asked to implement an input reading system and you have done so before, design might come easy to you, but then they tell you "it has to work on touch screens", and you never done that before, go do it, understand its needs before trying to apply your known designs to it, once its working you'll know if it fits your designs or you need to adapt them and how. If you've implemented Character control many times before, but you are asked to do so in Unity, which you never used, go make it work first. Go for quick and dirty and just get it working, you'll have something to show for and you'll be able to make better estimations when asked to. I've banged my head against the wall trying to come up with designs that foresee any need of a system many times before, I've always understood it much better after making it work.
  9. Levels are not game states, levels are content of a game state, specifically, gameplay, Game states are used to sepparate contexts of your application that have radically different logics, a menu is very different than gameplay, and maybe you have other states, like a world map and a battle stage, the logic in each of them is very different to the others and there is a connection between them, look up state machines. Between different levels, the logic of the gameplay itself is likely to be more or less the same.   As for levels, if your game is linear you could have a simple array, if the array is too big it might be more clear and efficient to hold a link to the next level within the current level itself, maybe in the exit, so if you have multiple exits you can use a different link in each one. As for the transition from one level to the next, you just initialize the Gameplay state with a new level as content, maybe put in a loading screen if it takes a while.
  10. A* is as fast as it comes, but huge maps are huge maps and simply exploring them with A* will inevitably at some point become too expensive. If the map is enclosed, like a city or the inside of a building, there is a lot you can do to simplyfy A*'s workload, the map is not likely to change and going from A to B will always require the same path. When you edit and save the map, you can precalculate paths between key points and store it along with the map data, so when someone wants to go from A to B it simply loads the saved path.   On an open map, there should always be choke points, natural barriers that split the map in zones, like a bridge over a river, a slope that climbs a cliff sided mountain, stuff like that, the path to cross an entire area from one chokepoint to another will always be more or less the same, and can be precalculated, you then use A* for more short range adaptations.
  11. Calculating arrival with soft turn (help!)

    I'm thinking of putting together an article for flocking and steering behaviors, the working code I have now I cannot share due to contractual obligations but I can make something on the outside and get a working demo of the technique.
  12. Calculating arrival with soft turn (help!)

    The target ghost worked quite well, its not perfect and its subject to a fine tuning of the kinematic parameters of the mobiles, but gives out a nice effect for what I wanted, A more precise method would probably exist but I don't need to dig deeper at this moment. For reference, the idea is to create a ghost mobile starting on the target position and orientation and having it move backwards based on the same logic used to move forwad with some reversed signs and considerations, the positive and negative boids are aligned you can move on to follow the target directly and arrival should do the rest quite nicely.
  13. Calculating arrival with soft turn (help!)

    I already have arrive implemented, and the mobiles do arrive and slow down at target, the problem is when you want them to end up looking with a specific direction and you don't want them to reorientate after arriving, but rather come softly from behind the desired heading.   I'm already using steering behaviors for this.   The target ghost boid as I've come to call it seems a promising approach, though it still needs tweaking.
  14. Calculating arrival with soft turn (help!)

    Another way to do this my coleagues and I thought of, that aproximates the previous idea well enough and might even take other things into consideration (obstacle evation and other movement rules) is to simulate an anti-mobile, that starts at the target and tries to get to our mobile, with the same parameters our mobile should use on arrival, deceleration speed, turning angle and so on, each frame our mobile moves towards the anti-mobile instead of the final target, and the anti-mobile moves toward the mobile.   Once the path of the mobile towards the anti-mobile requires no steering (both mobiles are moving in a colinear fashion), we stop moving the anti-movile, and once the mobile catches up with the anti-mobile, our mobile tries to move to the target, but from a state that favors a good arrival trayectory.   Does this make sense?