Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 18 Nov 2009
Offline Last Active Nov 05 2013 01:00 AM

#4860487 Is it better to use extern or pass in a pointer (C++)

Posted by thatguyfromthething on 11 September 2011 - 06:27 PM

Extern is almost always a bad idea and unnecessary, more so than goto.

But you probably don't want either one.

Your camera is nothing to do with the level, so your basic idea is skewed a bit.

What you probably need is some static method you call to get the current level, as this will come up over and over making games.

So you have Level::getCurrentLevel() or you might have a LevelManager class that has the info which seems to be popular way to do things.

#4827427 A Newbie, A Vision, No budget.

Posted by thatguyfromthething on 24 June 2011 - 07:32 PM

I think it's terrible advice to work with RPGmaker unless it can deliver the end result you want.

You should not waste any time learning anything that won't be used for your project. If you learn to make games that way, you will waste years and be no closer to making a real game.

If you want to make a fully 3D RPG then it's a lot of work and so is any RPG for that matter, but it's not really less work to make it in a 2D engine than 3D though probably doesn't require as much programming skills, and with 2D engine you probably need to program it yourself so you are making both a game and an engine.

No matter what your goals and budget are, just look for the tools you need first, in this case an engine. Then look what will be needed.

Realistically you can count on making an RPG in C++, though. You will probably fail utterly in any other method of development unless you have a very limited scope game. Most of the engines out there provide very poor support for any game but a shooter. The ability to make complicated data driven GUI just isn't there.

But this place is full of incredibly terrible advice. If you listen to most people here you will get nowhere, the issue is not just lack of knowledge but you need to realize that very few of them are making games like what you are making (if they are actually making games at all). I happen to have made a game similar to what you want, though not released yet the software is done for some time now, and it's just completely different needs compared to what most people have experience doing (console or cell phone games).

So say you want to say make a Fallout 1 clone then you get a bunch of people suggesting you use an engine like Unity that only really works with games that could be played on a cell phone easily not an old school RPG - graphics complexity hardly matters here, it's about how easy it is to work with data and create GUI that will make or break your project, not how easy it is to get art assets in (and honestly for any but simplest game this is just a nonissue - it it takes a month to import your assets (and no engine is that bad) then it's nothing compared to making a 5 year game, but a serious problem when making a one month game).

UDK has everything you need but they are not much better for GUI stuff than Unity, maybe worse. Plus the damned thing just isn't stable. If you had C++ support I'd say it's ok but that costs a lot of money

I ended up using my own engine, but it's probably not realistic to go from no programming experience to making your own engine to making your own game all in one go. Actually it's highly unrealistic to make a big RPG by yourself but it's not impossible to do so, it's just a lot of work.

So I'd try to find engine first (or maybe a couple engines you can try out) , get some C++ books, then get going. Yes you will make a lot of mistakes, especially as someone just learning to program, but you will start to see the issues of the problem at hand. If you start off making connect 4 or RPG maker you simply won't ever get started on your real project let alone complete it. This way at least you learn basics of how engines work, and even if you switch engines eventually the next time around you will be much smarter in selecting you tools because you know what to look for.

Eventually you will probably need some kind of team but a team is actually very easy to get together if you have anything to show. If you don't then there's no need for a team because they are a lot of work to communicate with and will just slow things down if you already have a task to do at hand. When you see how much work it is you will probably quit because it is years of work, but if you chip away at it long enough you will get done eventually, you just have to be patient and realize you won't be releasing anything new week, or next year, or maybe even 5 years from now.

#4802977 Game multithreading

Posted by thatguyfromthething on 26 April 2011 - 02:21 AM

Just because a game is 2D doesn't mean it can't use MT especially for things like AI.

There's two main uses for multithreading. One is to make things go more faster which is what many people tend to fixate on, but making for responsive asynchronous actions can be much more important.

For example if all your AI is done on a frame by frame basis it leads to lots of problems and can make for lots of wasted computing power. There's lots of stuff that just doesn't fit well with working frame to frame, and I'm convinced a lot of the reason so many games such so much is they are artificially shoehorned into this paradigm. Having to update something expensive every time you move the mouse can also kill responsiveness.

For making things faster, on the other hand, you generally want some kind of job queue. The big problem when it comes to speed is linear dependency, that is the fact some things depend on the result of other things before they can be calculated. That's the biggest reason it doesn't work out well to have lots of separate threads running, like a render thread or whatever. However if you design a job system well you can ensure that jobs are executed in proper order and that you pretty much never have completely wasted time where your main thread is just waiting on results.

You can use lots of libraries but when it comes to OpenMP I strongly recommend against it. The issue here is that the real difficulty in multithreaded programming is in breaking tasks up into a form that can be multithreaded. If you can do that multithreading is generally easy anyway. If you can't and if you don't understand the basics then you are going to get all the bad and none of the good. Since most of it is based on waiting and sometimes creates new threads, and due to the dumb comments the guy at intel makes, I'd say it's just a completely incompetent implementation of MT to be honest.

#4802189 Picking question

Posted by thatguyfromthething on 24 April 2011 - 01:16 AM

The origin and endpoint are the start and end of the rays that are cast against the triangles.

The basic process of the most brute force approach is you go through every triangle and see if there is a collision.

Even then it is a PITA because you have a possibility to detect a collision from the wrong direction. However, you can test against the winding order to discard selections (I forget exactly how).

The other thing you can do is only accept the closest hit. Just go through them all.

This is slow compared to something fancy like a BSP or octree (I think there is some octree collision in that lib as well but it looked complicated so I just used brute force), but for something done in user interface, it ultimately doesn't matter. For like rendering you will never get away with brute force but if it's mouse picking or something it's not a big deal.

#4802122 Picking question

Posted by thatguyfromthething on 23 April 2011 - 06:53 PM

Will you or anyone ever write a collision detection against a mesh that works on first try? Probably not, but this one seems to be missing some steps at a glance. Here is some code to look at:

	bool IntersectUtil::segmentTriangle(const Point3& origin, const Point3& end, const Point3& vert1, const Point3& vert2, const Point3& vert3, Point3& intersectionPoint)
		bool intersectsPlane = linePlane(origin, end, vert1, vert2, vert3, intersectionPoint);

			return false;

		float segmentLength = distanceSquared(origin, end);
		float intersectDistance = distanceSquared(origin, intersectionPoint)+EPSILON;

			return false;
		return GeomUtil::pointInTriangle(intersectionPoint, vert1, vert2, vert3);

	bool IntersectUtil::linePlane(const Point3& origin, const Point3& end, const Point3& vert1, const Point3& vert2, const Point3& vert3, Point3& intersectionPoint)
		Point3 ray = GeomUtil::normalize(end-origin);
		Point3 edge1 = vert2-vert1;
		Point3 edge2 = vert3-vert1;
		Point3 normal = GeomUtil::cross(edge1, edge2);

		float dp = GeomUtil::dot(ray, normal);

		Point3 toVert1 = origin-vert1;
		float det1 = -GeomUtil::dot(normal, toVert1);
		float det2 = GeomUtil::dot(normal, ray);
		float r = det1/det2;
			return false;

		intersectionPoint = origin+ray*r;

		return true;

	bool GeomUtil::pointInTriangle(const Point3& p, const Point3& vert1, const Point3& vert2, const Point3& vert3)
		if(sameSideLine(p, vert2, vert1, vert3)&&sameSideLine(p, vert3, vert1, vert2)&&sameSideLine(p, vert1, vert2, vert3))
			return true;
		return false;

I was going to copypast all the stuff you need but it turns out I'd have to post a ton of crap I didn't realize. Anyway I found this a while back while trying to do the same thing you are and it's not too advanced ot anything but seems to work ok for basic collision and computational geometry problems.


#4801564 Reverse mouse picking

Posted by thatguyfromthething on 22 April 2011 - 04:27 AM

I'm making a 3D game with an overhead freeranging camera. I have a method to mouse pick that works correctly, creating a ray for the mouse point then projecting it til it collides with something. I know it works properly because any markers I create show up at the right places.

Several times I've tried to go the other direction, though, and always had problems. Using the rays and camera focus and all that crap is very error prone. I don't even know for sure all of it works correctly in the engine. Most likely it does but there's a chance I am using something wrong or whatever. At any rate, i've given up on the recommended method it just doesn't seem to work.

Instead I want to just compute it using geometry. However, that seems to be failing too, but hopefully it's failing in a way that someone else can point out.

So using that method to project into the game world, I am projecting out from each of the corner mouse positions into the plane where z = 0. That is projecting from 3D perspective to a 2D plane.

From there I take the x and y axes, and call a method to find the closest point on each axis to the reverse pick point. Then I find the distance from the origin and use this to calculate the mouse cursor location for that point. Seems like it should work, but somehow it fails. Does this approach have something wrong with it? If not I guess there can be a bug somewhere else. Now the dummy case should be to project the cursor out to the plane, then project it back but it always fails and I can't see what's wrong. In practice there's a reason for doing this that can't be ignored, though, that's just the test case.

If I print out everything it seems if I project every mouse point to the plane the distances between them are regular and describe lines as I'd expect them to. So it seems like my method should be workable but it completely fails. I know the plane can be skewed but (or so I think) it should not matter.

Here is the code. Maybe something obvious is there? Been screwing with this 14 hours today so at this point a fresh pair of eyes would be helpful.

//first, I have this method which I know works
Point3 CollisionUtil::projectCursorPointToGround(Point screenPoint)

//this method fails
Point CollisionUtil::screenPointForWorldPoint(Point3 worldPoint)
	Point cursorPoint;

	float screenWidth = getDisplayWidth();
	float screenHeight = getDisplayHeight();

	Point3 last = projectCursorPointToGround(Point(0, 0));

	Point3 ul = projectCursorPointToGround(Point(0, 0));
	Point3 ur = projectCursorPointToGround(Point(screenWidth, 0));
	Point3 ll = projectCursorPointToGround(Point(0, screenHeight));
	Point3 lr = projectCursorPointToGround(Point(screenWidth, screenHeight));

	Point3 xAxis = ur-ul;
	Point3 yAxis = ll-ul;

	Point3 pointOnXAxis = closestPointOnLine(worldPoint, ul, ur);
	Point3 pointOnYAxis = closestPointOnLine(worldPoint, ul, ll);

	Point3 xProjection = pointOnXAxis-ul;
	Point3 yProjection = pointOnYAxis-ul;

	float xAxisMagnitude = magnitude(xAxis);
	float yAxisMagnitude = magnitude(yAxis);

	float xRatio = screenWidth/xAxisMagnitude;
	float yRatio = screenHeight/yAxisMagnitude;

	float xMagnitude = magnitude(xProjection);
	float yMagnitude = magnitude(yProjection);

	long pointX = round(xMagnitude*xRatio);
	long pointY = round(yMagnitude*yRatio);


	return cursorPoint;

#4800673 POD detection in C++?

Posted by thatguyfromthething on 20 April 2011 - 01:01 AM

I have a resizable array class...and please don't give usual annoying comments of "use STL!".

Sure, but consider that if you're going to reinvent exactly what the standard library is doing but you've run into a problem that the standard library has already solved, you could at least consider looking to see how the experts solved it.

What the standard re-sizable array class (std::vector) does is preallocate a whole lot of contiguous space and then, when the time comes, uses std::uninitialized_copy(), std::uninitialied_fill(), or std::uninitialized_fill_n() to perform the appropriate construction operations in place. Usually, those standard functions are specialized for PODs. I'm not suggesting that you use the standard library, I'm only suggesting that you could examine its implementation to see how they solved the same problems you experience.

I know all about stl and how it handles this and have read source code closely. It's much slower and crappier and much more of a mess than anything I would ever use to be frank, even without this optimization. It's not a bad response to a beginning C++ student but when all you get is spam saying stl is great or check out some stupid boost feature instead of answering the actual question it keeps real answers from coming along (if any are coming, or are even possible which seems like shot in the dark in this case).

Can't the compiler optimize away the placement new for POD type?

And if POD is the issue, use some simple traits to deal them specially.

Apparently not, oddly. But this might be due to lock issue, simply calling it at all might be calling the slowdown (didn't write the memory manager I am using).

Like I said I don't want to add 23 special cases. I want to keep things simple, especially in the most critical part of the template, with the most commonly used template in my library.

Someone said something about what's the difference between that and vector. The difference (like I already said) is when you set size on array then any member can be accessed and is considered initialized, so you can't really delay initialization. Array works out better for a POD. I don't want to split off into a POD array and a nonPOD array, but maybe that is the best I can manage.

#4796212 Any recommendations for a game engine?

Posted by thatguyfromthething on 08 April 2011 - 10:30 PM

First, drew you seem like a cool guy. I didn't mean to argue or convince you of anything, I was just throwing in my two cents. Please skip following rant.

And sure you can share code...via cut and paste or copying a whole file into another project.

How is that not sharing code? If you write a class for project A, and then re-use it in project B, isn't that sharing code?

Just as an example, what about heavily templated libraries in C++? Generally, you re-use that code by referencing the same file from multiple projects. How is that any different?

In any case, although I haven't done it myself, I believe you can use your own assemblies in Unity (although maybe not in the browser version). If that is in fact the case, then it completely negates your point (whatever it is).

And back to .net, you can't use all the GUI code in the API you have to rely on the simple tools provided or make your own based on them, which drastically limits your ability to separate your code from the engine.

Ok, earlier you said you couldn't use .NET. So are you now at least acknowledging that you can use .NET?

And what GUI API are you talking about? Are you talking about something from .NET, like Windows.Forms or something? What is it that you can't use exactly?

Unity has a built-in GUI system, but I probably wouldn't use it for production code. There are some good third-party solutions though, and you can roll your own just like you would with any other engine. I really don't understand what you're getting at about the GUI stuff though. If you mean something from .NET, then what game engine allows you to use GUI-related features of .NET in a scripting environment? Can you clarify?

And that's it in a nutshell, everything is tightly mashed in to an ubertool you have little control over.

This is the closest you've come to a valid point :) When you use a development tool like Unity, you do trade some control for ease of use, and that's something you have to weigh when deciding what tool to use. However, based on everything you've said, I think the 'giving up of control' that you're talking about is very different from the reality of it.

Complicated gameplay and GUI? no.

Again, you're 100% incorrect. Unity imposes absolutely no limitations on the complexity of the gameplay or the UI. Why do you think it does?

but it's a different story to make cell phone games and make something like a flight simulator or old school RPG. For unity that is virtually if not entirely impossible.

Where are you getting these ideas? There's absolutely nothing about Unity that would make it impossible to make an RPG or a flight simulator. Why do you think these things can't be done?

I apologize for being contrary; it's easy to fall into this trap on occasion when participating in forums such as this one :) But, it is a little frustrating when people post misinformation persistently. A lot of people read these forums, and some may not have the background or context to separate the good information from the misinformation. So, I do think it's important to counter misinformation where possible.

To be honest, it really sounds to me like you don't understand how Unity works. Like I said earlier, it's not for everyone (no tool is), but if you don't have a good grasp of it yourself, I'd at least refrain from discouraging others from using it.

Look is there some reason you are so defensive?

Remember, you are the one who came out and said I don't know what I'm talking about. I do know. I know a lot more about programming than all but a few people and if your life doesn't include a decades long programming training montague they you are NOT one of them. Yet I've had gamedev staff come into my threads and argue with me and even try to correct me like a schoolchild then get proven wrong flat out. Then still argue with me, like if you failed english 101 (and have this pointed out by quoting basic grammar texts) and then you keep arguing about obscure middle english texts with a visiting librarian from abroad who just spent a week studying the exact texts in question.

I would never normally posture to the extent of that last paragraph about my vaunted experience and knowledge but it's simple reality. If a guy just wrote a fricken memory manager he probably knows more about the subject than some guy who doesn't even know that malloc allocations are all 16 byte aligned (and in fact can't even be a C programmer at all to not know that, so should not even be saying anything at all on the matter).

And it's not like I made some uberrant against Unity. As I said, I feel that C++ is a better way to develop games in the long run. There's more learning curve but you have fewer limitations such as the ones you mentioned. I also said already it was not even intended to single out unity.

Now, your comment about sharing code tells me you are not much of a C++ programmer, and some of the other comments say you really don't know that much about unity even (a subject I am not expert in but which apparently more an expert than you, its defender). You have no business arguing with me to be honest, you just have no idea what you're talking about and you're just making noise for the hell of it. Of course you can have two separate files with the same thing in it. What would be nice is to be able to include another project in your project as a basis for the current one, especially when forced to use their stupid asset server. Or wait maybe you don't have pro version because obviously you don't even know what I'm talking about or why it's such a pain in the ass, and if not then you should doubly not try to drag me into an argument and waste my time.

Now are my comments arguable? Well of course like I said you can argue OOP and other abstract concepts pretty much endlessly with no resolution, but to come out and make the dumb comments you have about something you have very little grasp of is simply a waste of everyone's time.

#4796156 Any recommendations for a game engine?

Posted by thatguyfromthething on 08 April 2011 - 06:17 PM

So if I write a few programs that are OO then call them externally through another program, is that an object oriented program? If a unix command is made in an object oriented manner and I call that through bash is my bash script object oriented. Well I don't really want to argue about what OO means, which seems to be the issue. But I hold to what I said. It takes more than data structures to make OOP.

And sure you can share code...via cut and paste or copying a whole file into another project. Maybe this has changed, but on the other hand maybe you didn't go far enough to bump into that limitation yet.

And back to .net, you can't use all the GUI code in the API you have to rely on the simple tools provided or make your own based on them, which drastically limits your ability to separate your code from the engine. And that's it in a nutshell, everything is tightly mashed in to an ubertool you have little control over.

And yes I know all about the projects using unity. Good 3D display? Sure. Complicated gameplay and GUI? no. Of course you can say that of most any engine since everything is consolized and cellphonized these days and the leading engine unreal also has some pretty crappy GUI support, but I think it offers a particularly poor development environment for a complex project.

I don't mean to insult the cell phone makers of the world but it's a different story to make cell phone games and make something like a flight simulator or old school RPG. For unity that is virtually if not entirely impossible.

And this is not to just single out Unity, lots of engines have the same failings, possibly by design to make it harder to migrate to other products. The comment was more about C++ than unity, though.

#4795814 Any recommendations for a game engine?

Posted by thatguyfromthething on 07 April 2011 - 10:03 PM

In the long run you'll be happier with C++, and especially glad you ditched unity, even if it is harder to get started in.

Unity has their own and if I'm not mistaken Vision has their own.

Unity supports three languages (not counting C++ plugins for the pro version). One of the languages, UnityScript (aka Unity JavaScript) is specific to Unity, but the other two, C# and Boo are not (and C# at least is of course widely used).

But the support is of a nature that seriously limits you. The manner you do things is always in scripts, so it completely negates the OO features of C# and you don't get to use the actually useful parts of it like the GUI API so it's completely meaningless.

#4687676 C++ object memory management, reference count or raw or mix?

Posted by thatguyfromthething on 05 August 2010 - 05:36 PM

Original post by ChaosEngine
In C++, prefer RAII for managing any resource. Seriously, literally millions of man hours of experience have confirmed this as best practice in C++.

Use the stack if you can.
If you must use the heap, try to have clear ownership semantices (i.e. use scoped_ptr for single instances or boost.ptr_* for collections).
If ownership must be shared, use a shared_ptr.

Do not use a manual reference count, you will get it wrong. That's not a slight on you. Everyone, eventually gets it wrong.

The point here is why do you want to manage this manually? Unless you have a very good reason, you are simply making more work for yourself than necessary. Every minute you spend managing memory is a minute that could be spent making your game/app better.

RAII is just one of those meaningless things people say. If someone says manual you can be pretty sure that's a given. No one's really making objects that have some other object delete its members or anything like that. The issue here is not how the object/node cleans itself up, which however you do it is not usually in doubt about success except apparently to Bjarne Stroustroup. It's when you have an amorphous situation like a scene graph of graphics objects, how do you keep track of the damned things?

The possibilities are endless, and most of them have some degree of agony to bestow upon the end user. So once something not attached to some other node it disappears? Then we get stuff deleting itself behind our back, and stuff we still want to use has to be temporarily stuck to something for no apparent reason at all times. Is it all in some big container that tracks things and autodeletes? Then we close the app and deletion code that's already unloaded gets called. Do I have a smart pointer and some weak references? Well, that will fragment your heap to the moon and anyone but you using it will probably go through their days in constant doubt about what's going on.

#4597937 Best Game Engine for Indie Game?

Posted by thatguyfromthething on 02 February 2010 - 10:06 PM

For free noncommercial stuff, the unreal thing is the best bet but seems a bit complicated for hobby use. Even 2.5 has been free for some time for noncommercial stuff. Leadworks is good for hobby stuff. Good price, pretty good tools and some nice features.

For moderate money C4 is far and away the best thing out there. Unity has merit but also issues, and costs a lot for the version that has things like shadows, neoaxis is kinda unproven and a bit meh and torque3d is a complete joke that has lost any credibility with its customers (ie me) with their constant and ever more grandiose lies and hyperbole which have less followthrough than your average open source project.