Jump to content
  • Advertisement

Fenrisulvur

Member
  • Content Count

    289
  • Joined

  • Last visited

Community Reputation

186 Neutral

About Fenrisulvur

  • Rank
    Member
  1. Fenrisulvur

    Python type checking?(reloaded)

    Quote:Original post by ibebrett small dev team Eh, this is more-or-less it. Your focus is on smaller projects, likely from within a more freeform development lifecycle and with an emphasis on pragmatism. Bugs are probably by-and-large tolerable, no? I, on the other hand, am preoccupied with robust, correct software, and find strong static type guarantees very useful. Nevertheless, outright removing explicit type declarations on variables in a language constitutes an extreme and unjustified stance in language design. Quote:Original post by ibebrett Code which checks whether a variable is a type instance usually is not futureproof even slightly. That's a pretty strong claim, one which I can't really reconcile in general. Quote:Original post by ibebrett add: in addition, types in python can be generated at run time (which for us happens occasionally. You can't compile time check those. I think you're demonstating a lack of familiarity with how such patterns are handled in stricter languages, and the benefits offered by providing clear contracts denoting the properties to be implemented by a dynamically introduced type for it to function properly throughout a system. My experience is with Java - pulling in concrete types dynamically only requires very minimal reflection, and the overall approach is far more rigorous and robust than that seen in scripting languages. Mind, dynamic code generation, outside of some really specialized areas, usually turns up as a byproduct of some sort of bad design or coding practice. You should look long and hard at the sort of things you're generating at runtime, if a more mundane solution would do the job then they're probably an unneeded complication.
  2. Fenrisulvur

    Python type checking?(reloaded)

    Quote:Original post by aeroz I suggest not to check the type of the parameters. All you have to do is say that 'ship' needs to provide the posX and posY attributes. Then somebody can use your function with any type that is compatible with ship. Duck typing has its uses, but as a universal practice it's a terrible idea. Robust software development should leverage every reasonable formal verification measure available, which is pretty much limited to compile-time type checking; and further, static (particularly manifest) typing results in definite, intrinsic and local documentation of the structures operated on by a routine, and hence a significant sanity check in complicated projects. Also worth noting is that explicit restrictions of type are often crucial in the development of secure APIs for untrusted code. In response to these points I often get complaints about lengthy manifest declarations breaking a programmer's flow - but if you're writing robust software, why the hell does this matter? You're meant to be a methodical drone implementing a software design, not hacking away as though you're flying a friggen fighter jet. Paramount to writing good code is clearly defining data structures and processes, and making the relevant details explicit. Bluntly, the lack of optional manifest typing in Python is a mistake, because one must resort to this kind of cruft: def MoveShip(ship,x,y): assert isinstance(x, float) assert isinstance(y, float) assert isinstance(ship, Ship) # ... That is, if you feel bringing the roof down with an assertion failure is an acceptable response to a type mismatch, which it probably isn't. This is to say nothing of the inviability of basic automated type verification. The manifest version is obviously far more eloquent: def MoveShip(Ship ship, float x, float y): # ... EDIT: actually, the decorator above is a bit of an improvement. Still not what it should be, and it should be a standard feature; but it's better than a pile of isinstance calls.
  3. Fenrisulvur

    Coding in bed

    Laptop here, too. I've been doing it for years - it's absolutely the most natural thing in the world, even if Randall disagrees.
  4. Fenrisulvur

    Distance calculation without square roots

    Quote:Original post by Palidine I hope that you were at least interested in trying to remove the square root because a profiler told you that sqrt was your biggest performance problem. Typically the biggest limiting factor in A* performance is accessing the open list; I would think that sqrt wouldn't be anywhere near the top of the profile. O(log(n)) per poll at best, so, yeah, this. On this note, it should be pretty clear that a heap-based queue (PriorityQueue in ADT terms) would be your best bet for an open list. Normally something like a graph or a grid directly corresponding to the search space is your best shot for a closed list, and accesses should be O(1). If either of these is deficient, that's your bottleneck.
  5. += operator. x + x = 2x. ;) I guess you could change the line to x = 2*x - oldx + a*fTimeStep*fTimeStep; to avert the confusion it appears to have caused you. There's no significant reason why you would use the += operator here, I guess the author just felt like it at the time. Anyway, in case it isn't clear where basic Verlet is coming from, derivation from Taylor series: So it's definitely 2x.
  6. Fenrisulvur

    Dynamic SAT Collision Times

    Do your convex polygons undergo angular motion?
  7. Fenrisulvur

    A strange dilemma, need help!

    Quote:Original post by Tom Sloper Quote:Original post by Fenrisulvur My understanding of honours is an extra year structured as half coursework, half research project set and mentored by an academic. So if honours are "included" in a 3-year degree, is that a 2-year degree plus the extra year? Or does it still work out to 4 years? It shouldn't be "included" in a 3-year degree at all - that's known as Doing It Wrong. In my view it's not a true honours programme unless it's an additional year primarly concerned with an academic research project. Anything else is a bastardization of the very idea. Quote:Original post by Tom Sloper And when you say it's competitive, does that mean some people do the degree without doing the honours? And if they do, does that mean they do 3 years? Yes. They're pretty average students almost by definition, though. I don't know how pretty average students could make it in the games industry.
  8. Fenrisulvur

    A strange dilemma, need help!

    Quote:Original post by Tom Sloper Quote:Original post by Fenrisulvur Quote:Original post by yaustar Quote:Original post by Tom Sloper 1. A 4-year degree is a better door-opener. You should read this forum's FAQ (click small View Forum FAQ link, above). You'll also find tips for making decisions in the FAQ. Not every country's degrees are 4 years. In the UK at least, a degree is 3 years. That's without honours, right? (Hint: do honours) Huh? What? What are "honours"? Do they add time? Obviously I don't know anything about the education system in your country. Oh, right. Clicky. This page gives a generic overview of honours at the university I'm attending, though I wasn't aware of any faculties offering the latter two bullet points. My understanding of honours is an extra year structured as half coursework, half research project set and mentored by an academic. Entry is competitive. There are some four-year courses offered here, most of the engineering degrees come to mind. I don't think Science or Arts degrees are offered as four-year degrees, though. Mind, double-degrees or "combined" degrees such as Arts/Science, Engineering/IT, etc are available and span 5 or more years - I'm planning an IT/Science.
  9. Fenrisulvur

    A strange dilemma, need help!

    Quote:Original post by yaustar Quote:Original post by Tom Sloper 1. A 4-year degree is a better door-opener. You should read this forum's FAQ (click small View Forum FAQ link, above). You'll also find tips for making decisions in the FAQ. Not every country's degrees are 4 years. In the UK at least, a degree is 3 years. That's without honours, right? (Hint: do honours)
  10. Fenrisulvur

    Moving Sphere against AABB Collision

    Well, that sounds like an ill-conditioned numerical solution. This stuff is always a bit of a bitch. I imagine you should have sphere-edge down to circle-point, no? Looking back on some working I did on this stuff a while ago, circle-point (or hypersphere-hypersphere in general) is a quartic problem under constant acceleration, or a quadratic problem under no acceleration. I know of situations in which quadratic closed forms can go ill numerically, and I know of work-arounds to that; but quartics and other means are another kettle of fish entirely. Could you be more specific about which (regardless of whether or not it's either of these) your situation is? I cbf looking at jyk's code, especially given it may or may not be relevant to your problem.
  11. Fenrisulvur

    Moving Sphere against AABB Collision

    Could you explain said border case? (I haven't bothered looking at the link) What you're asking for should be pretty straightforward. I can only really invision three collision cases: sphere with side sphere with edge sphere with corner The first is very similar to testing for AABB collisions, and the last is almost identical to sphere-sphere. The second is a little trickier I guess, I'd be projecting to a plane to which the edge is normal (for AABBs that's effectively just ignoring a co-ordinate) to effectively turn it into a 2D circle-point problem. If you provide a little more detail on motion (obviously the nature of motion of objects involved is typically very important in a priori), I might be able to give a better response.
  12. Fenrisulvur

    Pi = 4. Discuss.

    Quote:Original post by Way Walker Fenrisulvur: For someone who accuses others of writing like philosophy students, your math looks like a philospher's or a new student's. Reading it is slow going because you spend so much time defining common terms and notation Eh, I already more-or-less conceded that I was stumbling around in the dark for the latter half. A lot of these concepts are pretty new for me. I'm not exactly sure which terms and notation you're taking as "common", here, or in what sense. Are you rejecting structure like metric spaces and definitions like that of the circle I gave in favour of some unstated common-sense interpretation, or are you familiar with such structural abstractions and objecting to having it all rehashed? I maintain that an answer to the troll's paradox is going to have to be structural, it's going to have to illuminate criteria which govern whether a sequence of bounding shapes do or do not coverge to give the circumference of the circle, and we're probably going to need a formal definition of what a circumference actually is. Quote:Original post by Way Walker (you even got fed up with it and just said you would be using "vector space axioms", which usually goes without saying) Oh, no it doesn't. That line would've been torn apart in a more formal setting, I hadn't defined any structure other than a metric at that point. Do you have any idea how many vector spaces can be constructed on R*R? Quote:Original post by Way Walker It would also help if you didn't use mathematical notation to cram so much on a single line. It's like complaints that Perl can look like line noise. (I often get complaints about being too heavy on the math, so this is a bit of the pot calling the kettle black. [smile]) Haha, point taken.
  13. Fenrisulvur

    Why is 'Murder' so popular

    Quote:Original post by LancerSolurus Why is murder so popular in current games? I have my own ideas about why it is (no repercussions for one) but I would like to hear your thoughts... The list is nigh-limitless, really: outlet for apparent bloodlust, demonstration of masculinity, romanticism of the sword/gun, outlet for frustration/anger/boredom, fantasy/curiosity factor, adrenaline factor, effectivity as dramatic effect/plot device, strategic factor... This stuff has been studied for decades - why violent media appeals, what effect it has on us, etc - and as far as I'm aware the establishment is far from reaching any significant consensus on any of it. We don't even know whether or not "mature" content adversely affects children. If your point is, "it'd be nice to see more games that don't place a significant gameplay emphasis on killing people", then, sure, I agree with you, there are surely many interesting concepts to explore in interactive media other than combat and such. But try telling that to the market.
  14. Fenrisulvur

    Is transitioning from C# to C++ really THAT simple?

    You recently birthed a thread asking whether C# was leading you away from AAA Microsoft/Sony development, didn't you? Look, you have completely the wrong idea on this one. I know it's natural as a newbie to place huge amounts of emphasis on the significance of the language to your end goal, and to an (ostensibly inflated) extent the more seasoned among us do debate the finer aspects of implementation language/platform details ad nauseam, as well. That's all fine (er, largely, anyway), and for the most part has it's place. But actual game development, or indeed development of any complicated software product, isn't anything like that. What you'll come to understand, is that the real meat of game development, the seriously hard problems, the stuff that'll separate you from the pack (or the pack from you if you don't recognise this at some point), are far deeper and rooted in far more immense and richer theory than meagre concerns like which language you're going to use to encode it in. Take, for example, physics*. To even start to properly grasp the physical interactions a AAA studio attempts to simulate in a game, you're going to have to come to grips with a monumental, astonishingly perplexing mindfuck of a culmination of mathematical brilliance that is The Vector Analysis. Then, note that university physics students usually get to contrive their investigations and exercises into simplified scenarios and experiments - a physics programmer has to write procedures which handle every case, and maintain the brick-shithouse integrity of invariants, complicated conditions which must hold throughout the course of play (eg. stuff shouldn't go through other stuff). Many problems in the area - collisions, for example - are famous for being absolute nightmares to handle robustly. There are many important phenomena in games which you'd struggle to think how to represent, let alone simulate - how the friggen hell to you handle fluids? Air? Water? Deformable anything? How does it all interact? And how do you balance this stuff juice-wise with the rest of the demands on your chunk of CPU time? Game physics is one of the genuinely, monumentally hard problems involved in AAA game development - but in among the several other monumentally hard problems in game development it's just another piece. Graphics is the "archetypal" example of a hard problem, and because I plainly know next-to-nothing about it I'm not even going to touch it, suffice to say many a game superprogrammer bases an entire career upon the field alone. What about AI? Audio? Networking? What about the infrastructural "kernal" of a game engine that ties all this stuff together? Ultimately, practically all of this stuff exists in and around the design phase, and by comparison implementation (that is, writing code) is intended to be a methodical and uninteresting by-product. You should also keep in mind that you will require a strong education in theoretical computer science merely as a basis from which to properly grasp any of these fields. The fact is, to be at all viable as a big-time game programmer, you need to be a veritable go-to guy on at least one of the big problems, and you need to have a reasonable understanding of what everyone else is doing, too. Attaining this level of understanding is brutally hard - learning a pissy little language like C++ is a friggen cakewalk in comparison. If you want to do something significant to better your chances of making it into serious AAA game development, serously: go to university, take a computer science course, and don't be that kid who whinges about not doing things in C++. And, seriously, if, after the immensity of these challenges truly sinks in, you have the mind, ambition, and stomach for these things: good luck. The world could always use more people so dedicated. *Using this as an example because my interest is simulations and such.
  15. Fenrisulvur

    Pi = 4. Discuss.

    Quote:Original post by JoeCooper Is any of this relevant or am I barking up the wrong tree? Actually, I'm now leaning towards an explanation based on many of the ideas you've put out there (the idea of one "approximation" being "better" than another, the idea of the "approximation" "doing something" to improve during convergence, etc), but I feel it must be set upon a firm and concise axiomatic base. Quote:Original post by JoeCooper Can we assume that x^2+y^2=r^2 is a valid test for whether or not a vertex lies on a circle? Is that a given? This seems like a reasonable start. More concisely, I'd like to define a circle in the following manner. First of all, I'd like to establish a "context", so to speak (I cannot for the life of me recall a better term, so bear with), from which to establish the idea of a circle. I'm going to work from the set of ordered pairs of real numbers, in other words ; but I'm also going to need a bit of extra structure, specifically a metric, which is a function which assigns a notion of distance to all points in it's domain. In particular, we are obviously interested in the Euclidean metric, which I'll define here: Another example of a metric, which I mentioned earlier, and would like to return to later to observe some interesting points, is the Manhattan metric: This metric is obviously based on the idea of movement constricted to "orthogonal" directions. A Manhattan distance between two points is the sum of the "vertical" distance and the "horizontal" distance between two points. Anyway, back on course, putting together the set of two-tuples of real numbers, with the Euclidean metric, gives us a metric space, ie. a two-dimensional Euclidean metric space. From here, I propose the following definition: a circle of radius r around a central point p, is the set given by In English, the set of points in two-dimensional Euclidean space which are exactly a distance of r away from a central point p. Is this definition acceptable? Based on what little I can gather from the Wikipedia definition, I feel relatively justified in the use of this definition. Also, there are some interesting images of unit circles which can be arrived at by using a different metrics here. Now, I'm not wholly sure how to formalize a notion of "circumference", but I'll give this a stab anyway. Firstly, I'm interested in the objects "enclosed" by a circle, and I'll specify them as follows. I define the line segment between two points: ...er, I'm assuming vector space axioms here. Hopefully the appropriate notions of addition and multiplication are clear, so can we please let this one slide? :P Now, I say that a point is "enclosed" in a circle if the line segment between it and the circle's centre doesn't contain any points in the circle. Formally, the set of all points "enclosed" by a circle: Hopefully it is clear that this is equivalent to the "open ball" of radius r around p: In this context, the open ball is in essence an "open disc". Now, since I'm not really familiar with any standard formal definitions of a perimeter or circumference, this bit's going to get really sketchy. I'm going to define a "circumnavigating sequence" of an open ball, as a sequence of points of length n, and the "circumnavigating path" as the set, I require that every true circumnavigating path have the following property: ie. the "path" traced out by following the sequence does not "enter" the open ball enclosed by the circle. Observe that the path may touch the circle itself. The next bit's pretty ugly: I need a notion of "reachability" of a point from another, which I'm going to give roughly as which basically means that P(p, q, S) for any two points p and q, and any set S, is the condition that there exists a path between p and q that doesn't coincide with the set S at all. I use this to give the second property I require of any circumnavigatory sequence: where p is the centre of our circle. This is to say that, together with the first property I stated, X bounds a superset of the open ball Br(p). It's a pretty sloppy way of specifying it, you could specify a sequence that overlaps itself and does all kinds of crazy crap yet still bounds the ball; but hopefully it will suffice anyway. Obviously, the length of the path given by X is Now I can finally get to what I've been angling for! Obviously, there is a "minimum circumnavigatory sequence" of size n, which I'll formalize like so: That is to say, that Min Xn is the minimal possble circumnavigatory distance specifiable in n points. I suspect that the regular polygons of Archimedes' method of exhaustion may actually correspond to these vertices. Nevertheless, I'm actually going to offer as the circumference of the circle . So, my conclusion is that the troll has defined a path around the circle, but that it is not minimal under the Euclidean metric, and hence not the circumference. Hmm, at about this time I'm thinking that I've probably gone to too much effort towards the end of this construction to reach what sounds like a trivial conclusion in my head. The troll is concerned with enclosing the circle in a shape and gauging the perimeter of that shape a it contorts to fit the edge of the circle, and I think I've formalized an understanding of the meaningfulness of such a construction to circumference; but the same point can probably be made reasonably concisely without all this Hilbertesque clutter. >_> Nevertheless, I think the idea that the convergence need be designed to minimise perimeter in order to home in on the circumference, rather than merely fit points to the surface, has become very, very obvious. That is to say, of the set of enclosing shapes of n vertices, some have smaller perimeters than others, and the one with the smallest perimeter is the "most correct", or closest approximation.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!