omegablast2002@yahoo.com 76a8f406ec
converted the player arrays into vectors, so we can test is a player is actually there at the time we are trying to access its variables. ...
this fixes 2 crashes I found, the first, 2 color random mode would crash on load.
2nd, ai vs ai testing would randomly crash, this should fix that also.
I noticed 2 color random mode is now trying to search for it's rules and sometimes flashes for a brief moment "error cant read file" or something like that....I could not find the source of that, it doesn't cause it to crash however it causes it to take a sec longer to load, this is before this commit btw, so the issue is still there.
it was trying to load the rules, flashed the error then crashes...i fixed the crash but not the rules error.
please review, i might have left in useless stuff...
I also did notice something, the way we are creating players is kind of all over the place. imo this is bad, it made this conversation extra hard becuase you create one player over here, another type over there, the human over in this direction, back track and create another somewhere else...this needs to be taken into account for a refactor, all player creation should happen in the same function, and at the same times...
the reason these 2 crashes existed was becuase players were being created before "gameobserver" in some modes, and in other modes, no player would exist at the time game was creating to set the player. but we then later call the same function when we actually load the player using the method specific to a mode.
this just leads to headaches, I mean no offense, just a general observation i made when converting this players array. unfortunately that kind of refactor is just a little beyond my coding ability.
2011-10-01 21:29:22 +00:00
2011-09-01 20:03:26 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-09-20 03:06:06 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-04-22 13:12:36 +00:00
2011-09-01 20:03:26 +00:00
2011-10-01 13:30:30 +00:00
2011-07-30 14:29:12 +00:00
2011-08-21 09:04:59 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-09-20 11:32:24 +00:00
2011-07-29 17:43:45 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 17:07:11 +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-06-03 20:01:50 +00:00
2011-05-06 06:40:00 +00:00
2011-02-10 17:19:11 +00:00
2011-10-01 13:30:30 +00:00
2011-04-24 10:33:38 +00:00
2011-09-20 11:32:24 +00:00
2011-10-01 21:29:22 +00:00
2011-09-17 08:42:13 +00:00
2011-09-04 02:45:18 +00:00
2011-09-06 21:08:25 +00:00
2011-09-05 22:04:10 +00:00
2011-10-01 21:29:22 +00:00
2011-08-21 09:04:59 +00:00
2011-08-14 18:13:28 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +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-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-07-04 19:09:19 +00:00
2011-07-03 08:47:51 +00:00
2011-09-01 20:03:26 +00:00
2011-04-28 07:49:51 +00:00
2011-08-14 14:42:37 +00:00
2011-09-20 11:32:24 +00:00
2011-10-01 13:30:30 +00:00
2011-08-07 04:01:56 +00:00
2011-10-01 13:30:30 +00:00
2011-09-22 04:43:05 +00:00
2011-09-01 20:03:26 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 17:07:11 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 14:24:07 +00:00
2011-03-13 21:19:02 +00:00
2011-04-23 08:43:34 +00:00
2011-04-20 07:50:00 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 17:07:11 +00:00
2011-06-02 05:33:45 +00:00
2011-10-01 13:30:30 +00:00
2011-08-14 18:09:02 +00:00
2011-04-29 17:30:57 +00:00
2011-04-20 07:50:00 +00:00
2011-09-01 20:03:26 +00:00
2011-10-01 13:30:30 +00:00
2011-09-01 20:03:26 +00:00
2011-06-04 16:22:45 +00:00
2011-09-04 23:13:22 +00:00
2011-09-17 21:27:36 +00:00
2011-05-16 23:19:08 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-05-26 12:27:44 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 21:29:22 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-09-17 08:42:13 +00:00
2011-04-20 06:27:44 +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-09-01 20:03:26 +00:00
2011-09-06 21:08:25 +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-08-21 09:04:59 +00:00
2011-08-21 09:04:59 +00:00
omegablast2002@yahoo.com
76a8f406ec