Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jul 2003
Offline Last Active Yesterday, 07:40 PM

#5166733 Storing position of member variable

Posted by swiftcoder on 14 July 2014 - 08:10 AM

Since I have both the class and member type, I can actually store the pointer-to-member as a void* alongside the declaration data, and cast it back when I want to use it... at least I hope this works the way I think about it, I'll at least give it a try.

This is not safe.


There is no guarantee that a pointer-to-member is the same size as a regular pointer, which will lead to some interesting results if you cast between them.

#5166610 Memory alignment problem (CPU and GPU)

Posted by swiftcoder on 13 July 2014 - 02:15 PM

Since I 'm using 16 bit normals, should I use another type instead of XMFLOAT4A ? (if yes, which one could I use ?)

XMHALF4, would likely be what you need.

#5165861 counting procedures

Posted by swiftcoder on 09 July 2014 - 11:59 AM

is there maybe some tool that could count how many functions my project count

What's wrong with the tool you are currently using (OllyDbg)?


From your post, it seems like it is counting these for you already.

#5165026 How to draw visible shadow volumes, but through transparent polygons too

Posted by swiftcoder on 06 July 2014 - 06:28 AM

So more dilemma! I want both to use the blocks with depth test, so I can draw shadows on top of them, but also without so I can draw shadows beneath them. Ah... any tips on this?

Yeah, that isn't going to work. You can't have transparent surfaces both casting and receiving shadows with less than one pass per layer.

#5164937 How to draw visible shadow volumes, but through transparent polygons too

Posted by swiftcoder on 05 July 2014 - 03:49 PM

The problem is: even at alpha zero, they're affecting the depth test for my stencil buffer.

Transparent objects shouldn't render depth. Won't the problem go away if you disable depth writes for the crumbling blocks?

#5164740 FBO Questions

Posted by swiftcoder on 04 July 2014 - 08:21 AM

Why can I sample a texture that I'm currently writing to? Is this legal in OpenGL 4.3, or is the behavior undefined?

It is explicitly not disallowed, because there are useful operations in this area (i.e. updating a particle system stored in a texture).


As Ohforf says, reading different pixels than you are writing is asking for trouble.

#5164543 Installer for Linux?

Posted by swiftcoder on 03 July 2014 - 05:40 AM

You also have to keep i mind what the users on a given platform expect from the software installation process.


Windows users are used to GUI installers. Mac users are familiar with standardised installers via Apple's installation tool, but they'd mostly prefer that your software is sold through the App Store, or delivered as a simple zip/diskimage (in that order).


Linux users are used to package managers and raw source code. It drives me up the wall that Eclipse delivers binaries that require a custom shell script to install - if your software isn't delivered by PPA, or in source code form with a working make install, there is a good chance I won't install it.

#5164471 Installer for Linux?

Posted by swiftcoder on 02 July 2014 - 08:44 PM

I'm preeety sure you can just get away with putting your stuff in /usr/share and /usr/bin.

I would hunt you down and kill you if you did that. The contents of /usr are exclusively the province of my package manager, and if you go mucking around in there, you will break something.


Realistically, your two options are to either (a) integrate properly with my package manager, or (b) provide your software as a stand-alone zip/tar archive with no system dependencies.

#5163737 Is there a way to define a front and back texture on a Quad

Posted by swiftcoder on 29 June 2014 - 06:29 PM

Or render 2 different quads at the same location, facing the opposite way to each other (you can even use the same vertices for each, and just wind the indices the opposite way).

#5163619 I've got problems with interviews

Posted by swiftcoder on 29 June 2014 - 07:33 AM

Communication is the most important skill for a programmer on a team to have if they are competent in coding areas.


That's a *big* assumption. A lot of the interview process (particularly phone screens) is to weed out applicants whose technical skills do not match up to their resume.



Testing real algorithm development on computer would be closer to what the candidate would be doing if they join your company, so why not test them that way in addition.


I would assume that any engineer worth their salt can code up a basic algorithm given a suitable IDE. The question in my mind is whether they can whiteboard up an algorithm alongside a team of other engineers.


Any junior engineer should be able to code up a storm, whereas a core function of a senior engineer is to be someone you go to when you need help, and they can grab a whiteboard and walk you through to an optimal solution.

#5163521 I've got problems with interviews

Posted by swiftcoder on 28 June 2014 - 04:59 PM

Being asked how you would detect a loop in a linked list I have been asked twice in interviews. Using a debugger wasn't the right answer ;)

Those questions filter for a basic background in algorithms. If you took a data structures course in university, you probably know the answer to that right off the bat.

Keep in mind that the entire interview process is calibrated around that fact that you can't get to know a person in one hour. Assuming that, then you are left with having to filter for the things you can test for in an hour: the kind of basic CS skills taught at university, the ability to think on your feet when faced with an unfamiliar problem, and the ability to function under pressure.

#5163502 I've got problems with interviews

Posted by swiftcoder on 28 June 2014 - 03:40 PM

Why do employers insist on this way of assessing programmers?

It differentiates engineers from people who only learned to program.

Don't get me wrong, programming is a fine skill, and you can accomplish great things with nothing more. But the majority of employers are looking for software engineers. They need someone who can function on a team, and much of that is having shared vocabulary, design patterns and concepts.

#5163332 Creating an OpenGL context on Windows with Glew.

Posted by swiftcoder on 27 June 2014 - 05:54 PM

The wiki says "A forward compatible context must fully remove deprecated features in the version that it returns;you should never actually use this." It's actually bolded on wiki so I took it at face value. Perhaps the wiki is overzealous. It seems like it would be a good idea to not include deprecated features, however I suppose if somewhere down the line features I'm using became deprecated and I asked for the latest context without deprecated features I would suddenly break my program. That seems like a far out case though.

They are just paraphrasing NVidia's guidelines there. You would expect a Core context to be more efficient, given that all deprecated functionality can be removed, but in some cases a single driver implements both Core and non-Core contexts, and in the Core case, it may have to add a bunch of extra error checking to make sure you don't call non-Core functionality.

I generally recommend that you use a Core context for development, and if you feel it necessary, switch to a non-Core context for release.

#5163214 How to greatly reduce fleet micromanagement?

Posted by swiftcoder on 27 June 2014 - 05:32 AM

I'm a big fan of tech upgrades affecting existing ships - particularly drive technology. There is nothing more annoying than having to dig through the fleet interface to split off that one ship with the lvl 1 drive that is slowing your entire fleet to a crawl.


The alternate solution would be to sharply limit the number of tech levels (say, 3 levels of drive tech only), and space those levels far enough apart that you don't tend to have multiple drive levels overlapping.

#5163099 Creating an OpenGL context on Windows with Glew.

Posted by swiftcoder on 26 June 2014 - 03:41 PM

Your driver reports OpenGL 4.3, *not* 4.2. Try creating a 4.3 context and see what happens.


OpenGL drivers are notoriously picky about version specifications - on my MacBook the drivers require I specify the exact version supported by the driver, not any previous major/minor version.