Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jun 2005
Offline Last Active Today, 06:13 PM

Topics I've Started

A practical approach to pseudo instancing for OpenGL ES 2.0?

08 April 2016 - 12:27 AM

Okay, the reason I'm asking about pseudo instancing is because last I checked, OpenGL ES 2.0 devices still dominate the market.




*shoot, I can't find a single article on the statistics of iOS devices capable of using 3.0+*


Eventually, OpenGL ES 3.x will overtake the marketshare, and ES 2.0 only devices will dwindle as it did with ES 1.1 and below.  Until that day comes along, I want to consider the most practical approaches for pseudo instancing where hardware assisted instancing is not supported.  My engine is crossplatform, and I intend for it to work on iOS, Android and Blackberry.  Ever since iPhone 5S, iPad Air/Mini w/ Retina, iOS has supported OpenGL ES 3.0 and also Blackberry since the Z30.  So it seems that it's becoming easier to get away with having an ES 3.0 only game engine, but I'd rather not do that at the moment.


So, what is my actual question?  I'm glad you asked.  When I think of two implementations of pseudo instancing, two things come to mind:


1. Use separate draw calls in a loop for each mesh and use an array and index to access attributes (not literal vertex attributes) related to that instance.

Example: http://carloscarrasco.com/faking-mesh-instancing-in-opengl-es-20.html


2. Use a dynamic VBO and encode the instance data into the vertex structure in order to limit everything to one draw call.



struct PseudoInstanceVertex
   /* Standard vertex attributes */
   vec3f position;
   vec3f normal;
   vec4f diffuse;
   vec2f texcoord;

   /* Instance vertex attributes */
   vec3f rotation;
   vec3f translation;

Then for each geometric shape, update per frame.


So, which one do you think is better?  My assumption is that #1 would be best suited for static geometry like trees in a forest that are primarily stationary and generally do not move, and that #2 would be best suited for dynamic geometry such as NeHe style butterflies made up of two procedurally generated triangles.  #2 would also have a bigger memory requirement and #1 is a bit heavier on the CPU.  I'm having a bit of trouble deciding which one has the better tradeoff.  So, any ideas?  Thanks.



I am beginning to hate the IT and gaming industry (Part 2)

04 April 2016 - 03:27 AM

A little over a year later, I feel a need to do a sequel to my previous thread: http://www.gamedev.net/topic/664743-i-am-beginning-to-hate-the-it-and-gaming-industry/


Now, going back to some of the advice from that thread, and looking at my current experience and perspective, I can honestly say that my views towards the industry haven't changed much, even though I've worked on two great positions since then.  To be quite honest, I still hate how this industry works and it's really burning me out.  Some things cannot be helped, others are just bogus and obsolete traditions that employers cannot seem to do a way with.  This isn't a "tantrum" because I couldn't get job at company XYZ, but more of a continuation of my previous venting about my frustration involving a vicious cycle of [finding/keeping] employment and security.


Rather than ranting away, I'll share a list of points like I did last year.


1. Whiteboarding


The one thing I absolutely hate the most about interviewing, and that is whiteboarding.  Let me get this one out of the way first.  Let's face it, whiteboarding sucks, it's mundane, and it cannot accurately attest to a candidate's actual ability to perform the given task.  Apparently, more and more software devs are agreeing with this.






From Forbes:


You give them a coding challenge, like “sort an array of 100 integers.” They have to stand up, turn to a vertical blank slate and handwrite code from scratch while a handful of senior engineers scrutinize their every word and move. Writing code on a whiteboard is a skill in and of itself. How does this awkward experience tell you anything meaningful about how well engineers can truly think and work in their element?


From Techcrunch:


Few professions seem so openly hostile to their current members as software engineering … we expect people to do live engineering on a white board under stressful interview conditions because, well, because that is what we have always done … In a time of engineer austerity, we simply can’t afford to throw away so much talent.


The software developer job interview doesn’t work. Companies should stop relying on them. The savviest teams will outcompete their peers by devising alternative hiring schemes.


I believe these sum it up nicely, as it has been my experience also.  Now, I've heard many of you say, "interviewers are more interested in your problem solving skills than how well/accurately you code the actual problem".  I always have and always will call bulls**t on that.  If that's so, then why do I NEVER get the job unless I nail the whiteboard problem on the first try with no error and at full optimization?  I've demonstrated great problem solving skills and have been commended on it multiple times, but still didn't get it because I didn't do the problem perfectly.  So you can tell me this until you are blue in the face and I will never believe it since I've been through many, many, many white board interviews.


A whiteboard test does little to attest to someone's skill or experience level.  There's really no point in solving some mundane problem that will never really be used in most cases.  On top of that, the ability or lack thereof to solve that particular problem within a certain amount of time does not attest to one's skills either.  There are many common whiteboard problems out there, most of which can be googled and practiced as well as memorized.  That way, a poor or inexperienced coder could slip under the radar with ease.  Good candidates aren't like parrots; memorize and repeat.  They are built to solve real world problems in practical conditions and environments.


One of the last interviews I had, the interviewer told me that he felt (based on the whiteboard) that I would not be able to ramp up quickly enough and that I would likely be replaced during this 4 month contract time period.  That is complete and utter nonsense.  How the hell can you tell this by someone's whiteboarding exam problem that has NOTHING to do with the task you're actually being interviewed for?  See how retarded this process is?


Fortunately, my last position at Microsoft didn't involve a whiteboard test, and I was very grateful of that.  Because of that, I was able to prove and demonstrate my exceptional skills as an SDET with hardware and driver level programming skill and leave a lasting impression on my superiors and co-workers.  Some of that stuff I wrote would be solutions that most experienced coders would not have come up with because I had both the affinity and the aptitude for the task at hand.  If they had gone through the usual BS whiteboard exam, not only would I not have gotten the job, but much of the work going into one of their latest devices would likely have never been done.


So frankly, I've taken much of the advice on whiteboarding in my previous thread, and it never really helped.  Only a perfect whiteboard answer would get me the job, nothing else.  Bottom line: whiteboarding.... it just, doesn't, work.  There's not much more that I hate about interviews with a hiring manager who has already determined that you don't have a chance in hell at getting this job because of the whiteboard test, but still smiles in your face and talks as if you do.  I mean really, at my last interview, one of the interviewers wrote something on a piece of paper and showed it to another person next to him right in front of me.  Wtf?  How stupid do you think I am?


Bonus fact: The last two jobs I had didn't require me to take a whiteboard test, which I believe is the primary reason why I got those jobs.  There was one more I could have had, but I was told I was overqualified since I talked about my coding skills/experience.


2. Contract vs. Permanent


This can't always be helped, and it's a part of life, I understand that.  But in my experience (and in others, I'm quite sure), more and more companies are either outsourcing their projects to recruiters or just simply hiring temporarily for a single project.  It makes sense in many ways, but at the same time, when it comes to contract work, you can never really expect it to last the full duration you are quoted.  For me, it never does.  Never.  If I'm quoted a year, I'd expect to be employed for half of that roughly.  This is especially true during release time, then they start looking at ways to cut budgets and starting dishing out layoffs.  It's so predictable, and tiring not being able to settle down at one place.  Of course, one good thing about this is that with every new job I get, my salary increases and my worth as an employee is easier to self quantify.  But knowing that you are about to get the boot as well as knowing that you are expendable at any sudden moment can really put pressure on you to perform or even outperform co-workers.  The animosity created by competition is real, and I've seen it more than once, even at Microsoft.  The last thing I want is to be pitted against my co-workers for the sake of keeping a job and/or becoming permanent.


"If you are tired of contracting, why not apply for full time?".  Do you think I haven't been trying that??  The consideration, availability and sheer competition for full time employment is astronomically stacked against you.  I've been searching my arse off for it.  So far, I've only had one interview for full time, and let's just say it was whiteboard related as to why I didn't get it.  Employers are getting tighter and tighter, and are looking for clever ways to save a buck, even if it means trying to find senior level people and trying to avoid paying them what they are worth.


3. Startups & Small Companies vs. Big Corporations


Now, I get a ridiculous amount of the same suggestion on this.  And that suggestion is, "why don't you try a startup or a smaller company instead"?  Once again, do you think I haven't been trying those??  The truth is, I've had a MUCH harder time with applying for startups and smaller businesses than the large "gargantuan" companies as someone put it before.  Startups generally don't give me the light of day.  Believe me, I've tried many times.  The larger the company, the more success I tend to have.  If there's one thing I like about Microsoft, is that they usually give me a fair trial inspite of them being one of the lower paying companies.  And if I had to choose, I'd likely choose a gargantuan company because I don't like the "social friendly beer friday" types of company atmospheres.  I want to come to work, get my stuff done, work hard, build myself up, and maybe an occasional goof day.  None of that extra stuff.  If you want to party and drink, don't do it around me and look for an excuse to dig up dirt on me with HR; why not do it on your own time?  Leave me alone and let me work.  So yeah, the work hard feel of the big corporate environment is what I like.


4. All About the Experience


Some of this I already ranted before, but I'll do it again.  Yup, no experience == no job.  End of story.  I keep hearing stuff like putting your own projects or things like game jams or coding competitions on your resume.  That stuff never really seems to work for me.  Maybe it does and I just don't know it, but employers never talk about it; rarely if ever.  I've even had one employer say that I had no experience based on personal projects.  On top of that, it tends to confuse employers and recruiters.  So, I generally don't bother.


So unless I've done <insert here> and got paid for it by someone else, I'm not experienced?  Yeah, F you.  If I had mountains of experience as they always seem to search for, I wouldn't be looking for a job, would I?  Because I'd have companies throwing themselves at me like blonde gold diggers throwing themselves a millionaires. 


I do understand that experience is important, especially in this field.  The more experience I gain, the more I understand the difference between an experienced professional developer and the high school or undergrad who's only taken a few courses and done a few side projects.  Speaking of inexperienced, what's with entry level positions having such strict experience requirements? 


5. Enthusiam Makes Up for Inexperience


Riiiiiight, sure it does.  Another thing you'll never convince me of.  Seriously, if that were the case, then I'd have had much more success.  If I had a dollar for all the enthusiasm I've shown to make up for inexperience, I'd have enough to pay my rent (and I don't right now, and it SUCKS)!  You can have all the enthusiasm in the world and they still won't give you the light of day.  Only one exception I've had was a company (that some of you might be surprised to know still exists) that wanted to give me a chance due to my enthusiasm.  What happened?  Still didn't get the job because of "not enough experience".  This goes for big and small companies, and startups have been the most picky about it so far.


6. "Overqualified"


This is one thing I never touched on in the last rant.  What the hell is "overqualified"?  Don't you want someone that can go above and beyond for your company?  Or do you fear the candidate would get "bored"?  These days, a job is nothing to be taken for granted.  One member here says that basically means "you are a threat".  I guess I could see that, but really, with companies not willing to pay someone a competent salary, what the actual frell?  Normally when you hear the words "overqualified", it's hard to get out of that zone.  So far, I've gotten out of the overqualified zone only once.  Still didn't get the job though.



So that's my rant for this year.  Not nearly as long, but sharing my experience based on the responses on the previous thread as well as the results from trying out those suggestions.  My general opinion hasn't changed from last time either.  And just to reiterate this once more, I do not want to work for a gaming company, ever again.  Just so we're clear on that because I like being treated and paid like an adult.


I've even thought of saying something like this at an interview before: "How about I refuse your whiteboard test?  Why?  Because it's an out dated, mundane and ineffective way to judge someone's skill or experience level.  Do you seriously expect to accurately measure someone's talent or problem solving skills by putting them on the spotlight where everything you write or say can be used against you?  Better yet, how can you be sure this isn't a problem I've memorized through the internet?  I've proven that with my previous and extensive experience that I already know how to code effectively, even through a nice list of references.  Now, unless you have a more practical way of evaluating my skill set, I will walk.  What do I suggest?  I dunno, you tell me.  Show me the door."


Needless to say, I see a growing number of devs getting tired of this cycle.  And now I want to break it.



An alternative to glutGet(GLUT_ELAPSED_TIME)?

18 March 2016 - 04:12 PM

Lately I've been trying to fix my game's timer code for Android and Linux.  I initially wrote this game as a small demo using GLUT, but now that I've moved away from GLUT, I want to replace this code with something else.  I've already successfully replaced this for iOS, Windows Metro and Blackberry, but not for Android.  What gives?  This shouldn't be that hard.  This is the code that I have used, as well as the multiple implementations I tried but failed on.

#include <sys/sysinfo.h>
uint64_t getTickCount(void)
  // 1st attempt
  struct timespec now;
  if (clock_gettime(CLOCK_MONOTONIC, &now))
    return 0;
  return now.tv_sec * 1000.0 + now.tv_nsec / 1000000.0;

  // 2nd attempt
	struct timeval tv;

	if(gettimeofday(&tv, NULL) != 0)
	    return 0;

	return (tv.tv_sec * 1000) + (tv.tv_usec / 1000);

  // 3rd attempt
	struct sysinfo si;
	if(sysinfo(&si) == 0)
		 return si.uptime;
	return -1;

At this point, I am really running out of ideas.  I'm sure it's something stupidly simple that I'm doing wrong.  Any ideas?  Thanks.



Does my game only work when installed using ADB?

18 March 2016 - 03:28 AM

I recently managed to re-port my game to Android and for me it works without any issues, but everyone else I've given my game to says they just get a white screen.  This isn't making any sense to me.  The difference is that everyone else is downloading it directly from the link below and running it from there while I and one other person installed it through ADB and it works normally.  Why is that?  Does that mean there's something wrong with my code somewhere?


For those that want to try it, you can click the link and downloaded here: *nuked; I'll release a more functional build later*


This should work on any device running API 10 or greater, and the target sdk version is 16 to keep it compatible with most devices.  Lastly, I don't know if this would have made any difference, but I used Eclipse instead of Android Studio because I never did find any resources on the recent NDK support, and Eclipse just worked unlike everything else for me.  If it does run, then keep in mind that it won't be scaled properly in "Story Mode" because I didn't fix that yet (no need to point that out).  But if you could try it, that would be greatly appreciated.


I ran this on my Nexus 7 (2nd Gen, 5.1) and my Droid1 (4.1.1).  Both ran for me, but of course the latter device can't really handle this game too well due to it's age, small screen resolution and low quality touch screen.  I've gotten the white screen on the Droid1 before, but I'd wait it out and the game would work for me after a minute or two.


So one thing I did was remove the white screen by adding  this to my style.xml

<item name="android:windowNoTitle">true</item>

When I get a chance, I'll do a splash screen...


Any ideas?  Thanks.




EDIT: Just tried downloading it from the net directly on my Nexus 7, it didn't work; just the white screen.  But installing using adb does work...


EDIT2: Nevermind, I fixed it.  I forgot to comment out one particular line (Debug.waitForDebugger() to be specific) that causes the device to wait for the debugger to attach itself.  I thought for sure that I did...

SDL: How do I get a native handle to the OpenGL context

26 February 2016 - 08:04 PM

My engine is using SDL2, and per platform, I'll need to do some OS specific tasks.  Sometimes I'll be required to get the native handle to the OpenGL context directly, especially when it's necessary to access non-portable functionality.  Example, for MacOSX (please don't troll) the accurate way to enumerate GPUs and their features is to use the low level APIs.  For iOS, sometimes I need to do similar things.


So, is there a way to get a handle to the native OpenGL context for SDL 2.x?  I tried googling, but I guess I haven't used the right keywords so far.  Thanks.