Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 May 2011
Offline Last Active Nov 17 2013 02:57 PM

#5079486 API Wars horror - Will it matter?

Posted by on 21 July 2013 - 10:24 PM

Also if a game company wants to use some obscure new DX function they can call up somebody at Microsoft and have a programmer leased to them until the issue is solved. I'm sorry, but this world exists only in your mind. A lot of us are annoyed because DX support from Microsoft is the worst it's been in literally decades.


Really. This only exists in my mind.... If UbiSoft offers to pay Microsoft for one of their DirectX consulting programmers, you don't think that this will happen?


As for the rest of the insulting things you said to me, I'll respond with the following.  Promit, you're an idiot.  People like you are the reason sites like this have such bad reputations for being overpopulated with arrogant, condescending, know-it-all, half-wits.  You're one of the big-fish in this department.

#5079467 API Wars horror - Will it matter?

Posted by on 21 July 2013 - 09:10 PM

Microsoft likes to use DirectX to launch the newest OS they have for sale.  Microsoft has almost unlimited resources and lines of credit.  They can dump a billion dollars a year into the newest version of DirectX if they want to. 


Also if a game company wants to use some obscure new DX function they can call up somebody at Microsoft and have a programmer leased to them until the issue is solved. 


If the drivers for a major hardware company is having problems with a new DirectX API, You can be sure Microsoft will throw money at the problem to make it go away. 

OpenGL doesn't have this vastly wealthy champion to ride in and fix problems in a timely fashion.


If DX didn't run at least a little bit faster, then I'd have to ask, "where is all that money going?"  Of course newer features are often faster and more consistent across GPU's.


Personally, I'm not going to help MS black-ball people into buying a new OS. 


If you choose one or the other, I'd say you should choose which ever one feels most natural for you, I modify this point with a few more as follows.


I started with OpenGL because it made sense to me sooner than DX did. 


Now I also consider cross-platform issues.


I also now consider this to be an ethical issue as well. 


I do not like how Microsoft does business and I am not going to help them any more than I have to. This is no different then the idea of voting with your wallet.  If you do not like how they do business then don't support them any more than you have to.  If money is all you think about, then team up with MS and you'll likely be very happy as well.


If you feel that DX is the better API then use it, otherwise don't, or learn both. 


There is no "war", this is drama and rhetoric for people who are upset at having to learn more than one thing, sort of like-> "Use what I prefer or you're a stupid-head!"

#5079464 When to load the Final Boss in a Game

Posted by on 21 July 2013 - 08:44 PM

A person should not become so caught up in optimization that they never get anything done because they are continuously caught up in squeezing out yet another 1% performance improvement.  But to say that optimization should not even be considered is very questionable.  It should not hold a person back but it also should never be completely gone from a person thinking when they are building something.


To say that a person should not optimize is to say that a person should not use VBO's or whatever the DirectX equivalent is.  This is also like saying that a person should use an uncompressed format like .bmp.   Also it is like saying that a person should not consider sending indices to the GPU.  It is also like saying that a person should not work on keeping their model's poly count low.   "Who cares about optimization?...  let's build dozen's of models with 10,000,000 triangles each into our game!"


If a person ignores these things then their project space will be the size of a blu-ray disk for just one level and the game will likely run at only one or two frames per second on even the fastest machines. 


Paying attention to optimization is fundamental.  It is like anything else.  If you do not consider it and learn it, and put it into practice then you will never understand it or be able to implement it.  You cannot get good at something by ignoring it. 


Having to re-build the entire infrastructure of a software package after it's been built up for years to accommodate future optimization that was never considered before is a real possibility if this fundamental idea is neglected.


To be honest, I don't care what other people do in this regard.  If I some day install some bloated, inefficient software that doesn't run on my machine, I'm just going to erase it and I won't think twice about it.  When people ask me about the software I'll tell them it sucks and it wasn't written properly, you have to buy a $4000.00 dollar machine to run it. 


Unless that software is a killer-app, very few people will respond differently.


I don't view people around here as my competition, I like to communicate with like minded people and I also like to help people, I don't view this any differently then when I wash dishes or clean tables at the local homeless soup kitchen.  I'm not going to argue with anyone about this, there would be no point.  Nobody is bound by law to pay attention to optimization but it is a guaranteed fact that you will be making everyone else who does pay attention to optimization look a whole lot better in contrast to you. 


It's your name that's going on the product, it yours to do with as you please.  How do you want people to view your name?



P.S.  Try this experiment, make up a super amazing resume that no game company could possibly ignore but start it off with the following.


Now send it off to a bunch of companies and see if it receives any replies. 

#5079235 When to load the Final Boss in a Game

Posted by on 20 July 2013 - 07:34 PM

The first rule of optimisation is don't do it.


I have to say something about this and I have been thinking of the response for several days now.  Before posting anything!  I have weighed the merit of not saying anything and I have consider the issue of starting an argument vs. just leaving things well enough alone.


I do not take insulting people lightly.  This being said....


If you consider yourself to be an honest person then you should also consider posting the following notice on all software that which you plan to distribute in the future.

The notice should read as follows. 


"This software will probably not work on your computer.  Buyer beware!"


The same could be said of anyone who only tests their software on their favorite brand of hardware.

#5078034 Extremely frustrated trying to find the right engine/language/api/whatever

Posted by on 15 July 2013 - 09:38 PM

Well... commercial games do tend to have very long credit lists, kind of like movies.  There are usually way more than only two people involved in making them.


Some of the more impressive games I've seen took 4 years to build, and once again, it takes large teams of people this long.


Maybe some of the stress you feel is from having an unrealistic expectation of yourself.

#5077784 When to load the Final Boss in a Game

Posted by on 14 July 2013 - 11:53 PM

I don't see why you would load something that is not going to be used until 20 hours later.  That would be a whole heck of a lot of stuff. 


Loading every model and texture for every single level at the same time is excessive and you'd be asking for trouble.  Running collision response for every single object from beginning to end could also really bog down the machine.  Same with physics. 


Why not load a model within a few minutes of it's first appearance? Now it's not a burden on the system until it's ready to be used.


Loading a model and its textures will not likely cause anything more than a slight hick-up if you've been cleaning up everything that is no longer being used.

#5077640 What is the programming tricks of 2D endless sidescroller game?

Posted by on 14 July 2013 - 12:24 PM

Most side-scrollers, A.K.A.'platformers' use repeatable objects that show up everywhere such as a stone block that is repeated along the ground to form the base plane which the character moves along. 

You don't want to continuously delete and reload these objects.  You want to prevent them from being drawn when they are out of view.


The 'chunks' method is good for preventing a distance check on every object which would require a lot of CPU time. 


To implement this, you only need to supply the player position to an if() statement that encompass the draw calls for every chunk. 


Here's the code that said you don't want, for each chuck you would have something like this



if (playerPosition >= -10.0 && playerPosition <= 10.0) 


  #include "levelChunks/chunk_5.c"  //as best as you can, put everything for drawing and collision here.




That chunk will only be processed when the character is between -10.0 and 10.0.  Aside from this it will be ignored. 


If the level is 5000 chunks wide, then all of these if() statements will now start to add up in CPU time, in this case you'd want to test for chunks of chunks.


You can also scale the 10.0 and -10.0 values if you want to zoom in and out.

#5077087 Index Buffer help

Posted by on 12 July 2013 - 08:10 AM

The object viewer on the following page can handle indices properly. You can easily access them and print them to an array.



#5076575 Any good resources on creating isometric tilesets?

Posted by on 10 July 2013 - 04:36 AM

Not to mention taking a 2D tile and rotating it, the pixels will not be as crisp because the texture's pixels will fall between the monitor's pixels, and it'll have to calculate and guess at the right colors, mixing and slightly blurring them (as also noticed in the second image).


It's very obvious now that you pointed this out, thanks.  I'll be more careful with theory vs. what I have experience with.

#5076531 Properly implemented loader objects?

Posted by on 10 July 2013 - 12:08 AM

I should have been more clear, I was not chastising you and I was not saying that you have done something wrong, I was simply pointing out a tool that I thought would help you.


Even though the translator is a bit broken, here it is anyways.


должны были быть более ясным, я не порицая вы, и я не говорю, что вы сделали что-то не так, я просто указываю на инструмент, который я думал, поможет вам.

#5076354 Properly implemented loader objects?

Posted by on 09 July 2013 - 08:53 AM

Deleted, apparently it was not appreciated.

#5076089 FMOD API

Posted by on 08 July 2013 - 04:32 AM

Are you using the official FMOD SDK?  The Windows version contains .c and .cpp files for both C and C++ respectively which are both in the same folder for all the individual project files.  In the SDK version that I have there is only C code in the .c file and the headers included both have .h extensions. 

In the .cpp file both of the headers have .hpp extensions.


I double checked just now to confirm this, for me there is no mixing and matching between either formats.  It's either C or C++, not both. 


Incidentally, if you are using MingW/GCC you will have to use the C code.  The library has a bug that causes what appear to be linker errors if you try to build the C++ version using the aforementioned compiler.  That'll really drive you batty since the errors are completely unrelated to the problem.

#5075809 What if I have more models per level than available VBO memory?

Posted by on 06 July 2013 - 05:10 PM

It sounds like you might want to implement a distance check to delete and create VBO's and texture data as the you move around the scene.  If a model will soon be visible, then run an initialization function for that model.  If it's not going to be visible anymore then delete it.  You might have some hick-ups when you move from one area to another.

I certainly would not want to do this every frame for every component.


So far as reusing VBO's that have already been created, I'm not sure this would offer you any benefit.  The VBO that is being reused would have to be resized and rewritten, it seems to me that just creating a new one would be the way to go.   I don't imagine that reformatting an existing VBO would offer any performance advantage over simply creating one, it seems like you'd have the same overhead either way.   Then again, I've never tried this, maybe it would. 

#5075423 low-budget ways of testing performance ?

Posted by on 05 July 2013 - 04:38 AM

If you post something that is more or less a "release" package, then there are many people around here that will be happy to performance test it on whatever they happen to have lying around.


I can test it on two machines that I keep around for just such occasions. 

One is an Intel GPU that only has generic Mobile Intel® 4 series Express Chipset drivers installed, it handles shader model 2.0 code for sure and claims to support at least some 3.0 stuff, although I have not bothered to test this. The other has a mostly burned out Radeon Mobile x1150.  Both are whimpy dual cores that are running Windows 7 on only 2 gigs of RAM.  If your code runs on both of these machines than you should not have too many surprises. 


I don't use DirectX or XNA so these two computers will be ideal for testing for any missing dependencies that people may have, I can let you know about every issue I encounter from start to finish, so far as error messages go. 


I won't snoop through it and I'll delete it all when the testing is done.  I always do this when I'm finished working with other people's intellectual property.

#5075184 Yet another Deferred Shading / Anti-aliasing discussion...

Posted by on 03 July 2013 - 09:28 PM

There is a document that deals with that issue of jaggedly lines for fences and power cables and such.  


Anti-aliasing alone can't help you since the lines off in the distance end up being much less than one pixel.    Look for the section titled "Phone-wire Anti-Aliasing"