Posted by dpadam450
on 11 November 2011 - 12:55 AM
[Mod edit: fire is not fought with fire around here, kthxbai.]
i know how to map uv to verts....
That is what you are asking right? How to map your verts into a UV space. My suggestion was walk the edges:
Your edge idea would be very simple if you made it a rectangle instead of 2 triangles, then you just start with 1 vert and loop around using the edges and just start with uv = 0,0, take the next connected edge vertex and set uv=1,0, from there check the next connected vertex and set uv = 1,1
you do not understand the basic concept that i want to do everything myself
Well if you want to do EVERYTHING then why not write an OS to program your flight sim on. Instead of using opengl/directx why not write your own interface? So to some degree you have to realize you cant do everything. And if you have never unwrapped a 3D model in another tool, then programming your own is going to be hard. Seriously your not going to use photoshop or MSpaint? I think you actually are 14 by the way you act and that your game is never going to be made, let alone sold because your textures will never get built to a professional game standard.
If you want a realistic answer then to "How do I write my own unwrap tool" then you can start with basic projection. Take your 4 points, and run them through your modelviewprojection matrix to get the actual pixels values of your vertices. So view from the top down, compute the vertices to pixels and then you can put them in UV space.
1.) your an asshole and I won't try to help you after this because 1: Everyone uses these tools, you are not cool for making your own, and its going to take you years to complete your game at this rate of "DO EVERYTHING IM THE BEST I PROGRAM WHEN I WAS 14 IM EINSTEIN". 2.) The fact is, you don't know what you are getting into because of this statement:
Actually i can select verts and then change their tex coords manually but its a stupid approach
EVERYONE in any application ever built to UV map, has to manually edit texture coordinates. Your whole ship doesn't just go into a 3D function and magically map to something useable. You still have to manually manipulate them. You have to make seams, pin vertices in UV space, move them, fill in your space properly. UV unwrapping is an art skill. It takes some time.
Posted by dpadam450
on 09 November 2011 - 01:48 AM
Reverse Engineering - Nope, not for games anyway. Never been asked in an interview.
Attracting People to you Resume - Get a website (free is fine) put up your work. Any games, youtube videos of your games/programming work. It has worked well for me. Secondly, 5% of companies recruit, the other 95% wait for people to apply directly to their company online. You have to go to them.
Posted by dpadam450
on 09 November 2011 - 01:03 AM
No I said to make a game you don't need to know much C++ at all. You hardly need to know the ins/outs of any language to code a game. If he wants to be a professional c++ developer in games or elsewhere, then of course what I said would make me look dumb. I said to make games, you strictly can do it in any language without knowing more than a bit of the language. That doesn't mean your code will be buggy. Writing buggy code is writing buggy code, doesn't matter how sophisticated the design or algorithm is.
If game making was as easy as, A=B ++ and B = C then C = ++(A) and I got an MMORPG on my hands, then by gah companies have been doing it wrong for years.
Well no, but if this person wants to start writing games, he doesn't need to read advanced c++ for software engineering, rather just start learning to make games and focus on the games. Learning c++ at a professional level usually takes some college or serious dedication at looking at boring code. The focus at a beginner level should not be "I want to get hired to make an MMO at Arena Net in 6 months after reading a book". It should be to take baby steps and apply those to making small games. Again I said "at the core" thats all he needs to worry about at this point.
What about pointers, address, garbage collections, functions, api, hooks, drawing, math, formulas, modules, direct3d, directx for that matter, model manipulations, instances, networking, controllers, options, SDL, XNA... that must all be variable manipulations also.
You can make a game without pointers. Key word can, at least to start with. You are going to write crap code to begin with, we all did at some point. How can you know how to write good code without experience. I remember my first text based game, all 1 cpp file, no pointers, tons of if statements to check what room I was in. I don't even think I had implemented a Class yet at that point.
Thats my opinion, hes never coded, and your telling him he needs to immediately know and focus on becoming a master at c++. You need to start somewhere. The original poster asked about c++ and someone said: "C++ is too advanced" , it can be if you want to be advanced at c++. Everyone portrays the other myth that c++ is immediately impossible to learn as soon as I open up page 1 of a c++ book. Thats all I'm saying. I know you contribute a lot to this community but your talking about this guy writing perfect flawless software without ever having written a single line of code?
One you know how to make a games, the language won't matter so much.
This guy has the idea. Learn how coding works, pick any language you want.
Posted by dpadam450
on 08 November 2011 - 01:25 PM
C++ is not a good candidate for starting out since you'll have to keep a lot of things in mind which keep you away from the actual programming part
Don't believe this. You only need to know very very little c++ or any language for that matter, to actually write a game. At the core all you need to know is how to make and manipulate variables. The first 20-30 pages of a c++ book is all you need to know really to make anything. Game development is not c++, common misconception in my opinion. Not enough material covers game development.
Posted by dpadam450
on 04 November 2011 - 02:06 PM
Returning void is perfectly fine. If there is nothing to return there is nothing to return. They are most likely saying return at least a boolean to say true or false, if the function actually worked correctly. Sometimes you have early breaks in functions such as checking for null and returning early so it does not crash.
Was going to say something like that as well just put them into buckets. Since its terrain, if its a grid all verts will share an x and y with several other verts. Make an array that holds number of vertex rows/columns. Plop a single vertex pointer into those slots, if a slot is already filled then delete it and connect your edges to the vertex already in the bucket.
I would probably say no to separating the used morph verts and unused? It depends on how many verts we are talking about. Do you want to change your normal,vert,tex coord pointers, and shader to the non-morphed portion of your model and send another draw call? Thats 5 or more openGL calls you will have to make. Unless this model is a million verts and most are not used, I would probably say just do the extra morph and shader on the static vertices. If your static verts are 1-2,000 then your very close to, or better to just draw them than to make 5 GL calls most likely.
What you are doing is basically networking a real time strategy architecture with a fps style game. If there are only so many players and you control one of them, you can get away with just sending updates of the players position as what is suggested.
So you can either validate, and then continue sending movement updates every 15ms. Or you can validate movement while you receive them instead of up front. If you get a movement command, check the current tile the player is now on, if it is invalid then send a stop command and move them back or something.