• Content count

  • Joined

  • Last visited

Community Reputation

736 Good

About Julian90

  • Rank
    Advanced Member
  1. suggested C++ API for beginner

    Quote:Original post by captainfreedom Quote:Original post by ManTis I suggest that you DON'T use C++ as a first language. Unless of course you developed in it for years now and want to try games programming. If so, SDL is always a good choice. If not, try out Python or C#, you'll save yourself TONS of grief. No, "But ManTis, all professional games are made in C++, lulz!" is not a good argument. That's just your opinion. c++ has many advantages over other languages. It's by far the most portable language (especially when talking about non-pc platforms). There are more c++ engines available and they are more mature. And it doesn't force you to use a garbage collector. C is more portable then C++.
  2. C++ - Initializing maps?

    Quote:Original post by MeshGearFox cout << pmyContainer->myMap[key]; That is what I tried doing. It doesn't work. It gives me a: "base operand of `->' has non-pointer type myMap" error. I think before that my class code was a bit different. (*obj.map)[value] or obj.map->operator[](value) Quote: class mapContainer { public: map <string, int> *myMap; mapContainer(map<etc> *_myMap) { myMap = _myMap; } }; which seemed to work about the same as far as initializing mapContainer went, and I got the same error when trying to access the map. You should use initializer lists to initialize things where possible, if you don't include an initializer then it will be default initialized and then you are assigning a new value to it in the constructor body (note the semantic difference).
  3. C++ infinity times 0

    Quote:Original post by Numsgil Alright, I've distilled the thread Julian linked to to something like this: *** Source Snippet Removed *** What exactly is this doing? If I read the syntax right, it's declaring an array of pointers to member floats. I recognize the syntax from using function pointers to member functions. But I have no idea exactly what a pointer to a member is or would mean. Is it basically an offset in to the class? And why does the dereferencing code need to look like this->*v[i] instead of just *v[i]? Yes it declares an array of member pointers to floats which are basically offsets into the class, more precisely they are pointers to a specific member of an unspecified class instance (I think there are some cases where this isn't the same as an offset into the class). When dereferencing a pointer to member you need to specify the object that you are getting the member from which may not be this since you can use a pointer to member from anywhere, it doesn't have to be from in the class (same as function pointers). The this->*v[i] is necessary to specify that you are getting the member from this. Note that a->*b is not the same as a->(*b) (operator->* is a separate operator).
  4. Intersection of bezier splines

    Quote:Original post by WinryAsa I'm just throwing out ideas... You could do a recursive test using 2 spline sections. Each step would divide the 2 line segments intersecting until they don't intersect anymore or a certain depth has been reached. Since one could assume that the splines wont intersect most of the time, this should be a very fast intersection test and can have a very precise point of intersection result depending on the recursive depth limit. That would be what I'd try first. Are you proposing that you start with an interval in which you want to find the intersection and at each step you halve the interval and recurse on the side that has the solution? If so then its the same as taking the difference of the two curves and then using interval bisection to find the zero which has order 1 convergence (at each iteration the error is a constant multiple of the previous error). Or are you proposing that at each step he find an approximate intersection using the lines between the end-points and then recurse on each side of the approximate solution to find the new solutions? If so then this is equivalent to an approximate newton method called the secant method (once again by solving for the difference equals zero) which has super linear convergence (order (1 + sqrt(5)) / 2) which is fairly good but ideally you want order 2 (quadratic) convergence. Quote:When finding the intersection of 2 polynomial splines the problem basically comes down to solving a system of 2 polynomial equations. Say you can get your splines in the form: A = (at^2+bt+c,dt^2+et+f) and B = (gt^2+ht+c,it^2+jt+k) (I'm assuming quadratic because it's the easiest to type. The method is basically the same for higher degree) Then to find the intersection you have to solve the equations: at^2+bt+c = gt^2+ht+c //set the Xs equal dt^2+et+f = it^2+jt+k //set the Ys equal A and B are different curves so you should be using different variables for them, say t and s. What you get then is a system of 2 equations in 2 unknowns. For the 2nd order case these can be solved trivially using analytic means. For the 3rd and 4th order ones it can still be done analytically but its extremely ugly. For higher order ones it becomes necessary to use numerical methods. For a simple system like this you probably want to use Newtons Method which has order 2 convergence. Order of Convergence The order of convergence of a iterative numerical method is the value alpha such that lim{n->inf}(|en+1|/|en|alpha) = k. So an order of 1 means that at each iteration the answer has roughly one more digit accurate and an order of 2 means the answer has roughly twice as many digits of accuracy.
  5. C++ infinity times 0

    Quote:Original post by Numsgil error C2620: member '<unnamed-tag>::v' of union '<unnamed-tag>' has user-defined constructor or non-trivial default constructor error C2666: 'Float::operator +' : 2 overloads have similar conversions The types used in a union must be POD types, however, since your Float class has non-default constructors its not POD and so the types in the union aren't POD. If you are just using this for indexing in a vector class then you can get around this by using the method described here.
  6. std::vector<int> a; std::generate_n(std::back_inserter(a), 6, rand); std::transform(a.begin(), a.end(), a.begin(), std::bind1st(std::plus<int>(), 1)); Nothing is overkill in C++.
  7. Beginner/Learning Languages

    Quote:Original post by intrest86 Usually the languages I hear people mention these days are Python and C# for people to start with, but I believe both of these languages have significant downfalls for the "starter" with no experience. The goal is to find/define a language that is good for teaching programming, if not actually used for production. I think one of the advantages C# and Python have over other languages which may be far superior as "teaching languages" but useless for production is that they have a larger existing user base of experienced programmers that people just learning to program can get help from. Quote:Languages like Java and C# that force programmers to start and end with objects add a layer of conceptual difficulty that has to be dealt with before learning can start. In addition, requiring all code in functions has the same issue. Being able to right commands and just have them execute in order would be a good start. Ideally the language would also allow you to use functions and then objects, as the students have already learned how to deal with the basic flow control structures and begin to see the reason why each layer of abstraction is helpful. I'm not sure how much of a problem this actually poses, in the worst case you can just give the student the basic framework and tell them to "place code here", it's probably not ideal but it does avoid the need to introduce more complex things like classes before the basics have been covered. In the ideal teaching language though I think I agree that this is a good idea. I think that a language for learning should support a fair few different paradigms, at a minimum procedural, functional, and object oriented. It needs to have one primary paradigm which it focuses on though or the language won't be good enough at any paradigm to provide a nice learning environment, the extra supported paradigms should more be to expose the student to different ideas which they can then go explore themselves in other learning environments/languages. I don't think which paradigm is the primary one really matters that much but I lean towards functional because so many people seem to have troubles learning it after working with procedural/oo languages. Quote:In addition, the typing needs to be explicit. In languages (like OCaml) that have inferred typing the user still has to understand type, but the language itself does not give any plumbing to help a student understand. I believe it is important that the student explicitly states "X is an Integer". I don't agree that explicit typing is necessary. Using a language with type inference allows students to entirely ignore the issue of types initially and only begin to look at it as things get more advanced. If the student needs the explicit reminders of what type each thing is then they can use type annotations on all functions/variables while they are still getting used to the concept of types. I think a better alternative though would be explicit support in the IDE for displaying the type inferred for the different variables. Quote:Support from an IDE One thing I think needs adding here is support for some form of REPL or other method of interactive coding where students can experiment and see results immediately. Quote:What else do you think is important for a starting language? Any comment on my ideas? And is there a language that anyone knows of that fits these criteria or you think is a good language to learn with? I think F# fits most of what you said, the only part I can see where it really doesn't fit is that it doesn't require explicit typing and that some of the syntax has some gotcha's which can be unintuitive. The main reason I don't recommended it for learning purposes is that there aren't enough good resources for learning using it.
  8. Quote:Original post by Peon I'd just wrap it in a function (psuedo code): boolean isWithinDelta(int x, int y, int delta){ if(abs(x - y) <= delta) return true; else return false; } eg: if isWithinDelta(ball.x, paddle.x, 0.4) doCollision(); ... boolean isWithinDelta(int x, int y, int delta){ return abs(x - y) <= delta; }
  9. #include <boost/fusion/algorithm/query/all.hpp> #include <boost/fusion/adapted/mpl.hpp> template<typename Value> struct compare_value { Value value; compare_value(Value value) : value(value) { } template<typename T> bool operator()(T t) { return t == value; } }; template<typename Vec, typename Value> bool compare(Value value) { return boost::fusion::all(Vec(), compare_value<Value>(value)); } int main() { typedef boost::mpl::vector_c<int, -1, 5, 2, 10> vec; std::cout << compare<vec>(10) << '\n' << compare<vec>(3) << '\n'; } To impliment the fall back you could have two compare functions, one which with boost::enable_if< boost::fusion::is_sequence<Vec> > to handle the boost::mpl::vector_c's and one with boost::disable_if< boost::fusion::is_sequence<Vec> > to handle to uint's.
  10. C++ custom memory manager ideas

    Sounds like you mean a pooled allocator, something like Boost.Pool. Normally you only have the pool store one type of object or you store all objects of a single size in a single pool rather then using a single pool for all objects derived from a certain object. Your setup also causes problems when allocating an array since you have to return a block of contiguous memory, whereas the above wouldn't be contiguous when allocating an array of A. You could overcome that by using a separate mechanism for arrays but you really are better of grouping them by size instead of base class. A simple [and incomplete] implementation of the size based one might look something like this. template<std::size_t N> struct sized_allocator { static std::vector<bool> allocated; static std::vector<char> memory; static void* allocate() { for (std::size_t i = 0; i < allocated.length(); ++i) { if (allocated[i]) { return reinterpret_cast<void*>(&memory[i * N]); } } } static void deallocate(void* obj) { std::ptrdiff_t offset = obj - memory; std::size_t i = static_cast<std::size_t>(offset) / N; allocated[i] = false; } }; template<typename T> struct allocator : sized_allocator<sizeof(T)> { typedef sized_allocator<sizeof(T)> base_t; static T* allocate() { return reinterpret_cast<T*>(base_t::allocate()); } static void deallocate(T* loc) { base_t::deallocate(reinterpret_cast<void*>(loc)); } static void construct(T* loc, T& cpy) { new(loc) T(cpy); } static void deconstruct(T* loc) { loc->~T(); } };
  11. Scale Conversions

    You do know you never asked a question, right? You only stated what you are doing, not what your problem is or what you want help with.
  12. Help with simple physics update!!

    Quote:Original post by Holland Quote:Original post by Julian90 This will give a accumulated force of force0 * pow(friction * dt, N/dt) where N is the number of seconds which still isn't what you want, you need to do, force = force * pow(friction, dt) which will yield a total force of force0 * pow(pow(friction, dt), N/dt) = force0 * pow(friction, N) which is independent of the time step and so probably what you want. but if i use force = force * pow(friction, dt) wouldn't that always set my force to 0 if i said i wanted 0 friction? should it be friction^dt or dt^friction? If you wanted no 'friction' then according to what you wrote previously you would set friction = 1 not 0, having friction = 0 roughly corresponds to infinite 'friction'.
  13. Help with simple physics update!!

    Quote:yeah, i realize that my slowing of forces isn't effected by time right now, but i'm not really sure how to..besides just doing force = (force * friction) * dt but then won't i be required to add even more force to keep the player moving, since it will now be dropping even faster? I keep a read out of my FPS on screen and it stays fairly steady. i know not having my friction be effected by a delta time isn't good...but i don't think that's the entire problem. of course i could be wrong...i'll play around with that. This will give a accumulated force of force0 * pow(friction * dt, N/dt) where N is the number of seconds which still isn't what you want, you need to do, force = force * pow(friction, dt) which will yield a total force of force0 * pow(pow(friction, dt), N/dt) = force0 * pow(friction, N) which is independent of the time step and so probably what you want.
  14. std::string is just a typedef std::basic_string<char> string; and std::wstring is just typedef std::basic_string<wchar_t> wstring;<\tt>; so they should behave the same, you also shouldn't have any trouble just using std::wstring everywhere.
  15. Quote:Original post by taby Quote:Original post by Julian90 Quote:Original post by taby Quote:Original post by Julian90 Quote:Original post by taby Quote:Original post by My_Mind_Is_Going Quote:Original post by taby Normalizing the unit vector is like melting water. It's already melted. tau = t * sqrt(1 - Rs/r) dtau/dr ~ Rs/(2r^2) dtau/dr * c^2 ~ GM/r^2 ... A = GM/r^2 * normalize(Planet.Pos - Sun.Pos) Nowhere should an r^3 term come into play here, unless one wishes to confuse the reader. The point is there is no need for a unit vector in the 1 / r^3 form. It is very common actually to see it written like that and it's more efficient to compute: A = 1/r^3 * ( r_sun - r_planet ) = 1 square root and 1 division. A = 1/r^2 * normalize( r_sun - r_planet ) = 1 square root and 4 divisions. I know enough about grade 5 arithmetic to get the point of what's going on there. :) What I was saying is that it's nonsensical to those who are just learning gravitation, because they might get the impression that this is common. Perhaps my physics books are out of date, but I've never seen an introduction that works by intentially confusing the reader in order to avoid a SINGLE vector normalization operation. The simplification of the Schwarzschild solution, as I've posted above, contains the proper r^2 form. Anyone now learning Newtonian gravitation using the r^3 method who later moves on to General Relativity will only be confused. GR is confusing enough, and only someone who does not appreciate the underlying calculus would go about adjusting the formulas that have existed in the proper form for 300 years! No ones adjusting anything the scalar form is always written as r^2 and the vector form as r^3, theres nothing confusing about it and if someone can't understand it then perhaps they should learn some more maths before trying to do this stuff. As for this being a standard form, well I'm not the only one, this is the form that is used in all the text books I have. Anyone who even considers studying general relativity better have enough of a maths background that they wouldn't even give this a second thought, even if they'd only ever seen one form converting to the other should only take a few seconds of thought otherwise they're going to be confused by a lot more then just this. Seriously, don't you have something better to do then argue about this? Please give me the list of your text books. I do have better things to do THAN this, yes, however I'm arguing from the standpoint that if you guys actually knew the calculus behind this, you would realize that this "vector" form is ridiculous. What's even more ridiculous is that the denominator in the equation you list on wikipedia is a scalar gathered from a vector. Well, so is the standard version, so this "vector" version is no more "vector" than the standard version. Then this "vector" version also multiplies the force by the unit vector in order to arrive at the final acceleration vector. Well, so does the standard version. The only thing being done in this "vector" version is screwing up the meaning behind the equation. It's not just random arithmetic, it's based on the actual calculus of the potential's gradient based on distance. Weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee.... Massive Quote... Of coarse the denominator is a scalar, division isn't defined for vectors, it's a vector form because the result force that it calculates is a vector, you know, like the scalar version calculates a scalar force (the magnitude of the vector version). The 'standard' version to which you keep referring is, I assume (since you insist it has a r2), the scalar version which is of coarse a scalar, F = G m1 m2 / r2. Also, I only just noticed, but the version on wikipedia is actually wrong regardless, I didn't notice that they where multiplying by the unit vector rather then the actual vector which puts their equation out by a factor of 1/|r|. Really there is no point to this, both are valid, both are mathematically equivalent, both forms are commonly used and both make just as much sense. Quote:however I'm arguing from the standpoint that if you guys actually knew the calculus behind this How about we refrain from insulting each others intelligence? I do know the maths behind this and I'm surprised that anyone who does would bother to argue about it since both of the equations are fine. Right, except for where they make look like an inverse-cube law in order to skip a division operation... No one makes it look like anything in order to skip anything, taking out ht factor of 1/|r| is IMO a logical operation, it doesn't make it 'look like' anything, its still the same equation.