NypyrenMember Since 19 Aug 2002
Offline Last Active Today, 12:47 AM
- Group Crossbones+
- Active Posts 4,235
- Profile Views 11,455
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Eugene, OR, USA
C#, F#, x86-64, Developer Tools
Posted by Nypyren on 17 January 2016 - 07:46 PM
C6A708h is your EXE/DLL's _tls_index (the stored TlsAlloc return value that the startup code (MSVCRT?) reserved for your EXE/DLL's thread local storage index. It allows EXEs and the DLLs to know where their own dedicated area of the TLS is.)
ecx = fs:[2Ch] is the Win32-specific way to get the thread's TLS pointer.
edx = [ecx+eax*4] is looking up your EXE/DLL-specific area of thread local storage using the _tls_index.
[edx+104h] is accessing a member of the structure it points at. The constant offset is determined at link time - each thread static gets a different constant. The earlier use of _tls_index is what allows this to be constant.
C6A1E0h is the address of a variable indicating whether it has performed initialization yet or not.
I'm not familiar with the __Init_thread_header/footer functions.
C6A1DCh is the address of your actual static variable.
Posted by Nypyren on 14 January 2016 - 03:19 PM
In general, you should:
Keep applying, but EXPECT almost all of them to reject you. For internships it's mainly just a numbers game - you versus the thousands of other people looking for a summer internship. Even big companies probably can only have a handful of interns at a time. For full time jobs, it will be entirely about qualifications and whether they like your personality.
Work on your own projects while you wait for responses. List them on your resume when applicable.
Search for local get-togethers of software developers. Talk to everyone there. This is how I got my foot in the door after college (I never actually got an internship).
Talk with your friends at school.
Universities often have people dedicated to helping you out with contacting employers and other Internship/job-hunting strategies. Find them and talk about it with them.
Don't get depressed. This is the thing that was hardest for me. Even though it can sometimes feel like it takes forever to find a job, everyone eventually makes it as long as they keep trying. It's only over if YOU give up.
Have a backup plan to survive. I worked at a temp agency over the summers, doing things like installing floor tiles, moving furniture, loading trucks, delivering soda, working on assembly lines, etc. This gave me time to save money and pay rent while looking for a "real" job. Temp agencies will hire pretty much anyone who aren't physically handicapped. The pay was OK and it was REALLY easy, and I didn't have to deal with customers. DON'T list these jobs on your resume since they have nothing to do with programming.
Posted by Nypyren on 14 January 2016 - 01:49 PM
If you imagine your two vertices are a model, your 0,0,0 is the "center" of the model and isn't changed by scaling.
The 0,0,0 point stays at 0,0,0 no matter how much you scale it, and then moves exactly by your translation amount.
The 1,1,1 point first moves to a point equal to the scaling (x,y,z), and then has the translation added to the result.
Therefore, translation controls your 0,0,0 point's final location and scaling only controls the 1,1,1 point's location relative to wherever your 0,0,0 point is.
Point A = 0,0,0
Point A transformed = (0,0,0) * (scaling) + (translation)
// (0,0,0) * scaling = (0,0,0), so this simplifies to:
Point A transformed = (0,0,0) + (translation)
Point A transformed = (translation)
Point B = 1,1,1
Point B transformed = (1,1,1) * (scaling) + (translation)
// (1,1,1) * scaling = scaling, so this simplifies to:
Point B transformed = (scaling) + (translation)
So this means you can control the exact location by using:
Point A transformed = Desired point A location
Point B transformed = Desired point B location
Desired point A location = translation
Desired point B location = (scaling) + (translation)
Subtracting translation from both sides:
Desired point B location - (translation) = (scaling)
Desired point B location - Desired point A location = scaling
Posted by Nypyren on 11 January 2016 - 07:56 PM
If the other three vertices are coplanar (well, they're always coplanar, just make sure they're not degenerate into a point or line anyway) get the normal of the plane they lie on.
Take any edge from one base vertex to the top vertex and project that line onto the plane normal.
Take the magnitude of the resulting line.
Simplify and remove the unused portions of the calculation (i.e. the whole projected vector isn't needed, just the magnitude).
There are likely much simpler ways to do this that I don't know about since I'm not a math person, but that's an intuitive geometric way of going about it.
It seems like you could give a valid answer for the degenerate cases (all three base vertices at the same location | all base vertices collinear) as well:
- Point case: return the distance between top and any base vertex.
- Line case: solve the 3D problem the same way in 2D, just without the degenerate vertex (you can project along the base line and then subtract that from the top-base vector to get the vector along the "normal").
- If top is the same as any other vertex, return 0.
Posted by Nypyren on 11 January 2016 - 06:08 PM
It's extremely important to know how Dispatcher.Invoke works all by itself, in case you want to do cross-thread stuff without a timer.
Posted by Nypyren on 11 January 2016 - 03:14 PM
Posted by Nypyren on 08 January 2016 - 07:53 PM
Unfortunately you have to declare the register reserved at all times, by everyone, which requires that all compilers and people coding directly in assembly know about it.
Posted by Nypyren on 08 January 2016 - 02:52 PM
...it's going to take a lot of time to learn and it's pretty hard.
Well, yes. People invest time and money in *themselves* so that they can fulfill their ambitions.
What do you want to do for a job?
What do you want to do for a hobby?
If neither of those things involves hard work, then you're not going to fulfill ambitious goals. That's just how life works.
Your best hope is to find the fun in a challenge, and let that feeling drive you.
Posted by Nypyren on 07 January 2016 - 10:15 PM
When you have VLA's... you can still reserve fixed locations for fixed size stuff, but a VLA wrecks the compiler's knowledge of anything on the stack afterwards, and you can no longer optimize out the frame pointer (since the stack pointer now has an offset from the frame pointer that can't be known at compile time). When you index a VLA, the compiler has to make a dereference relative to the start of the VLA. Since the stack almost always grows towards negative addresses, this means the start offset (even for the single-VLA case) is dynamic and has to be stored somewhere. The obvious implementation counts the number of VLAs a function uses and reserves extra fixed-position pointers on the stack to keep track of where the VLAs end up. It can deterministically figure out the position of *one* VLA the same way that normal frame pointer omission works, but after the first you need to have pointers. Manipulating any VLAs after the first then requires additional loading of those pointers off the stack or keeping them in registers (as opposed to the optimal method of baking the offsets into operands), leading to an extra dereference and more register thrash (which is worse since you're also forced to keep your frame pointer).
Static analyzers that warn you about array indices being out of range have two dynamic things to track (dynamic length, dynamic index) instead of one (static length, dynamic index).
It's pretty gross and leads to a bunch of extra instructions to deal with it. I avoid VLAs and alloca at all costs.
Posted by Nypyren on 06 January 2016 - 09:30 PM
Then, why do they say Python, if nearly no one even uses it for production games? At what point do I stop with Python and switch over to something more complex (C or C++)?
Learning programming languages is MUCH easier than learning a new natural language like Japanese or English. Most programming languages have VERY few rules to remember, and almost no exceptional cases to memorize. IDEs and compilers can quickly tell you when you're wrong and often suggest fixes. They're designed to avoid the stupid inconsistencies that natural languages have. They are all based off of the same core ideas, and this makes it very easy to switch once programming "clicks" for you.
Recommending Python instead of C++ is based out of complications specific to C++. When you learn C++, there are a lot more occasions where you be on a roll, learning something, and then a tedious detail of C++ (usually a compile/link/template issue) rudely interrupts your train of learning. This doesn't happen as often with languages like Python or C#, which is why lots of people recommend starting with those languages. It's easier to learn if you don't have to stop and fight with the language.
Different languages come into favor or fade into twilight over time. COBOL used to be a Pretty Big Deal, Way Back When. You don't hear about it much lately. Luckily, unless you plan on being a full-time professional programmer, you don't have to invest "all-in" with any single language. Most of your knowledge will lie not in the language details but in the *strategies* you use when you convert your ideas to code. It's like ordering a hamburger in English or Japanese. Once you know what to do, actually doing it is the easy part. This makes it easier to adopt different ones as time pass.
Posted by Nypyren on 05 January 2016 - 06:07 PM
Posted by Nypyren on 31 December 2015 - 12:51 PM
Posted by Nypyren on 20 December 2015 - 08:14 PM
The process I'm aware of works like this:
- Your device calls an API which "registers" the device (which gives you a unique ID for your device). This is where you do your native Unity plugin programming.
- You record that ID on your servers, associated with whatever ID you're using to identify your players.
- When a second player wants to send a notification to a user, they send a request to your server.
- Your server maps the player ID to the device ID(s) that that player has registered with, then contacts the Apple/Google/Amazon/Microsoft notification service to send the message through.
- The receiving device uses the OS's own polling mechanism to receive the notification.
- The user taps on the notification, which can then launch your app with whatever metadata came along with the notification. This is another place where you may need some native code to retrieve that metadata.
Posted by Nypyren on 18 December 2015 - 10:20 PM
I am pretty sure someone who can adapt to any of these as needed doesn't exist or a rare specie.
Most of the veterans on these forums can do everything you listed. I've done everything there, and I'm not an expert of any of those. I'm an expert of adapting as needed. When a specific requirement is presented to the development team, we either know how to do it already (for the common stuff) or do research on the fly to figure out how to do it right then and there.
Everyone has to adapt, because markets change and demand for skills move to different skills. I started off working on PC games in C++. Six years ago I worked on console games. Three years ago I worked on web games in AS3. Today I work on mobile games in C#. Who knows where I'll be in three years. Maybe VR? I have no idea. But I'll adapt when the time comes.
The core concepts are the most important to be good at, because those are the ones that stay relevant the longest. Expert-level gritty details become outdated very rapidly as they are frequently replaced with new technology and techniques.
It's good to know as much as you can, of course, because this gives you insight into as many situations as possible to identify problems and come up with plans faster. But there is diminishing returns for expert-level knowledge in that the need for that knowledge doesn't present itself as frequently. If you need to learn that one specific thing to solve a specific problem, it's easy to learn that one thing rapidly if you have a solid foundation of general knowledge about everything.
As a concrete example, let's take graphics. The team decides what engine we're using and learn how the shaders/materials/textures/meshes/etc work in that engine. The engine handles all graphics work, but you have to set up some custom shaders. You're the guy that knows the most about shaders, so you set them up as needed. But shaders don't need tweaked that often once you get them set up the way the art team wants. They may occasionally need to be tweaked if they don't run on a specific Adreno chip or something, but that'll be like a one or two day task. When you're not using that expert knowledge about shaders, you had better be able to pull your weight with other non-shader stuff, otherwise the producer will be a little uncomfortable explaining their slipping schedule to upper management when one guy is obviously just sitting around with nothing to do.