reloadead

Members
  • Content count

    334
  • Joined

  • Last visited

Community Reputation

1795 Excellent

About reloadead

  • Rank
    Member

Personal Information

  1. You store your data in an array. Did you also take into account that the indices in the obj file format starts at 1 and in arrays it starts at 0?
  2. Scrolling background logic?

    It depends on your purpose.   Your typewriter example is a possible solution. You start with a given sequence and once it reaches the end, you start with the first one again. The advantage is that it is pretty straight forward, but could become repetitive.   You can also have a pool of different segments that get randomly spawned at the end of the last segment. It can create a more diverse feeling, but it can potentially be more work because you do want them to connect visually. This approach would be more semi procedural in a way.   Or perhaps a bit of both worlds: Have a basic background scroll and spawn various background objects based on whatever factor you want.
  3. I remember someone else tried this a while back. It eventually failed due to too few people being active (even though it seemed active enough to me). I'm guessing this is not the same one? Or is it?
  4. Water texturing of caustics effects

      Polygons. I simply animated a gradient for the "flicker" effect and added a distance falloff.    I did play around with a post processing effect for the god rays, but due to the openness of the scene (and at that time, my lack of deeper knowledge about it) and control of the effect I decided to stick to polygons.   https://www.youtube.com/watch?v=g6qWhylScsk
  5. Water texturing of caustics effects

    Nice! :)   Back in college we had to do a "specialization" course where we would focus on a field in programming we were interested in. As I am really fond of graphics and special effects, I chose to do some underwater effects, including caustics. The catch behind it was to make it look accurate, but with "fake" (or at least, non physics based) implementations.   I didn't put as much effort in it as I would've wanted to, but in the end it was alright. Your Unity implementation reminded me of this project because I used the same software to create the caustics. :)   https://www.youtube.com/watch?v=T1GcGWrQX3c
  6. OpenGL vs DirectX

    In regards to game development, it really doesn't matter. As you might have already figured out yourself, they're graphic APIs and you can reach the same goal when properly using either of them.   If you really want to do some game programming, I would suggest using an existing framework/engine (SDL, SFML, OGRE3D or Horde3D come to mind). These engines/frameworks take away all (or most) of your worries and you can just focus on the game aspect. If you really want to have a full fledged game engine you can use Unreal Engine. I'm not sure why you are keen on sticking to C++, but Unity3D is also a nice option.   Now if you want to make something completely from scratch (which I would not recommend if it's a game you want to make), then it really doesn't matter. The only real deal breaker for DirectX is if you are not developing on/for a windows machine. Other than that, just pick one that peaks your interest the most.
  7. Portfolio feedback

      I get your point and I understand your reasoning. I also wouldn't say it's a bad thing to show you understand the (basic) principles of design and/or art, but (and I do note this is personal) I do think it's better suited to emphasis your programming skills on a project basis and add the minor (art/design) parts to it. Kind of the same way you already did for Sir Lance Alot. For things like art I would just create a single page with all the relevant stuff you want to show if you can't tie it in with an existing project.   Now I can't speak for every company, but most of them will surely focus their search (or list openings) for a specific role and everything you can bring to the team as an extra, is just that, a nice extra. Even small teams need to focus their efforts in the specifics. You can always bring up your extra skills at an interview and you can also always mention it in your motivation letter.   I did my internship at a company with 3 people and while they welcomed a diverse skill set, it was the programming that got me in (and the fact that I know how to program shaders) :)
  8. Portfolio feedback

    Here are a few things that come to mind (personally) when checking out your portfolio:   Stick to what you want: Your first line mentions gameplay programming. Alright, second line is prototyping; that's still related to programming, but a different aspect. When suddenly we got art related stuff.. While I get what you're going at, It's probably not that necessary to put stuff in your portfolio that you (as you mention yourself) are not really interested in. Instead, if you really want to mention it, add it to the specific project. I'm pretty sure the people viewing your site will know what gameplay programming is. (or any of the other descriptions really), I would simply rephrase those lines and mention what you learned on that specific subject in the project. Flesh our your projects a bit more and keep it consistent: You're using "challenges", "coding challenges and "problems" for the same foldout. Stick to one thing unless it's really something different. You have a couple of group projects in there, list what you contributed to that project. (pair it up with what you learned) Back up any claims you are making: "In unity, listening to each key press is best done within the OnGui() method". Why? Show meaningful code: You're mentioning that you are validating the key press in Not Fish, yet you don't show how. You're only showing me you can use an if statement in that particular snippit. Show code! In your Fiery Core project you only mention 2 random generation types, explain what you did. Show code! (or in a case of blueprint, show your logic!) Don't leave code out. In your Sir Lance Alot snippits you're using //Code... comments. I'm not sure if you're omitting code (which you shouldn't) or that you are placing comments that have no meaning at all. That's all that came to mind quickly, the above mentioned stuff is also valid, so no need to state it twice. :)   Good luck! :)
  9. Next to what is already stated above, your reasoning will likely also aid us in helping you find a proper answer, so do take your time to explain, not only will this make it easier for us to aid you, but to also give you decent advice on related topics or even give you some better sources.   Also, don't limit yourself to just 1 reference, get multiple sources, study them and (try to) understand their reasoning for choosing whatever solution they implemented and how they implemented it. It doesn't matter if it's done in Unity, plain OpenGL, DirectX or whatever engine or framework. What matters is you understand the underlying algorithm so you can implement it in your own engine/framework or existing software.   It's also worth noting that the 2 links above apparently focus on 2 different aspects of the ocean rendering. Where Eric Bruneton is apparently focusing on the lighting model, the Unity port initially just focused on getting the ocean "feel".    With all this in mind, it will probably already help a lot if you simply state your goal, what are you trying to achieve?   And to finally also give an answer to your question: I would keep both and keep searching for more references.
  10. DigiPen: The Game School I Went To

    You should probably submit this as an article. :)
  11. What part of "shaders" are you trying to grasp? If you made vertex/fragment shaders in Unity3D, you (should) already have a solid understanding on the basic principles. If you want to know how to compile your own shaders, bind them or pass parameters, etc. You will need to look into the graphics API you're using.   If it really is about the shader, try reading through the CG Tutorial. While the CG language is not supported anymore, the general syntax is still pretty much on par with GLSL and HLSL, you can also easily look up HLSL and/or GLSL tutorials, just google it.   If you're looking for the entire package. When I was in college, one of our teachers made a site with some good tutorials/references on both OpenGL and DirectX implementations and shaders which might be a good place to start: http://www.3dgep.com/
  12. Lightmapping

      Working in a company that mainly aims mobile devices, I can say that light maps are still being used at our place. (working with Unity)
  13. GLSL/shader Tutorials?

    Just go through it step by step, once you get to know how to make some basic shaders (and move on to some advanced stuff), you'll start to figure out how they work.   For things like blurs, you probably want to look up Post Processing effects.
  14. Unity Code design/architecture

    Thanks for the suggestions and tips so far!   Yeah I think the most obvious way thing to do is proper communication. There's certainly room from my side when it comes to communication, especially discussing design choices before actually implementing them.   Reviews are something we're already doing, but I have to admit that as of our latest project it has not been followed as strict as it could/should. Though I think I will have to go after that a bit more myself.   Luckily, this is not the case. We have coding guidelines we should be following (and actively try to remind others who do not follow them).   I think reading up on design patterns is certainly something I could and should do. I did have to read up on the during college, but I must admit that it became rather rusty.
  15. Hey guys,   Recently I got my 1 year evaluation at the company I am working at and got some feedback from colleagues about my performance and such as a programmer. The main thing that could be concluded from this (which to me, wasn't that big of a surprise) was that the architecture/design of my code could be improved.   From the feedback provided it was more of a general thing. Odd choices on proper ownership and when/where to execute closely relevant code (for example initiating a death sequence from a separate health class instead of a dedicated class). Anticipating the general architecture/design of project so I don't need to refactor (certain parts of) systems already in place.   I've already had some short talks with others about this subject and it boils down to a couple of things: proper communication in general about the project on where everyone is heading. Discussing made choices with others to see if they have valuable (better) suggestions on design choices and time. With time I mean that most others also said that learning architecture will improve over time when you get more insight of different projects and face certain problems.   Now I really want to get better at this and not just for the companies sake, but also because I simply want to be the best I can be. Some of the lacking parts I mentioned above are being worked on, but I would like to broaden my horizon a bit more and for that I come to ask help of others! I did a little bit of research and it mostly boils down to: Write code and learn from it! This is something I am doing in my everyday job. I would love to know how others improved their design/architecture of their projects. Any literature/websites or general suggestions/pointers are very welcome!   TL;DR I'm trying to improve my code design/architecture where several persons are involved in the project and would love any suggestions. Doing this so far: Discuss with colleagues Write code Review code (Both looking at others as getting my own reviewed) Thanks in advance! :)   P.S. We're working with Unity3D and C# if that helps.