(short)-12851 is 0xCDCD. That is a well-known bit pattern that indicates heap memory that you have allocated but not initialized (i.e. uninitialized variable on the heap).
NypyrenMember Since 19 Aug 2002
Offline Last Active Today, 10:23 PM
- Group Crossbones+
- Active Posts 3,509
- Profile Views 5,415
- 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 07 January 2014 - 12:30 PM
As far as I know on x86 Windows, guard pages are handled by using the processor's protected mode page fault behavior.
When any execute/read/write operation accesses a page that's guarded:
- The processor triggers a page fault exception since the page is marked as "not-present" to the processor.
- Windows sees the page fault and looks up the offending address, sees that it has a guard page at that location, pages the memory in (if it previously was an active page before being changed to a guard page), disables the guard flag and raises a Windows-specific guard page exception.
The guard page exception can then be:
- Intercepted by a debugger.
- Used to expand stack space, which allocates the offending page as more stack space and then sets up a new guard page above it.
- Used to cause a stack overflow exception if the stack cannot expand any more.
Windows only puts guard pages at the top (low address) of its stacks. It does not put guard pages after them (at the high addresses). However, the memory that comes after the stack will not have any allocated pages. So this will happen:
- You accidentally access memory below the stack.
- A page fault occurs.
- Windows looks up that page and sees that nothing exists there, then causes an access violation exception, which crashes your thread.
tl;dr: The processor does this the same way it handles access violations, so from a software point of view there is no additional overhead until the access violation actually occurs.
The reason nobody uses this to automatically do bounds checking on standard data arrays is because the minimum page size is 4K. This means your array would need to be a multiple of 4K in size, and you would need to isolate the array in address space such that no other allocated pages are nearby. It would waste a lot of address space to do this.
Posted by Nypyren on 04 January 2014 - 12:59 AM
Transport Tycoon and Roller Coaster Tycoon were both supposedly written primarily in x86 assembly, though I'd wager only reusable functions involved in input and rendering were reused (those games both used pure software rendering).
Also, consider precompiled .lib files (static libraries). Regardless of their original language, they're in machine code now (Machine code is typically just a direct binary encoding of assembly language). The library is still usable by any language that is compatible with the library's ABI.
Posted by Nypyren on 03 January 2014 - 02:22 PM
If you want to limit your speed, instead of applying each movement directly to mPosition, make a temporary movement vector first, apply all your player inputs to it, then limit that vector's length just before adding it to mPosition.
movementVector = zero; apply all input to the movementVector; speed = length of movementVector; if (speed > limit) // assuming limit > 0 to prevent divide-by-zero. movementVector = movementVector * (limit / speed); mPosition += movementVector;(edit) Note: You can also move the _timer.GetDelta() so that you only multiply it with movementVector on the final line. This way you won't need to multiply it with every vector, speed, or limit during your calculation.
Posted by Nypyren on 19 December 2013 - 09:15 PM
- Any I/O which the rest of the program is waiting on.
- When the CPU is waiting for the GPU or vice-versa.
- When multiple processes/threads fight over a single resource (I/O, mutex, etc).
- When your program cannot keep up with a real-time process (if you cannot decode audio/video fast enough to play it in real time).
Overhead is either:
- When you're being needlessly wasteful, the 'waste' can be called 'overhead'.
- When you're required to do more work or store more data than you want to, the extra that you don't care about is the 'overhead'.
Overhead is purely subjective; A computer that's functioning normally does ONLY what it's programmed to do, so ostensibly there is never overhead from its point of view.
Generally, programmers should think about whether they are making required overhead worse by writing their code in certain ways.
- (required) Stack frame setup/teardown when calling functions.
- (wasteful) Using recursion when you don't need to.
- (required) Network packet headers.
- (wasteful) Sending one byte of payload data per packet instead of waiting a bit to send more data at once.
- (required) Locking a texture to access its pixel data.
- (wasteful) Locking and unlocking once per pixel instead of locking, writing a bunch of pixels, then unlocking.
- (required) Allocating a stack and ThreadContext when creating a thread.
- (wasteful) Creating and destroying threads for many short-lived tasks instead of reusing them (a Thread Pool).
Posted by Nypyren on 14 December 2013 - 01:38 PM
In your class/race relationship, the normalized way I would do it is:
Classes (PK)ID Name ---------------- 1 Rogue 2 Mage 3 Warrior Races (PK)ID Name ---------------- 1 Man 2 Dwarf 3 Elf ValidClassRaces (FK)ClassID (FK)RaceID ----------------------- 1 1 2 1 2 3 3 1 3 2 3 3This allows you to ask "what races can class X be?" and "what classes can race Y be?" with the same query complexity since your tables are not biased anymore.
It allows you to rename classes or races without affecting the relationships.
It allows you to delete or change relationships quickly.
It allows you to prevent deletion of a class or race which is still in use by the relationship table through constraints.
Posted by Nypyren on 14 December 2013 - 01:17 PM
Ah so writing to the hard drive is a slow process? Why is that? Is writing to the hard drive exhausting resources(memory from CPU and RAM)?
When you pause a game, does it make the Game do less work then?
The API and OS will buffer writes for you, but eventually those buffers will be filled up by your game faster than the buffers can be 'flushed' to disk. When this happens, the write-to-file functions are forced to wait for the low-level disk write to finish.
On desktop PCs, the buffers involved are HUUUUUUUGE, so you almost never see your file I/O block until you start getting into hundreds of megabytes worth of data. Typically, saved games will not be this large.
However, resource-limited devices like smartphones or old consoles (PS2 and Wii generation) don't have NEARLY as much spare RAM to use for buffering, so their buffers fill up before the game can write all of the data to disk, and suffer from the blocking I/O issue.
No matter what your game does, the hardware speed limit will eventually require your ENTIRE game to pause if you try to write too much data at once, because you will run out of buffer space.
If a game does not have room to make at least one full copy of the data they need to write, then they must pause the game. If they can make one full copy, then the gameplay is not required to pause.
Posted by Nypyren on 14 December 2013 - 02:50 AM
There are lots of different ways to get around this, but it depends on the game. The central idea is to make a self-consistent copy of your game world that the save system can use without the gameplay modifying it in the middle of the process.
Some games keep two "frames" of their game data - current and previous frames, and allow the gameplay systems to always update the current frame. If the save system is not busy, they copy the current frame data to the 'previous' frame data. If the save system IS busy, they don't overwrite anything but can continue playing in the meantime. A few console games I worked on in the past did this.
Some games are able to quickly perform the first serialization step (making a simple data structure with all the necessary data) without impacting framerate, then start a background thread after the serialization is done to perform the rest of the job (compression and file I/O). The mobile games I work on now do this.
Some games are split into isolated regions that can be saved independently of each other, so only those smaller sections need to be saved at any given time, and the sections which aren't in use can be left in their "frozen" (already saved) form. Elder Scrolls games and use forms of this concept, I believe. From its planet file format, I believe Starbound also uses this approach.
Posted by Nypyren on 13 December 2013 - 01:53 PM
C# doesn't allow assignments within comparison blocks. That code will cause a compilation error.
This is not entirely true. C# allows assignments in comparisons. However, the comparison expression must result in a boolean (which is what catches most of the typos). This means you can still be affected by the typo, but only with boolean variables:
bool b = something; bool c = somethingElse; if (b = c) Console.WriteLine("Hi"); // This is printed if c is true, regardless of what b was.
Posted by Nypyren on 12 December 2013 - 12:45 AM
Say you have a Base class and a derived class. Unless I'm mistaken, the following code is validBase base=new Derived;
Precisely. This is the main reason that prevents type declarations from being eradicated entirely in statically typed languages. Even "var" and "auto" are picking a specific static type. They just allow you to use them to reduce typing.
If you use C#, use 'var' to reduce redundant typing, ESPECIALLY for long types like Dictionary<string,object>. But don't forget that being able to designate a variable's type manually when you need to is also very important.
Posted by Nypyren on 04 December 2013 - 11:49 PM
It's not even remotely as simple as graphics vs. gameplay or hardcore vs. casual.
Here's the reality of why long running franchises dramatically change over time: The developers of the original games no longer work at the company. Some have retired. Some got bored. Some wanted to start their own company to make a different kind of game. Some got downsized. Other people have been hired to take over. The new people have different opinions about what the game should focus on, how puzzles work, etc. Experience that the original developers had is lost or must be rediscovered by the new developers. Friends who got left behind lose morale.
Companies reuse their game engine between games. Everyone initially thinks this is good because the code works and doesn't need to be rewritten, right? Wrong. The existing code must be DRAMATICALLY changed to adapt to new consoles and features that it wasn't originally designed for -- downloadable content, multiplayer, etc. Remember all those developers who decided to quit? It turns out that they were the only ones who understood how the system works, so time must be spent by the new developers to figure out where to even MAKE those changes.
Meanwhile, other companies are making similar (but much more popular games), and the producers at your company decide "we GOTTA have this feature that they did in that other game, it must be why they are more popular than us!". Everyone other than the producers sigh because they know what's coming: Copying other people's features don't excite the development team at all, and are usually way harder to add to the game than the producers are willing to believe ("the team who made XYZ are half of our size! We should be able to do it in half the time!"). This just makes all the people actually implementing the game more stressed out and less motivated to make the best game they can. And despite what people think about large companies that steal ideas, the VAST majority of employees get really depressed when we're told to copy other games.
These forces conspire to make game development a LOT more complicated, stressful, and apathetic than it needs to be, and this is what is stifling innovation and good gameplay at larger companies.
Posted by Nypyren on 02 December 2013 - 03:26 PM
I use the context-switching analogy as well. I wouldn't say this is a problem relating to introversion. It's a problem related to short-term memory.
Make sure to express your concerns within your company. Distractions (interruptions, context switching, whatever you want to call them) are a big problem when your job involves keeping a massive amount of information within your short-term memory. In most cases the bosses/managers/producers on your team should be fielding questions from marketing instead of you. Unless you ARE the boss/manager/producer.
Things I do to try to minimize the impact of mental context switching:
- Offload your short-term memory: Break your tasks down ASAP and write them down somewhere. This lets you recover from context switching more quickly by caching your memory in a more reliable format and priming stronger triggers in your meat-memory.
- Offload your long-term memory: Document what you know so that when people ask you questions, you can redirect them to the documentation instead of being forced to be a walking encyclopedia for them. You can write a FAQ on demand as people ask you questions to minimize the up-front cost of documenting Question-Answer pairs. The goal here is to minimize the loss of your current context by not having to switch all the way into a different context.
Posted by Nypyren on 01 December 2013 - 08:17 PM
It's interesting to consider that recruiters ostensibly search for employees of particular large companies instead of by skill set or experience.
Recruiters on LinkedIn seem to just want your e-mail address so they can contact you outside of LinkedIn without anyone paying LinkedIn anything - thus, networking.
Posted by Nypyren on 29 November 2013 - 01:43 PM
Initiative = (Reactions * TUs / MaxTUs)
Whenever an enemy performed an action within your line of sight, the game would find the unit with the highest Initiative, and if it was higher than the enemy's own initiative, you'd make a snap shot if you had enough TUs left.
This would decrease the firing unit's TUs by a large number (typically around 30% of their max TUs), which would result in their Initiative value dropping for the rest of the turn. This means that if they missed, the enemy could continue moving several squares without triggering a second opportunity shot from the same unit.
The programmers gave the aliens some rudimentary handicaps and tactics to overcome getting killed by campers:
- Aliens can see the maximum distance (20 squares) no matter what lighting conditions exist.
- Aliens gain +6% Reaction, +4% TUs, and +6% FiringAccuracy per difficulty level.
- If they spot you on their turn, aliens would typically make sure that they could always back up to a safe distance away from your units (to "kite" you). In outdoor areas, this typically resulted in them firing from beyond your sight radius. In indoor areas, this would result in them forming "ambushes" as they would retreat around corners and wait for you to come to them (your movement = your consumed TUs = your lowered initiative value = the alien shooting you first).
- They would ALWAYS use explosives (grenades and blaster bombs) against you if your units were clustered together.
- The pathfinding nodes inside UFOs were set up so that the aliens would typically wander around inside the UFO randomly with a really low chance of coming out the front door. Inevitably you'd have to walk in with your soldiers with the best reactions, "nuke the site from orbit" with blaster bombs, or use mind-control scouting.
In X-Com Apocalypse, the AI was much more blindly aggressive, had many types of Aliens that could not use ranged explosives (even many of their ranged weapons were much shorter range than your weapons), and was generally much easier to kill with firing squads than in the first two games. In the endgame, aliens started using personal cloaking fields and teleporters to make it much harder to apply firing squad tactics.
Posted by Nypyren on 28 November 2013 - 02:02 AM
"Large scale systems" is somewhat of a buzz-phrase and generally indicates several separate programs/devices/people/companies that interact with each other, and are each either numerous or complicated enough that someone decided to call them "large scale" (this is subjective).
1. An MMO could probably be considered to be a large scale system.
2. Are you asking whether you can write a story where a large scale system is a plot element? Your question doesn't make any sense to me.
3. I doubt anyone would consider a program running on a single thread to be a large scale system. However, any program can be theoretically rewritten to run on a single thread. It just won't have the same performance characteristics.
4. The bad side would be that you have unnecessarily complicated a small program by trying to use large-scale methodologies where they aren't needed. For example, I could write a "hello world" program by making a REST call through a load balancer which routes the request to a server which then fetches data from a membase cluster and returns it to the first program which just prints "hello world" on the screen.