Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Mar 2009
Offline Last Active May 22 2013 08:43 AM

Posts I've Made

In Topic: All from scratch

12 December 2012 - 02:50 PM

I would be curious to do a poll at some point along the lines of:

Which do you think is harder:

-- filming a movie
-- coding a video game

I've been involved in both (programmer/actor though less acting than programming :) ) and that's a tough one lol.
Each of them are equally draining but in different ways, at least that is my opinion... kinda states the obvious haha

Me-thinks we're getting a bit side-tracked guys.


Hope this helps!

Ah yes, I apologize.
Ok so I'm pretty tired of dishing out the same old Your-Not-Going-To-Make-X. speech so lets try it a different way,
pick one of the languages below, try several before settling on one if you must.

In no particular order:
- C#
- Python
- Java
- C++

Then, in chosen language, try to implement what you think will be the single most easiest feature to program in your MMOx
If it were me I would probably start with menu system (no fancy GUI or anything, just the ability
to navigate a hierarchy of sub/menu's and have the perform different actions) simple enough.
Then move onto something a little harder, perhaps an inventory (depends on how you want your inventory system to work).
If you manage to achieve that, try to do something a little harder; a chat client! over the interwebs!
(atleast I think its harder, probably because I have never attempted it and have little idea as to what it involves).

Then keep going for as long as you can, the rest of us who were once in your exact position already know the ending to this
story, but at least this way you will gain a serious amount of valuable experience!

In Topic: pool allocator

26 September 2012 - 08:27 AM

I've read that allocators of the same type are required by the standard to be able to
deallocate the memory that another of its type has allocated.

No, memory allocated by a allocator A can be deallocated by allocator B only if A == B is true. If they aren't equal to each other, they're not required to be able to deallocate each other's allocated memory. See section 20.1.5 of the C++03 standard or of the C++11 standard.

I don't have the standard documentation available to me nor do I know where to get it. What you have said is essentially what I mean but the problem is that allocators of the same type are required to return true from A == B (or so I read somewhere) I am probably wrong, if so does this mean I can implement the comparison operators normally?

In Topic: Need help with Matrix decomposition algorithm...

25 September 2012 - 03:03 PM

Above post

I'm actually working on a small library of random items that include math related things such as vectors and matrices.
if you want id be willing to share code, or give feedback over skype or something though I don't have a mic. I don't yet have a
class for quaternions so I'd be interested to see your implementation.

In Topic: Need help with Matrix decomposition algorithm...

25 September 2012 - 02:36 PM

I was once in the same boat as you somewhat, I wanted an algorithm to do LU decomposition because I had heard that you can compute the inverse of a matrix with the decomposition though I never was able to find any information on exactly how to go about that. I did however write a working algorithm to do the decomposition and it should still be here on gamedev somewhere.. (I'll check my posts and then get back to you) though I was told it was lacking "pivoting" or something.. I'm no math genius I just learn enough to get by in programming (and possibly a little extra if it peaks my interest which is more often than not).

hold on let me find that post for you..

EDIT: Sorry, seems my old posts/topics have been deleted =/ .. blows.. well I'm not that great at math and it took me a good few hours to read about LU decomposition and how it is done, to come up with an algorithm. I'm sure if you keep at it you will come up with the algorithm as well it wasn't complex at all if I remember correctly just a few for loops.

It might be around somewhere, I used to go by CodeCriminal around here but have since changed my handle.

EDIT2: Woo found it http://www.gamedev.net/topic/562662-lu-decomposition-and-computing-the-determinant-of-an-nxn-matrixsolved/

In Topic: custom allocator adapter

25 September 2012 - 07:20 AM

EDIT: I just tried a few things out, and one of those things was to inherit from the allocators rebind member which at first spat out some errors during compilation. Then gcc suggested something interesting - 'use Allocator::template rebind to indicate that it is a template' - I have never come across anything like this before but it seems to have fixed the original problem I had with your change to the rebind member when I change it like so:

Yes, that construct is required by the language in that situation. Older versions of the Microsoft C+ compiler fail to comply with the language specification on that, I'm not sure about current versions. GCC has required it since 3.0 which was released a decade ago now.

Ah, good to know, I've only been working with gcc for just under a year now (not counting actual time spent programming) and I was a visual studio guy before that, so that's probably the reason why I had never come across it before. (couldn't resist those c++11 features that vc10 was lacking in Posted Image )

You're poking around with a part of C++ that has all the pointy bits at one end. Hang on, you're in for a fun ride.

Oh joy a challenge, I look forward to it haha.

BTW, the only place GCC should be using std::allocator_traits<tracking<int>> is in its test suite.

Well since changing the code in the rebind member that edd suggested, that problem has pretty much disappeared, I'm now faced with the getting it to work with std::list. The problem I am getting is that std::list<T, Alloc>::get_allocator( ) or some function there within is trying to call a "supposed" non-existent copy constructor. The errors go a little something like this:

error: no matching function for call to 'type::allocator<std::_List_node<int> >::allocator(const type::allocator<std::_List_node<int> >&)

It works with std::allocator but not my own implementation it seems.. (recently discovered)
After one quick look I noticed my constructors where declared explicit, for some reason this blows up in the containers.
Removed the explicit keyword and now everything is working again! .. until I find the next flaw that is.

Oh, and one more thing. The current C++ standard changes allocators around a lot. The old C++98 allocator model is being deprecated. It's a good riddance kind of thing.

Oh really? so am I using the old allocator model? If so where can I find information on constructing allocators that comform to the new standard?


[revised code] : http://codepad.org/9mrTYNT2