Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Mar 2005
Online Last Active Today, 11:21 PM

#5293861 Toggling buttons on a toolstrip

Posted by frob on Yesterday, 02:41 PM

Under the hood they are secretly check boxes.  The status of the checkbox indicates if the image should be popped in or popped out, or grayed out.


Selected generally refers to the cursor. 

#5293848 Iam new and I don't know where to begin

Posted by frob on Yesterday, 01:10 PM

> 1 - What programming language to start with? (iam already good in C# programming) 


Then use C#.  The language choice doesn't particularly matter, you can use whatever language you want that your tools support.


> 2 - What engine to use and according to what ? (I already started using Unity3d and it's good for me but i need some advices)


Unity uses C# and is free. It is also a frequent recommendation.  


Unreal also has some support for C#, as does Hero Engine and Allegro, to name three.


> 3 - i need some recourses to get free assets 


There are people and groups who post free asset packs online of varying quality. Generally if you want specialized work for your game you need to pay someone for it.


> 4- How to be good at programming and devoloping games?


By both study and practice. Study and learn the things you don't know. Practice and actually attempt to implement the things you want to implement.

#5293702 Do you usually prefix your classes with the letter 'C' or something e...

Posted by frob on 26 May 2016 - 07:22 PM

Many people also forget what real Hungarian notation originally looked like.  Microsoft re-published the 1970's work with some minor tweak about 16 years ago on MSDN.


It stems from an era of short names, 2-letter and 3-letter names were common. Recall also from the 1970s and 1980s that 6 to 8 characters were the limit of name lengths for many compilers.  Rather than using longer descriptive names, the notation was to keep the incomprehensible short names and prefix them with symbols. 


I'm just going to copy the example directly so you can see what they called a "real world" example:

1   #include "sy.h"
2   extern int *rgwDic;
3   extern int bsyMac;
4   struct SY *PsySz(char sz[])
6      {
7      char *pch;
8      int cch;
9      struct SY *psy, *PsyCreate();
10      int *pbsy;
11      int cwSz;
12      unsigned wHash=0;
13      pch=sz;
14      while (*pch!=0
15         wHash=(wHash<>11+*pch++;
16      cch=pch-sz;
17      pbsy=&rgbsyHash[(wHash&077777)%cwHash];
18      for (; *pbsy!=0; pbsy = &psy->bsyNext)
19         {
20         char *szSy;
21         szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz;
22         pch=sz;
23         while (*pch==*szSy++)
24            {
25            if (*pch++==0)
26               return (psy);
27            }
28         }
29      cwSz=0;
30      if (cch>=2)
31         cwSz=(cch-2/sizeof(int)+1;
32      *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
33      Zero((int *)psy,cwSY);
34      bltbyte(sz, psy->sz, cch+1);
35      return(psy);
36      } 

Perfectly legible code.  :-)


Programming has come a long way since he developed that pattern around his doctoral work in 1977 and introduced it as standard as the chief architect at Microsoft in the early 1980s.

#5293674 Are Third Party Game Engines the Future

Posted by frob on 26 May 2016 - 03:25 PM

My point is that I believe in time AAA studios will sacrifice having this amount of control in favor of the better tools and workflow that third party engines will provide.

Yes, "third party engines" are getting better.  But the list is always changing.  While Unreal and Unity are two popular ones, they are not the only ones. There are many other engines, others are coming and going all the time: C4, Hero Engine, Game Maker, Shiva, Havok, Marmalade, MaxPlay has shown up at a few events, Amazon's new entry is Lumberyard, and so on. The engines of yesteryear have been replaced with today's kingpins. Today's engines may not be tomorrows engines.
AAA products have money. Lots of money.  These days it means spending about a hundred million dollars on development. No matter what tools they work with, large projects are likely buy the source and manipulate it to their needs.

#5293595 Are Third Party Game Engines the Future

Posted by frob on 26 May 2016 - 08:50 AM

As technology improves and third party tools improve, do you think that the bigger AAA game studios that have internal engines will eventually switch to using third party engines or will the industry continue as is for the foreseeable future?

Engines and middleware save time and money, so they are here to stay.

The tools of the day are always changing and evolving. For example a project may use use FMod, WWise, or Miles Sound System, or some other audio product.

The choice of any particular technology is always in flux. If you're a true "bigger AAA game studio" then you've got enough millions of dollars that you have a license to use and modify the source of whatever engine and library technology you are using and bend it to your needs.  If you decide some technology doesn't work for you, you can adapt it and make it use different technology.


Game engines are not only the future, they are also the present.  They've been in the industry for many years already.


Exactly how you classify them, "third party engines" versus "in house engines" is not really relevant. Somebody makes them, it doesn't particularly matter who made them, only that the tools exist and can be used to build better products.

#5293345 what good are cores?

Posted by frob on 25 May 2016 - 07:14 AM

There was a great article back in 2004: 

Moore's Law stopped being about faster processors well over a decade ago.  The approximate doubling still takes place, but it is in parallelism.  Anyone wanting to take advantage of higher performance than what you saw around the year 2000 will need to learn to parallelize their processing.
As game programmers we are often looking for the easy win.  Task-based parallelism is often an easy solution to take advantage of parallel processing.  Build a queue of many different independent tasks, have one worker per processor, and pull off task after task until all of them are done.
Many individual algorithms can be implemented as parallel processing problems, although depending on their size may not make sense in games.
Parallel search is a classic problem with superlinear speedup when done with parallel processing, but for smaller data sets often isn't worth the cost of setting up the parallel work. Searching among a few thousand items a brute-force linear search is faster than distributing them and then doing the linear search. (Of course a binary search is probably faster still, and has buckets likely faster again).  For under 1000 small items, potentially a linear search can be faster than a binary search thanks to cache effects. 
Parallel rendering is another classic problem with near-perfect parallel results. Your graphics cards implement this behind your back. Some people use GPGPU programming to take advantage of it. Some libraries like PhysX take advantage of it. 
There is a great book that was placed online, Designing and Building Parallel Programs. The book is starting to be a little dated, but the theory still applies. Learning its methods you can break down just about any traditional algorithm and rebuild it as a parallel algorithm.  There are other books with alternative methods that also work, but they're not in free books. 

#5293143 Confused About Frames Per Second

Posted by frob on 23 May 2016 - 09:22 PM

It is often a little confusing to people who haven't worked on modern games.


Many games have simulators that operate in the future as far as the human is concerned.  


The simulator advances time occasionally as needed, usually thinking about the near future. The display shows somewhere in the past on the timeline at an approximate location between the previous simulated location and the approximated future simulation. User input generally gets inserted into the game simulation, in many modern games the simulation rewinds time a little, inserts the commands back where the player expects, then replays the future with the new input.


Although it sounds rather complex, in practice it means a few hundred kilobytes or possibly a couple megabytes of data gets kept around between simulation steps, and rendering gets a tad more work.

#5293094 Confused About Frames Per Second

Posted by frob on 23 May 2016 - 12:38 PM

You're right, I did actually modify it so that the render call only happens when it runs an update of the game state, because why render if nothing has changed?
I'm not sure what you mean by tweening though.

Assuming animation is happening, you still need to render when nothing has changed because something HAS changed.
Tweening is an old animation term, drawing the frames in between key frames.  It applies here because something HAS changed.
That something is time.
If you reread the "Fix Your Timestep" article, you'll see this near the bottom:


What this means is that we’re displaying the state of the physics simulation at a time value slightly different from the render time. This causes a subtle but visually unpleasant stuttering of the physics simulation

The solution is to draw as though you were pat of the way through.  
Imagine you have simulation time steps simulated at simulator time step 2973 and 2986, and your rendering is taking place at simulator time step 2976. That means you don't draw 2973 because that is too far in the past, and you don't draw 2986, that is too far in the future.  You draw 23% of the distance between the past and the present.  If your next render takes place at simulator time step 2985 you still don't need to update the simulation, but you draw at 92% of the distance between the past and the present.
Decoupling your rendering step from your simulation step is part of the solution.  Once it is decoupled so you are no longer simulating every frame, generally you need a somewhat more difficult step of triggering the rendering interpolating between two simulator steps.

#5292958 Confused About Frames Per Second

Posted by frob on 22 May 2016 - 06:27 PM

> What I don't understand is, if most games run at 60FPS, why does mine feel so off? It seems like it should still run smoothly either way,


Not all frames-per-seconds are equal.


Create another trio of timers, updated every second:


Min ms / Avg ms / Max ms


That is, the fastest frame time in milliseconds, the shortest frame time in milliseconds, and the average frame time.


60FPS means 16.6 milliseconds per frame, but with those three numbers you can see quite a lot more.


60FPS can give 16.4 / 16.6 / 16.6

60FPS can give 12.8 / 16.6 / 38.3

60FPS can give 1.4 / 16.6 / 143.8


All are at 60 frames per second. The first is rock solid.  The second has at least one small hiccup, a frame taking 2 frames worth of time and others making up for it.  The last one, however, indicates some fairly erratic behavior is going on.



Even better, have several sets of timers.  One for the full time including the page swap, another one for just your render time.  And perhaps another for your simulation times. And perhaps another for your physics times.  You'll probably want those timers in microseconds or even nanoseconds rather than milliseconds.


Before long, you'll have enough profiling data that you can start to make informed decisions about the performance of your game.

#5292899 APP with GPS and GOOGLE MAPS

Posted by frob on 22 May 2016 - 12:34 PM

> Could I make the app with java?
If you want.
> Should I use Android?
If you want.
> which API can you recommend me for the GPS and the interfaces
If you are developing for Android devices, probably their location services API

#5292897 Terrain Rendering

Posted by frob on 22 May 2016 - 12:26 PM

Terrain clipmaps doing LOD on GPU terrains from GPU Gems 2 book


Much more complex terrain generated by GPU from GPU Gems 3 book


There are many more articles and examples and videos and tutorials on it, and those articles are a little dated, but they should serve as a good launching point for learning.

#5292796 Terrain Rendering

Posted by frob on 21 May 2016 - 05:35 PM

Terrain via heightmap textures was one of the first big uses of programmable GPUs.


Incidentally, it also destroyed my masters thesis work where I was working on continuous level of detail for terrain at the time. People in my lab said "You need to see this announcement." It was a press release for the GeForce 3, and the demo video was about 100 square miles worth of terrain being processed with newfangled "shaders".  


With a single shader and a heightmap, the card does all the work to display all the ground geometry for an enormous area. No terrain mesh needed, just the height map that the shader uses to figure out all the heights.  You still need to throw on textures and modeled objects, but those are not that difficult.

#5292722 how much PC do you need to build a given game?

Posted by frob on 20 May 2016 - 09:06 PM

Right now, any standard commodity PC is powerful enough for building a modern game.


A typical off-the-shelf machine is more than enough for any hobby game an individual can build.


You may not be able to reach some of the highest-end, most cutting-edge features, but you aren't making that type of game without a multi-million-dollar budget anyway.

#5292721 can a generic engine do something like skyrim?

Posted by frob on 20 May 2016 - 09:03 PM

Unreal and Unity out of the box could come close enough for hobby work, where you also are not going to do as much world processing.


You would need lots of assets, lots of custom shaders, lots of programming work.  Performance-wise such a system would struggle on a brand new machine. You could not reach the raw performance numbers without modifying the engine's source and fixing up a few things. Both engines are fairly poor at multiprocessing out of the box, and neither is designed to take advantage of the most modern video cards like Skyrim does, but the engine can be modified easily enough.  


It would still need a couple thousand development-years of effort, and a 9-digit dollar cost.


If you're paying hundreds of millions of dollars for people's salary, paying five or possibly six figures for engine source is cheap, then you can fine-tune as you see fit.

#5292515 How should I organize Java Classes?

Posted by frob on 19 May 2016 - 10:48 AM

> Often you'll find you have a class that wants or sometimes needs to do multiple things, and you won't know what to name it to reflect that. 



Single Responsibility Principle helps with that. When it does more than one thing, make more than one thing.


You still have the struggle of naming the things. "Manager" is a banned object name at my present and my most recent past employer, partly at my recommendation.