Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jun 2005
Offline Last Active Today, 10:44 AM

#5232979 I am beginning to hate the IT and gaming industry.

Posted by on 05 June 2015 - 11:51 AM

Didn't notice that this thread was bumped again.  Since it's still open, I'll add that I'm back where I started again.  Time to go though this BS job hunt crap again.  And tbh (I'm not saying this to stir up drama), I S-T-I-L-L not convinced that employers care about skill, but only job experience and your ability to ace the whiteboard on the first try.  That's the ONLY way I ever get IT jobs.  I almost had a job as a deployment engineer for Starbucks, but I got outclassed by one guy.  Soooo close.


Going to go back through the thread and re-discover a few suggestions.



Okay, 17 interviews later, finally got a new job.  It pays rather well for a position that doesn't require immediate coding ($70k). 
I guess I just had a Vegeta moment for a while there.

Someone like me would happily take $10/hour job because its already a lot of money per month if you live in India. Avg. income of an Avg. person in India is $1000 per month.


$1000 usd/month isn't enough to survive on here, and is considered poverty.  In the small town I used to live in, I made slightly less than that.  But now, such a low wage is illegal in the US.



#5223575 GLSL Procedural Animation bug

Posted by on 15 April 2015 - 07:35 PM

Okay, finally fixed it.  After altering some instructions a bit to tweak stuff, I discovered that it was the EXP instruction that was causing the problem, which I'll explain in minute.  I got curious and replaced exp with sin and some variations below:


R0.y = sin( R0.x * 3.0 ) * 0.5;


That worked, but it was inaccurate.  So I looked up the EXP instruction on the ARB_vertex_program documentation, and it said this:



Section,  EXP:  Exponential Base 2 (approximate)

    The EXP instruction computes a rough approximation of 2 raised to the
    power of the scalar operand.  The approximation is returned in the "z"
    component of the result vector.  A vertex program can also use the "x" and
    "y" components of the result vector to generate a more accurate
    approximation by evaluating
        result.x * f(result.y),
    where f(x) is a user-defined function that approximates 2^x over the
    domain [0.0, 1.0).  The "w" component of the result vector is always 1.0.
    The exact behavior is specified in the following pseudo-code:
      float ScalarLoad(floatVec source) 
          float operand;
          operand = source.c;
          if (negate) {
            operand = -operand;
          return operand;
      tmp = ScalarLoad(op0);
      result.x = 2^floor(tmp);
      result.y = tmp - floor(tmp);
      result.z = RoughApprox2ToX(tmp);
      result.w = 1.0;
    The approximation function is accurate to at least 10 bits:
      | RoughApprox2ToX(x) - 2^x | < 1.0 / 2^11, if 0.0 <= x < 1.0,
    and, in general,
      | RoughApprox2ToX(x) - 2^x | < (1.0 / 2^11) * (2^floor(x)).

It didn't hit me right away, but EXP is a multi-function instruction, and the original author was using the 2nd function.  You select the function you want by selecting the destination field in your vector.  So I changed that line to this:


R0.y = R0.x - floor( R0.x );


And now it works perfectly.  Never would have guessed that was the problem.  Now I can finally get on with life.  Thanks for reading.



#5222088 Using named POSIX mutexes?

Posted by on 08 April 2015 - 10:26 AM


I'm asking because the primary purpose I'm asking is because I'm attempting to write some code that detects multiple instances of my app running on the same machine for Linux and MacOSX.  The steps (in theory):
- Attempt to create a mutex with a specific name that matches the app's ID.
- If it already exists, then this app is already running.
- If not, save this mutex until the app exits, then destroy it so the app can be relaunched.


I realize you may have already found an answer to HOW, but I'm wondering about the reason WHY?



Is there some reason you must prevent multiple instances of your app at once?   I know often you prefer your game to be run one way, but is there a reason you must absolutely forbid it from being run another way?



As an example, on several titles I found it useful to launch several instances of a game, perhaps 2 or 3 or 4, all on a single machine.  I'll have them connect to a game server (also running on the same machine) and hook up one or two debuggers as needed.  Yes, the performance degrades into something terrible, but for debugging purposes it is far easier than finding four open machines to use, or configuring my machine to run four virtual machines and running the game inside each. 


As another example, sometimes games appear to close quickly by destroying and hiding windows but continue to run in the background cleaning up resources for quite some time. Or they crash and it takes the operating system an extended time to clean everything up.  In that case I may want to launch another instance of the game immediately, and if some stupid shared object is still hanging around it can take quite some time before I am allowed to start my next instance.



The point is, it seems like you are trying to force your decision that your game is really a singleton onto the user.  For whatever reason, you have decided that even if the user wants more than one the user is wrong, and the user's decision shall be overruled.  Usually that is the wrong decision.


Good points (and many of which I didn't think of).  Although I have multiple machines handy to test networked games, I'll have to try that idea.


This is actually some functionality I'm adding to my engine (not necessarily to a specific game), where the programmer can choose what he wants to do when there's multiple instances existing.  The exiting/shutdown case you stated is a good reason not to force it, but sometimes when it takes a minute or two for your game to load/start, the user might get impatient and just start clicking away thinking "why won't you start?", and then end up with multiple instances of the game running as a result.  This has happened to me before, and it's been a pain to close out multiple windows of a AAA resource hog, especially if I'm in fullscreen.  To me, it's undesirable from an end user standpoint.


A better solution would be to display a dialog stating that there is another instance of the game running, and allow the user to confirm that he wants two or more instances running.  And as a bonus, include a check box that says "Do not display this message in the future".  How does that sound?



#5221762 Using named POSIX mutexes?

Posted by on 06 April 2015 - 09:01 PM

I'm not sure if pthread defines system-wide named mutexes, but the POSIX standard defines named semaphores, and a mutex is just a special kind of semaphore (that only takes values 1 and 0 and that is initialized to 1) so that should be good enough if not as handy.


Look at the sem_open function for how to use it. You might also want to read that SO question: http://stackoverflow.com/questions/16400820/c-how-to-use-posix-semaphores-on-forked-processes

I tried the POSIX semaphore idea, and that worked like a charm.  So much nicer than file locking...



#5221699 Using named POSIX mutexes?

Posted by on 06 April 2015 - 02:49 PM

Okay, I have a question about using POSIX mutexes.  I've searched all over the net, but I can't find any examples on how to create a named POSIX mutex.  Can this be done?  I've searched google for quite some time, and no concrete answers appear.


Also, assuming a named POSIX mutex can be created, can I create the same named mutex twice?  I'm asking because the primary purpose I'm asking is because I'm attempting to write some code that detects multiple instances of my app running on the same machine for Linux and MacOSX.  The steps (in theory):


- Attempt to create a mutex with a specific name that matches the app's ID.

- If it already exists, then this app is already running.

- If not, save this mutex until the app exits, then destroy it so the app can be relaunched.


This is how I handle this problem using Windows, so I assumed you could do the same thing using MacOSX and Linux.  If not, then I'll use a slightly messier solution, a file lock (yuk!).  Any ideas?  Thanks.



#5220782 From scratch vs Unity

Posted by on 01 April 2015 - 01:27 PM

Takes a lot longer to get anything done
Potentially less deployment options

Good points overall, but I don't quite agree with these cons of writing your own completely (for reasons I've stated in my last response).


- If you are writing every component from scratch, then yup, you're going to be at it for a long time.  That's why I chose to use many particular open sourced libraries for the complex and redundant stuff.  Unless you really want/need to, I don't recommend writing every component from scratch.


- Well, it depends on what your engine requires.  If you are using PhysX for example, then it will limit your deployment options unless you can pay for a license.  To get around that, I simply used Tokamak because it's a well written C++ library, and called it a day.  What you decide to use can limit your options if you are building a commercial game for platforms with higher exclusivity.




EDIT: I really should write an article about my experiences with writing a custom engine to hopefully clear up certain misconceptions and invoke in depth discussion, one that even I could hopefully learn from :)

#5220554 How it will be a company?

Posted by on 31 March 2015 - 02:14 PM

Szía Gábor, hogy vagy?


Geri igaza van.  A szofverfejleszto"égek elhagyják Magyarországot, mert az adók túl magasak. sad.png


Minden magyarnak sikeresnek kell lennie! smile.png



#5219758 From scratch vs Unity

Posted by on 27 March 2015 - 07:03 PM

I wrote my own engine for these reasons:


1. Portability: My engine needs to work on whatever platform I want it do.  "But Unity runs on everything, including <insert platform here>", it becomes a problem not being able to use your language of choice.

2. Licencing: No need to worry about licensing fees, which is great.

3. Optimization: Have you ever tried optimizing a closed source commercial engine?  It sucks because you can't do it.  Size optimization is one issue.  One issue I see people talk about when it comes to Unity is minimum binary size.  I already have a rather complex engine, and I can remove the complex components that aren't being used if need be.  My engine generates very large executables (15mb in general, but VS13 takes 3 minutes to optimize it down to roughly 3mb).  Sometimes, that's not desirable, especially if you are running on a platform with fixed resources.  Another is rendering.  Sometimes, I need certain functionality that Unity might not give me, such as GPU fencing, command buffers/lists, or direct hardware access on certain embedded platforms.

4. Custom needs: Unity can't do *everything*.  It does many things, but sometimes, a closed source engine can limit your game in some ways, sorta like above.


Reasons I don't use Unity (don't take offense to this, I'm entitled to my opinion):


1. I wouldn't be caught dead writing a game in C# (my preference).

2. Pride as a seasoned and experienced programmer; I'm not a n00b.

3. I don't like Unity, or the fanboys who can't do a dammed thing without it, and yet criticize those who write their own.


I'm also going to say this (and I've said it before).  When people hear the words "writing your own engine", they are immediately thinking "writing everything from scratch, hence re-inventing the wheel".  This isn't always the case, and in mine, definitely not.  My engine consists of multiple open source components with compatible licenses making it suitable for commercial projects.  You don't have to write everything yourself.  Let me give you a rundown as to how I chose my engine's components:

  • Tokamak for physics.
  • Stb for texture based ttf font rendering and ogg decompression.
  • Assimp and OpenCTM for 3D mesh parsing.
  • SDL for various portable solutions involving threading/synchronization, timing, OpenGL context management, input devices, etc.
  • Some misc code from the NVSDK used for debugging and other stuff.
  • NVIDIA's Gameworks SDK for lots of misc stuff, like the excellent open source and extensive math library.
  • NVTriStrip to "stripify" primitives.
  • jo_jpeg, a simple jpeg library I use for screenshots.
  • ezxml or irrXML for XML parsing.
  • Enet as a reliable UDP based networking client.
  • Angelscript for scripting.

What I have written is basically the glue to put everything together in a neat and organized set of interfaces.  Some things I wanted to write myself, such as an extendable 3D rendering, audio and input interface that supports Direct3D, core OpenGL, OpenGL ES, OpenAL [soft], FMOD, OpenNI, Leap, etc.  So putting this all together was done rather quickly, and done in about 2 months worth of work off and on.  You might say that "I don't have that sort of time".  Then fine.  Time is the most valuable resource, as it is not renewable, but it's also important to use your time wisely, and considering my needs, it was well worth it, (and no, I didn't do nothing but write this engine; I worked on it in conjunction with a planned title).


This isn't an attempt to belittle those who use Unity, it's my defense from those who act like they are better than me because I don't.  Do what works best for you.  I've chosen my path, and it works best for me.  If you need Unity or UE4, go for it.




EDIT: I ended up replacing NVTriStrip with TriStripper because I hear that it's not only faster, but has less bugs and has greater flexibility.  Also added "recastnavigation", which uses Detour and Recast for AI navigation for 3D realms.

#5219746 Windows mouse event handling (outside of the target window).

Posted by on 27 March 2015 - 05:48 PM

Well, there's a story behind the reason why I chose [Free]GLUT, and kept it.


This was initially a prototype concept from an idea I had once before going to bed.  At the time, I just wanted to test it as quickly as possible plus it was an unseen benefit to be able to press a button, and the window changes to a borderless window the size of the desktop resolution.  On top of that, I originally wrote this for MacOSX, and I didn't know how to initialize OpenGL without it before then.  So, I kept using it.


For this game, FreeGLUT is fine.  For my engine (which this game predates and hence, does not use), I use SDL because it contains various functions for system related stuff, and I can also use Direct3D with it.



#5219719 Windows mouse event handling (outside of the target window).

Posted by on 27 March 2015 - 03:49 PM

Eureka!  GetCursorPos followed by a call to ScreenToClient solved the problem!


Now I can finally get ready for my game's beta release on Windows :)


#5217531 Question about saved games

Posted by on 18 March 2015 - 08:38 PM

Writing a game's save data to disk can easily be as simple as writing the contents of a structure to a .bin file.  That's what I do for my game(s).


Example (C/C++):

/* A carefully aligned structure holding your game save data */
struct savedata_t
   int level;
   int score;
   char user_name[16];

bool save_game_data( struct savedata_t* savedata )
   /* Attempt to create a new save game */
   FILE* fp = fopen( "mysave.bin", "wb" );
   /* If successful, write the data, and exit.  If not, return a failure */
      fwrite( savedata, 1, sizeof( struct savedata_t ), fp );
      return true;

   return false;

A game save can contain more than just variables, maybe something like a bitmap icon used as an avatar, etc. so you'd have to take alignment and formatting into consideration.


Another thing you could do would be to write some content to a .xml file then inject that and any other files necessary inside of a binary container such as a .zip file (which could have any extension desirable to mask that it's really a .zip file) so that everything is kept in one single file that can be read and/or written to easily.  That's my two cents.


Other than that, I totally agree with golergka.



#5215495 GUI Challenge

Posted by on 09 March 2015 - 02:53 PM

nothing but complete idiots on here.




... you're obviously very new to this forum, aren't you?



#5209535 How do I fix this stupid linker error?

Posted by on 09 February 2015 - 12:02 AM

Okay, finally fixed it (thanks to Bacterius).


Changed this:

LOCAL_LDLIBS := -lopenal -lGLESv2


To this:

LOCAL_LDLIBS := openalsoft/armeabi-v7a/libopenal.so -lGLESv2


Sorry for cursing, I spent far too much time dealing with Android stuff then getting actual stuff done.



#5208344 1997 game graphic files

Posted by on 03 February 2015 - 12:28 AM

Maybe one of you knows how sprites were stored in 1997 or recognized the file signature.


For starters, keep in mind that you can't assume every DOS game uses the same resource file format.  Usually they are custom designed to keep the every day person from easily reverse engineering it because devs generally don't want their assets stolen, so you could be infringing copyrights here depending on your intent.  Keep in mind that there are some exceptions, but you certainly cannot count on those either.


If you're really serious about this, then you might want to start off with building good reverse engineering skills.  Start by getting a good .exe disassembler and get a good knowledge of how x86 assembly works.  If you don't know assembly, then there may be a rather steep learning curve ahead of you.  I bought a book about reverse engineering, and it gives plenty of examples on reverse engineering functions in x86 assembly and discovering how code on a low level really works.



#5207766 Programming

Posted by on 30 January 2015 - 04:42 PM




Listen to her.  She knows what she's talking about.





That is the internet for you... Rule #37... the power of avatar images and game avatars. smile.png

Right.  I'm still amazed how many people (even staff) keep mistaking L. Spiro for girl, even though he's explained the story behind that sketch he drew multiple times.


Btw, to the person who just rated down that comment... Not to be a jerk, but FYI, given the above statement, please don't get it twisted.  I should have known that someone wouldn't catch the reference, and probably go "zomg misogyny"!  Or maybe I just wrecked someone's fantasy about L. Spiro being a girl. :)