omegablast2002@yahoo.com 6f070f8cd4
couple things here, ...
first enum'ed the variables of ADynamic class to make them easier to understand at a glance.
2nd
added stack resolves for the abilities in ADynamic, sword to Plowshare bug fixed
3rd
removing foreach mana producers from the stack, didn't realize they used the top portion of activated ability resolves, also added event sending for @tappedformana for foreach manaproducers.
4th,
in getcoreability if we're getting the core of a foreach, send the foreach->ability itself otherwise we go one layer too deep and end up throwing off the core completely.
2011-04-16 21:16:07 +00:00
2011-01-21 18:01:14 +00:00
2011-04-10 00:11:03 +00:00
2011-04-12 20:54:34 +00:00
2011-03-13 21:19:02 +00:00
2011-03-13 21:19:02 +00:00
2011-01-21 18:01:14 +00:00
2011-04-16 21:16:07 +00:00
2011-04-13 06:31:54 +00:00
2011-02-02 18:22:08 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-04-16 17:00:51 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-02-08 15:12:14 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-02-10 17:19:11 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-01-21 18:01:14 +00:00
2011-02-14 09:35:43 +00:00
2011-02-10 17:19:11 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-04-12 20:54:34 +00:00
2011-03-13 21:19:02 +00:00
2011-02-12 15:06:28 +00:00
2011-01-31 10:04:18 +00:00
2011-01-30 13:06:21 +00:00
2011-01-21 18:01:14 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-03-13 21:19:02 +00:00
2011-02-06 11:35:40 +00:00
2011-01-21 18:01:14 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-01-21 18:01:14 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-01-21 18:01:14 +00:00
2011-01-24 17:58:14 +00:00
2011-01-21 18:01:14 +00:00
2011-04-16 17:00:51 +00:00
2011-02-09 20:42:19 +00:00
2011-01-21 18:01:14 +00:00
2011-04-14 15:26:19 +00:00
2011-01-21 18:01:14 +00:00
2011-04-12 20:54:34 +00:00
2011-02-14 09:35:43 +00:00
2011-03-31 16:39:28 +00:00
2011-01-21 18:01:14 +00:00
2011-03-02 13:41:24 +00:00
2011-01-21 18:01:14 +00:00
2011-04-12 20:54:34 +00:00
2011-01-21 18:01:14 +00:00
2011-03-13 21:19:02 +00:00
2011-02-01 19:11:43 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-04-12 20:54:34 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-02-15 14:17:34 +00:00
2011-01-21 18:01:14 +00:00
2011-01-08 12:24:39 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-03-02 21:33:42 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
Performance improvements/cleanup: card->hasType("foo") performs a string lookup for an integer id. Now that our primitives have over 1000 types (1018, I believe is the number I saw while debugging), this is not the cheapest lookup. Over the course of time, a lot of new rules have crept in the code - support for 'aura', 'equipment', and recently 'planeswalker'. While profiling, I saw an inordinate amount of time being used doing map lookups for these strings. Since they're used so frequently, I've added them to the SubTypes enumeration, and swapped out doing the string lookup in favour of using the int ID directly. I also found a few places where we were using hasType("Creature") or hasType("land") when we already had helper functions to do the int lookup, so I swapped these in as appropriate, as well as a couple of places where we had hasType("instant") instead of hasType(Subtypes::TYPE_INSTANT), etc.
2011-04-10 00:07:34 +00:00
2011-01-21 18:01:14 +00:00
2011-04-12 20:54:34 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-04-14 17:06:44 +00:00
2011-01-28 06:00:51 +00:00
2011-01-21 18:01:14 +00:00
2010-02-27 18:49:03 +00:00
2011-01-21 18:01:14 +00:00
2011-02-05 06:42:53 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-04-12 20:54:34 +00:00
2011-01-30 11:14:36 +00:00
2011-01-21 18:01:14 +00:00
2011-01-31 10:24:06 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
omegablast2002@yahoo.com
6f070f8cd4