kd7tck

What saved openGL ultimately was that directx only runs on microsoft devices. Mac/Unix/Linux/Android/PS3.... All use OpenGL.

All good... you know, part form the fact that Android uses OpenGL|ES (aka OpenGL's saner relation) and the PS3 doesn't use GL at all.
(An OGL|ES layer exists for the PS3 but no one in their right mind uses it...).

Directx only became king because microsoft partnered with game companies and funded hundreds of game titles in the late nineties. They flooded the markets with windows only games and this set the standard from that point onward.

OpenGL was still the renderer of choice in the late 90s and very early 2000s; I was still playing Counter Strike on the source engine using OpenGL as late as 2001, UT's OpenGL renderer was better than the D3D one of the time and iD was still pushing OpenGL solutions. D3D9 came out, stopped doing dumb things and the ARB utterly failed to bring matching functionality for some time (look up the history of the VBO and FBO extensions for example of features which massively lagged D3D due to IHV infighting) and have managed to stumble time and time again (OpenGL2 & OpenGL3 being the big ones, the last being the one which finally made me go 'screw this noise..' and swap to using D3D).

The source engine didn't come out until 2003 when it was stolen by hackers, I have no idea where you got 2001. Valve and ID have always been open source friendly, some of their early games where openGL because they wanted to port them some day. Just because early directx was garbage doesn't mean it wasn't heavily used. As I recal most OpenGL games made back then where also D3D, if need be. The few years where the infighting did hold it back is over with now. It only lasted a couple years and I feel the vendors learned allot from it.

OpenGL will always be around regardless of it's slight ineriority to Directx, all becuse it runs on almost everything. Yes I an OpenGL fan admit directx is slightly better, ...just slightly.

By the way I love OpenGL|ES, I always assumed it was openGL. My bad on that.

especially if it's build solely by one company and their marketing department.
... snip ...
Standards are the way to keep your freedom of choosing what and how you want to develop.

The first part of your post wasn't bad, but that one line was idiotic and trollish.

The second line is equally silly.  You do realize that C# is ratified as a ECMA standard language right?  By your logic people *SHOULD* use C# for exactly this reason.

When it comes to graphics libraries, it was actually being an open standard that caused OpenGL to stumble and DirectX to become king.  D3D pre-9 were basically shit, and D3D9 took a number of revisions to get to the point of being better than OpenGL.  However, they could move quickly and did, while OpenGL died a slow death by committee.  The move to a programmable pipeline is the only thing that saved GL in the end.

What saved openGL ultimately was that directx only runs on microsoft devices. Mac/Unix/Linux/Android/PS3.... All use OpenGL.

Directx only became king because microsoft partnered with game companies and funded hundreds of game titles in the late nineties. They flooded the markets with windows only games and this set the standard from that point onward.

The easiest way is to doubly link everything, this is easier because it will require the least modification to your program. To implement, make sure every object that has a vector is also part of a vector collection in each of the child objects. This must be made a constant for every vector, if you choose to do it this way. Later when the deconstructor of an object is called, it will contact each and every child object in it's vector and remove itself from their vectors.

Otherwise you can use modified smart pointers, that take into account all vector copies.

This is a tough one, I researched this one all last night.

First I would recommend google checkout as the checkout and payment system.
Next use google App Engine and construct a relay server, one that will tie the orders from google checkout with an unchangeable destination server.
Ensure that if the destination server is changed, then no further orders will be processed.
Finally for the destination server side. For this you would just generate the keys and forward them to the correct gmail account.

Google has most of this infastructure in place for companies, which you can leverage yourself.

I have never used pygame before, but in SDL I would simply rotate the world textures. I'm not certain how much SDL and pygame have in common so don't take me literally.

NOTE: Make sure to keep all textures seperate, poll all non player textures and rotate each one around a common axis.

From my experience, a thorough understanding of Calculus goes a long way to simplify most other subjects, especially physics. It's probably easier to work with than Algebra.

Calculus uses algebra, so how can it be easier.

I would recomend a discrete aproach to physics and drawing calculations. Since most online math tutorials are all geard toward the continuous aspect, you may have a very hard time bridging these two worlds. What you need to do is spend 2 years mastering the clasical continuous approach to calculus, then branch over into discrete math and start translating what you had learned into the way computers process data.

The way you solve an integration problem is not how a computer will do it, keep that in mind.

The sources seem to at least have some code for running on Linux. Maybe it already works. Have you tried compiling it?

The code you speak of is for the compiled game itself, not the torque3d ide.

http://www.greensock.com/

Just so you know, Source engine has been used many times in the past to make 2d/2.5d games.

I know many of the people who write patches to allegro on an ongoing basis, Allegro and C are anything but outdated.
Allegro is actually a highlevel SDL wrapper, and there is a c++ wrapper written for it.

Don't cringe at wrapping C code into a c++ game. Often this is the fastest way to get things done.

Decrease the size of bally, to like 10. Also move the "sGreenBall.Move" line above the "rGreenBall.Top = sGreenBall.GetPosition().y;" line.

Are you first compiling to assembly from C?



The reason I ask is because

static const unsigned short CoefficientsRGBU[256][4] = {

is not assembly.


This is only a hunch I got, so stay with me here.
Convert the following code in C with -S first.

static const unsigned short CoefficientsRGBU[256][4] = {
{0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0},...
{14465, 62734, 0, 0}, {14465, 62734, 0, 0}, {14465, 62734, 0, 0}, {14465, 62734, 0, 0}};

Then modify the output, add the following to the end.

movq mm0, [ (_CoefficientsRGBU_ + offset) + 8 * eax ]

If I am totally off base with this hunch then please post back with more info.

Did you update the include path?
Otherwise If you did, then move it to the front of PATH and see if it was a collision.

If I were in your shoes I would make a scripts folder, then load every script in the folder during runtime and put through luaL_dofile.  This way the end user could add any number of extensions or addons as they wish. Create a special C++/Lua api, where you register certain C functions inside lua. These functions when called will act as hooks to common game tasks/functions. These scripts will allow any number of modifications to the game runtime. Once all scripts have been run execute the game with all changes in effect. The scripts should be made optional and not required to run a basic game. For example an optional script could add another level, or new kinds of weapons.

Don't be scared to show us all your code.

Look at this post http://www.gamedev.net/topic/630029-data-driven-renderer/ .

This is a lot of work, why are you doing this?

GameObject->RendererComponent->RenderCommand->Material->(textures, matrices etc...)?

Model your system after the collada file format,  this will make it easier for you to import data later.