Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Jun 2006
Offline Last Active Yesterday, 11:16 AM

Posts I've Made

In Topic: Difference between Framework and Engine

15 June 2016 - 02:36 AM

I'm going to side with Sean on this -- framework is something you build on top of, engine is something you work inside of.


The distinction is kind of like whether you write the "int main()" or not...


"when i'm interviewing, I'll wanted to show my "engine/framework","


No. You'll be wanting to show a working game. Every tom, dick and harry shows up with bits of code they call an "engine". Finish an actual game instead.

In Topic: Pros/Cons of coding alternatives to std::algorithm?

10 June 2016 - 03:53 AM

"I always felt like it's probably a bad practice to do so."


It's not if it does the job. I get to say it again; You don't need code to run as fast as possible -- you only need fast enough


Build it using the BIGGEST tools you can find -- the less work you have to do the sooner you can get a project done, profile it, then replace only the sections that mean you're not hitting your target.


Your goal is a completed project, not a tiny section of very-very-very-very spiffy code.

In Topic: Computing Matrices on the GPU

10 June 2016 - 03:45 AM

"But wouldn't this mean two texture accesses (normal and position texture) plus matrix construction per vertex thread? "


Yes. But it'll probably end up living in cache and it's saving an entire rendering setup sequence -- it's one less program binding & execution along with all the GPU management overhead that contains.


It's also simpler, so it gets you running and (as kalle_h says) profiling faster.


GPUs are insanely fast -- particularly vertex programmes. It's really quite hard to saturate the vertex side before you're saturating the pixel side.


And you don't need code to run as fast as possible -- you only need fast enough. Fixating on being the besty-best-bestest-best-best instead of "good enough for what you need" is what kills amateur projects.

In Topic: Computing Matrices on the GPU

08 June 2016 - 06:04 AM

Why not compute the matrices in the vertex shader of whatever you're rendering with the set of them?


Pass (handwaving) a matrix number as a vertex attribute and use that to create the MVP needed to transform the vertex.


Most recent hardware can access textures in the vertex shader -- there's a value to read to see if its possible on the hardware in play.

In Topic: Particles form a shape/letter/object

26 April 2016 - 03:48 AM

The cheap way is; Start with the particles where you want them to end up. Design your "physics" that will disperse them and invert it; run it backwards. If your particles run in from a random offscreen location, you give each a random vector and start them 500x that vector away as if you'd scattered them FROM their final pattern. Then just wind that physics backwards... at 0x, they'll all be in their final position.