stevenmarky

Members
  • Content count

    726
  • Joined

  • Last visited

Community Reputation

369 Neutral

About stevenmarky

  • Rank
    Advanced Member
  1. don't get too comfortable

      Yes, it will. A few I could think of:   Normal mapped lighting doesn't work well in VR, because with stereo vision you can see the surface is flat. Tricks like always drawing users weapons/hands over all geometry (e.g. Half Life 2) are horrible in VR. Maintaining a consistently high FPS (90+) is of very high priority. Anyway, In general I'm a big fan of VR. It really opens up a lot of possibilities. Feeling like you're there (to an extent) really changes the feeling of a game. Enemies I wouldn't have thought intimidating suddenly are, eye contact evokes a reaction, exploring is suddenly interesting and so on. I'm expecting to see some really interesting games/demos over the next two years (although I have no doubts it will remain niche in that time).
  2. [UNITY] Problem with 2d colliders in unity game.

    This could be because the arrow is traveling so fast it's going entirely through the rock in a single frame. It depends how fast the arrow is traveling and the size of the colliders. I'd advise making the arrow slow to eliminate that possibility first.   Two other things I noticed: You have a 2D collider on the rock - does the arrow also have a 2d collider? I'm not sure if 2D/3D colliders are compatible. There's a warning on the game object you've selected (in the first screenshot) about the collider, that might also be the reason.
  3. T4 Code Generation in Unity

    This is interesting, I actually wrote an editor script a while ago which generates a C# file containing an enum list from a certain type of file resource, so if those resource files are ever removed we'd get compilation errors instead of waiting for a runtime error. What advantage would using T4 code generation have over manually writing a C# file?
  4. You're asking difficult questions...you might get more answers if you are able to break it up into separate problems and focus on one at a time.   I haven't fully analyzed what you are saying above, and I haven't fully analyzed your code but I have the feeling that you're making an incorrect assumption somewhere. I don't have a specific answer but I have some guesses and some more general advice.   This sounds strange to me...if you are using Daikon forge and if it is similar to NGUI then when you use a 'fixed size' it's actually just means that it's using a constant 'virtual' pixel height, but the width of the screen is free to change. If so and your problem boils down to converting screen pixels to those 'virtual' pixels all you need to is something like:      float pixelPositionToVirtualPosition(float f)     {         return f * (virtualScreenHeight/Screen.Height);     } This will convert a screen pixel position into a NGUI position, and you can also write a function to do the reverse.   When you say something like this:     or this:     It makes me think that you're developing using trial and error. If you've thought logically about how the object should be positioned (could help to test the equations on paper first), and it doesn't end up where you think it should then you need to find out why before trying another solution. Use Debug.Log or print statements, or the debugger. Use divide and conquer to find the point at which your code is breaking down, then fix it.
  5. Billboard issue in front of 3D object

    With shaders you might be able to change the depth testing offset factor (see http://docs.unity3d.com/Documentation/Components/SL-CullAndDepth.html ) of the scenery to 0 - if I'm understanding the documentation properly this would make the scenery all screen facing in terms of depth, but I'm not sure if it would introduce any other problems.
  6. Billboard issue in front of 3D object

    That's an interesting problem.   My first thought would be to not use full camera facing billboards, instead use normal quads that are orthogonal to the ground and put the texture on there. You'd still want them to billboard on the y axis however. The side effect of this would be that the sprites would look shortened vertically when viewing from above, so to compensate for that you'd have to stretch the quads vertically dependent on the camera angle. I can't think of any reasons immediately why this wouldn't work, and it seems preferable to messing with shaders.   I will elaborate if it's not clear what I'm saying.
  7. Haskell kicking my Asskell

    The problem is "post xor mask" on line 7.   It should be "xor post mask" because the function comes first (unless it's an infix operator).   You can still use it as infix with special syntax: "post `xor` mask"
  8. Job Interviews

    Good luck Mike.
  9. Welcome To The New Gamedev.Net!

    My main criticism is that stylistic elements (e.g. on the main page) take up a lot of space. In particular the headers of each content block is 74 pixels - which takes up a lot of space. I also feel there's something strange about having a border around the main content area which is white, which is then surrounded by more whiteness. On the main page I'd prefer the recent posts were closer to the top of the page. I'm not sure if you've analysed where most of the clicks lead to on your main page but I imagine a lot come from the recent posts. Anyway, good job. I'll also submit these points to feedback
  10. thanks gamedev.net

    Welcome to gamedev.net!
  11. Programming logistics

    Maybe you'll find this pattern interesting Gravy, it is called component and it is frequently used: http://gameprogrammingpatterns.com/component.html
  12. Programming logistics

    There are design patterns, but I don't think there's any as high level as you are thinking. Quote:I'm making a RPG. Well heres a general and practical approach to doing that RPGs are so varied that there's only a small amount of things that we could describe in general. For example is there a general approach to doing movement in an RPG? Well movement could be tile-based, or pixel based, or our RPG could be 3d. or it could be isometric 2d, and it could require data sending to a server each time we move, and there might be entities we collide with, or there might not, and there could be traps, or triggers that happen when we walk in certain spots, or the movement should be able to be scripted from another language or...and so on. Each requirement a specific game has will result in a different approach.
  13. Programming logistics

    I'll have a stab at answering your other questions: Quote:Do you try to modularize is as much as you can so you can reuse as much code as possible? In general, splitting things up into well defined components is good design. However when you ask this question I get the idea you're splitting things up into tiny fragments in the hope they will be used again at some distant point in the future. Be pragmatic and consider the benefits and cost of making things reusable. For example - if you're writing a small game is it important to separate the game logic from any engine calls? Not really. Quote:where would you put the variable "Score" in your game? Without any more information, in the game class. Quote:how do you handle saving the game state? If you have a class that contains all variables that encompass the games state all you need to do is make a copy of it. Quote:Do you use a player object to keep track of what the player does? If it's a requirement to keep track of what players do, then this sounds like a good idea. Hard to answer without knowing exactly what you are asking. I might make copy of the player object, and associate it with a timestamp.
  14. Programming logistics

    Hi Gravy. Quote: I don’t know what else to call it, when you’re trying to figure out how to program your program, other than programming logistics. My question is how you guys figure out where to put you code. In the text editor or IDE! Quote: lol, man you guys completely misunderstood my question. It's because your question is not concise and it's easy to interpret it in different ways, and actually seems to be a few questions: How can I avoid rewriting my code? How can I write things in the least amount of lines possible? How do you generally go about engineering a good solution to a problem? How can I avoid rewriting my code? Short Answer: Planning, and foresight. Longer Answer: If all your requirements are known to you at the start of the project, rewriting should be minimal although some level of refactoring is natural. It's usually changing requirements and additional requirements that cause rewrites. While planning break it down into well-defined components that interact. Experience helps here- this is something you will get better at over time. How can I write things in the least amount of lines possible? I'd like to think that a system that has been properly split into well defined components naturally lends itself to being concise. Apart from that, just being smart. Note that writing things in the least amount of lines isn't always the best thing - it could reduce maintainability. How do you generally go about engineering a good solution to a problem? I think rip-off answered this well (rated). [Edited by - stevenmarky on December 21, 2010 7:32:02 AM]
  15. Dialogue Boxes! - in C++

    I suggest trying out Visual Studio Express. It's free and you'll be able to follow along with your book. I'm sure you could manually type your resource file in Code Blocks, or even find a plugin that provides you with a WYSIWYG dialog editor, but what's the point of going through that extra trouble?