Jump to content
  • Advertisement

efolkertsma

Member
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

160 Neutral

About efolkertsma

  • Rank
    Newbie

Personal Information

  • Interests
    |programmer|
  1. efolkertsma

    Deferred context rendering

      There is no 'right' or 'wrong' way off the bat. It is depending on your context, and your question is as Hodgman pointed out...      It is unclear to me from your description where your problem is outside of that your procedural calculation takes long and you stall your rendering based on this.   Please clarify.
  2. efolkertsma

    Deferred context rendering

    I am not entirely sure what you mean by 'high quality textures' so for the sake of my explanation I will assume you mean high resolution textures.   My guess is that you are trying to update the texture asynchronously, but synchronized to main thread, on another thread. However if the texture becomes large enough the time it takes to complete is still too long for a frame causing the jerk, or your texture is so large that once you un-map the driver overhead is so high that it jerks there (seems more unlikely, since this is effectively a memcpy from system memory to GPU memory, but you gave limited information.)   In any case if you have any thread synchronization going on (be it the thread calculating the procedural stuff or the render thread waiting for the ready flag to be set) I would start splitting up the update into smaller blocks. Say you have a 4096x4096 texture you need to update with your procedural function then I would map it into chunks of say 128x128 and build a bunch of tasks each doing their own block, running on multiple helper threads (on multi core systems.) This would show intermediate results where some pieces are updated and others aren't.   If it is not an option to show a partially updated texture then I would build a lower resolution (low mip) that you can do within one frame and set the mipmap range to only use the lower one until the higher resolution one is filled in. Once the higher resolution is completed I would up the mipmap level it can use in the sampler desc.   As an alternative to a lower mip I would use the same mip map level, but calculate less samples. Say you calculate a procedural sample every 4 pixels. Then after this, you do a quick pass to 'smear' out that over the remaining pixels. So in effect for the quick version you could calculate 1 pixel in a 4x4 block... then run a post pass that either just duplicates the data or creates a bilinear filtered version or so. Then in subsequent updates you can refine the result... rendering 1 pixel in a 2x2 block, then every pixel. Then generate the lower mips of the higher res.
  3. There is a book called: "Beautiful Code". I have read bits and pieces of it and I think it is a reasonable book.   In any case if I can give one personal piece of advice, based on what I have seen in my career. There is no 'off hand' right or wrong way. Therefore don't try to make up a strict rule set based on the code you read and try to retro fit particular problems into the approaches you have read by other people. Often times a particular situation requires a unique (or at least modified) approach to be good. (There are a lot of opinionated people out there that promote 'their' line of thinking because it worked in their circumstances and therefore it must work in all circumstances, right?!? (e.g. Mike Acton with his data driven development))   Depending on how new you are to programming I would start with smaller scale software and avoid diving into large scale engine such as Unreal, CryTek, etc. Because realistically if you haven't had enough experience on smaller things/first hand, meaning you haven't hit the problems they describe personally... it is very hard to see their architecture and understand fully why they did what they did. For me personally on the code base I work on there are times where I disagree with the architecture... sometimes I am right (as in I have valid arguments that the majority of people I talk to agree with) and sometimes I am wrong (meaning the reverse). (edit, I forgot to add) Often when I am wrong it is because I did not fully understand the set of problems they were trying to solve, or the constraints that were there. So I would avoid trying to form an opinion without understanding the full problem.
  4. efolkertsma

    Obj file loading weird problem

    Good to hear that you resolved your issue. I thought about the material mapping since you had stated that you had some objects come in correctly, which in my mind excluded the UV mapping.   Anyways, here is a reasonable explanation for it http://thedev-log.blogspot.ca/2012/07/texture-coordinates-tutorial-opengl-and.html   TL;DR version: In DirectX top-left is (0,0) in OpenGL bottom-left is (0,0). This has to do with DirectX being more centered around memory -> screen layout (address 0 is top-left) whereas OpenGL is taking the more mathematical approach of x,y axis which means y increases upwards, aka bottom-left is (0,0)
  5. efolkertsma

    Obj file loading weird problem

    If I had to guess it is material mapping.   Usually multi material objs use materials with "usemtl" you had better then use the correct textures defined in the accompanying mtl file.   For example here is a simple cube.obj:   # Blender v2.77 (sub 0) OBJ File: '' # www.blender.org mtllib cube.mtl o Cube v 1.000000 -1.000000 -1.000000 v 1.000000 -1.000000 1.000000 v -1.000000 -1.000000 1.000000 v -1.000000 -1.000000 -1.000000 v 1.000000 1.000000 -0.999999 v 0.999999 1.000000 1.000001 v -1.000000 1.000000 1.000000 v -1.000000 1.000000 -1.000000 vn 0.000000 -1.000000 0.000000 vn 0.000000 1.000000 0.000000 vn 0.000000 -0.000000 1.000000 vn 0.000000 0.000000 -1.000000 vn 1.000000 -0.000000 0.000000 vn -1.000000 -0.000000 -0.000000 usemtl Red s off f 2//1 4//1 1//1 f 8//2 6//2 5//2 f 6//3 3//3 2//3 f 1//4 8//4 5//4 f 2//1 3//1 4//1 f 8//2 7//2 6//2 f 6//3 7//3 3//3 f 1//4 4//4 8//4 usemtl Blue f 5//5 2//5 1//5 f 3//6 8//6 4//6 f 5//5 6//5 2//5 f 3//6 7//6 8//6   Here is its mtl:   # Blender MTL File: 'None' # Material Count: 2   newmtl Blue Ns 96.078431 Ka 1.000000 1.000000 1.000000 Kd 0.000000 0.004612 0.640000 Ks 0.500000 0.500000 0.500000 Ke 0.000000 0.000000 0.000000 Ni 1.000000 d 1.000000 illum 2 map_Kd  blue.tga   newmtl Red Ns 96.078431 Ka 1.000000 1.000000 1.000000 Kd 0.640000 0.000000 0.000630 Ks 0.500000 0.500000 0.500000 Ke 0.000000 0.000000 0.000000 Ni 1.000000 d 1.000000 illum 2 map_Kd  red.tga   So load the appropriate material and texture, don't bind materials in the order the editor assigned them and do not use the order from the file (as you can see obj references Red, Blue; but the material file lists Blue Red)
  6. efolkertsma

    Posibility of getting to game industry?

      Sure thing! And good luck. 
  7. efolkertsma

    Posibility of getting to game industry?

        While I was in university I needed to do an internship, so I went to a smaller game company in the Netherlands, once the internship was done I got a job at the same place. About 2 years in one of the guys I was working with knew a person working here in Canada and he wanted change jobs, so he did. A couple months later he asked me if I wanted to change jobs to, so I went for interviews. I then later asked another guy, but he failed the interviews.   At that time I had very little (1-2 years) experience and the company wanted some re-assurance that it was worth to move me over. So they flew me in and I had about 16 hours of on-site interviews, over the course of 2 days, for various different teams. Ranging from graphics to low level technology such as memory manager, file systems, etc. Mostly white boarding and the like. I was not too picky on what to work on, I just wanted to 'get in'... and luckily for me they accepted me. So I moved to Canada in 2007.           Well having a good portfolio and sending that out gets you noticed. You shouldn't be too picky and just literally send your resume to a lot of companies... A LOT of people are hiring because there is always a shortage on good programmers.     Once you get the phone interview (which usually happens before they fly you in for interviews.) you will have to know some 'on the spot' things (what does virtual do, what's the size of a long, what's a template, etc, simple stuff.) and it is not about white boarding. Usually questions on the phone go over what you have done (education, work project, hobby projects) and then some more technological simple stuff... usually related to what you worked on. So if your hobby project is rendering a voxel world or so then likely you will get questions about 'how did you make the drawing efficient -> spatial partioning/batching, etc. If your hobby project was a physics engine then you will be asked about iterative solvers, some basic math, etc. If you have great hobby projects then this will certainly make you 'stand out' because it means you are passionate about it. And as you pointed out... a lot of people are tired after work, so knowing that even after that a candidate still had passion to do something means a lot (for me personally it means more than the jobs they have held or the previous work they have done, mostly because a lot of people 'polish' their resume to look a lot better than they are, and it is a lot more difficult to fake a portfolio piece.)   Sometimes after the phone interview you get an 'assignment' where they expect you to do some test in your own time (usually 10-20 hours of work.) This ranges from making a small game like space invaders, to solving travelling sales man problem in an NP-complete situation (so we can see your creative approach), to writing a software 'rasterizer' for a particular data set. The main purpose of this is to see code quality/style.   Once you get an in studio interview you should be prepared for many questions along the ACM/Geeks for Geeks thing. I know we do it, we have a partly standardized test and some improvisational questions. Be cautious though, we usually easily pick out the people who 'memorized' solutions and that rates you worse than if you struggle to do the test and finish it half way.    So long story short. From my experience portfolio gets you 'noticed'/'invited', programming skills like ACM/Geeks for Geeks gets you 'hired'. But this is my opinion, so I wouldn't take it as 'the rule'   PS: For me I built a couple of things to get noticed. One was a simple 3D terrain editor with undo/redo, texture painting, height map painting, etc. Another was a simple physics engine, iterative solver, but did things like box-stacking. Then for my first job for the small company I did a terrain engine, with 3 other people, which was never released on PS3.   PS2: If you want you can send me a link to your portfolio and I can give some feedback.
  8. efolkertsma

    Posibility of getting to game industry?

    I will try to answer some of your questions:   But before that, you should really consider whether you like to make games, or technology that allows games to be made. For example in the company that I work my job does not deal directly with 'game' programming as such, but we deal with a lot of technology to enable good games to be made.   1) I can't really speak to question 1, because honestly my environment wasn't all that rough. But my experience has been that your back ground is no-where near as important as your ability to actually program. Now I understand that you're tired after a day of work, but most people go through that... so your passion will have to carry you through that.   2) The type of company depends on what you want. If you're in a larger company, working on AAA titles, you will likely be working on a smaller piece... and in this case C++ is usually the main language for development of tech, and C# for tools. If you're going for an indie company, then I believe most use C# and something like Unity is just amazing to work with. It is fun, it is fast iterating, all the ground work is done (rendering, physics, input, audio, animation, etc.) + the asset store has many good quality assets.   3) Mid 20s are actually perfect. Lots of young people around. In fact you are likely to be most flexible while you're young (don't have a family), because likely you will relocate (I moved from the Netherlands to Canada for example.) And that's just easier to do when your significant other does not have to quit their job & leave their family behind.   All in all my experience to get a job in the industry has been that you don't have to be an exceptional programmer (in the larger companies), but you just have to be reasonably good... meaning you have to be able to stand in front of a white board / do an online interview on a notepad of some sort. It helps if you know someone in a company you want to work, because there are a lot of resumes being sent in and before it reaches the programmers HR or so has already filtered out a lot of the resumes.   I think a good measurement stick would be things like ACM programming contests, not necessarily they world contests, but just the questions (they have an archive). Or if you go to GeeksForGeeks they have a bunch of good problems. If you manage to do those (and I don't mean study them and then perform them, but I mean if you see them for the first time and you can do them.) I would say at that point you already stick out above most of the people I have personally interviewed.   All in all, determine what you want and pursue that dream... you will get there if you work for it.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!