ConcurrentModificationError on Vector - vector

What I am trying to accomplish here is to remove a "blossom" from the Vector whenever a collision is detected. However, I keep getting a ConcurrentModificationError. It messes up when I try to remove the blossom from the Vector. I have tried doing it many ways. At one point when it was detected that the blossom should be removed, I saved its position in the Vector and then tried to remove it when the next position in the list was being looked at. I think this is the only method that you need to see. Can anybody see what I can do to fix this??
private synchronized void DrawBlossoms(Canvas c) // method to draw flowers on screen and test for collision
{
Canvas canvas = c;
for(Blossom blossom: blossomVector)
{
blossom.Draw(canvas);
if (blossom.hit(box_x,box_y, box_x + boxWidth, box_y + boxHeight, blossomVector) == true)
{
Log.v(TAG, "REMOVE THIS!");
//blossomVector.remove(blossom);
}
}
}

The solution is to use an iterator and synchronize on the Vector.
synchronize(blossomVector)
{
Iterator dataIterator = blossomVector.iterator();
while (dataIterator.hasNext())
{
//... do your stuff here and use dataIterator.remove()
}
}

Related

my program seems good on Windows,while on Ubuntu it is crashed

I'm programing a plane game on Windows by QT which seems good,while on Ubuntu it is crashed.It has a QLinkedList<Bullet *> Bullet_list.and it is crashed after Bullet_list.removeOne(*ite)
I've tried judging every Null-pointer,adding delete *ite after removeOne(),but it doesn't work.
Plane_Player *Plane_p;
connect(timer,SIGNAL(timeout()),this,SLOT(Refresh()));
void GameWindow::Refresh(){
QLinkedList<Bullet*>::iterator ite;
for(ite = Plane_p->Bullet_list.begin();ite != Plane_p->Bullet_list.end();++ite)
{
(*ite)->Go();//move the bullets on the screen
if((*ite)->isOutOfBound())
Plane_p->Bullet_list.removeOne(*ite);//crashed after this.
}
}
class Plane_Player
{
public:
QLinkedList<Bullet *> Bullet_list;
}
in the function Refresh(),there is other removeOne(),and it's all crashed after it.
I hope it won't be crashed on Ubuntu.
the whole project:https://github.com/Vinolzy/QT
Qt documentation states that:
If you want to insert, modify, or remove items in the middle of the
list, you must use an iterator.
So far so good. But I think the problem is that you reuse the iterator after removing an element from your linked list. To fix it you need to update your iterator after removal. For example, you can rewrite your loop like:
QLinkedList<Bullet*>::iterator ite = Plane_p->Bullet_list.begin();
while (ite != Plane_p->Bullet_list.end())
{
(*ite)->Go();
if ((*ite)->isOutOfBound())
{
ite = Plane_p->Bullet_list.erase(ite);
}
else
{
++ite;
}
}
And finally, it works differently on different platforms because your code leads to an undefined behavior.

Is there a way to tell CMFCColorButton, what colors not to present

Is there a way to tell CMFCColorButton what set of colors to display?
For example, when press, show me just orange white and black.
Update
I've tried by defining:
PALETTEENTRY palleteEntries[2] =
{
/*index 0 black*/
{0,0,0,PC_EXPLICIT},
/*index 1 white*/
{0xFF,0xFF,0xFF,PC_EXPLICIT},
};
CPalette colorPalette;
colorPalette.SetPaletteEntries(0,2,palleteEntries);
Then I get an assertion.
Just create a CPalette object.
Use void CMFCColorButton::SetPalette(CPalette* pPalette) to force usage of this palette.
CPalette colorPalette;
colorPalette.SetPaletteEntries(0,2,palleteEntries);
At this point colorPalette is just a C++ object, not HPALETTE resource object. SetPaletteEntries makes WinAPI call for a non-existing HPALETTE and fails. This is one of those times when MFC is not being helpful by hiding everything. But the debugger helps to point out the problem.
Start with LOGPALETTE instead. LOGPALETTE::palVersion should be 0x0300 otherwise CreatePalette fails. Use this instead:
CPalette pal;
LOGPALETTE* lg = (LOGPALETTE*)malloc(sizeof(LOGPALETTE) + 5 * sizeof(PALETTEENTRY));
lg->palNumEntries = 5;
lg->palVersion = 0x0300;
lg->palPalEntry[0] = { 255,0,0,0 };
lg->palPalEntry[1] = { 0,255,0,0 };
lg->palPalEntry[2] = { 0,0,255,0 };
lg->palPalEntry[3] = { 0,0,0,0 };
lg->palPalEntry[4] = { 255,255,255,0 };
if(pal.CreatePalette(lg))
{
m_myColorBtn.SetPalette(&pal);
}
free(lg);

How to suitably avoid RangeErrors when "looking around" this 2D array?

I have a 2D array structure to represent a grid of tiles that is a part of the game I am making. One aspect of the game is that the grid is filled in in a somewhat random fashion, based on analysis of a text file. Right from the outset though, I already realised that just leaving it be pretty much randomly done like this without sticking in some kind of validity checks or prevention mechanism, to stop really badly configured grid from forming, would not work out. The main problem I want to avoid is too many tiles that would be untraversable being close together, potentially severing chunks of the grid from the rest.
The idea I came up with to try avoid some really bad grids is to check when assigning a tile value to each "grid square" during generation with logic like this
if (tileBeingInserted.isTraversable()) {
//all is well
return true;
} else {
//we may have a problem, are there too many untraversables nearby?
//Proceed to check all squares "around" the current one.
}
To be clear, checking around the current square means checking the square immediately adjacent in each of the 8 cardinal directions. Now, my problem is that I am trying to reason out how to code this so that it will certainly not give a RangeErrorat any point or at least catch it and recover if it must. As an example, you could clearly take one of the corner squares to be the worst scenario in the sense that only 2 of the squares the algorithm would want to check are within the array's bounds. Naturally, if a RangeErrorhappens for this reason I just want the program to progress onward without issue so the structure
try {
//check1
//check2...8
} catch (RangeError e) {
}
is unacceptable because as soon as a single out of range square is tested the code falls out of the check block. An alternative I thought of, but do not like because of its messiness, would be to individually wrap each check in a try-catch and yes that would work I guess but that's some horrid looking code...so can anyone help me out here? Is there perhaps a different angle from which to come at this problem of avoiding the RangeErrors that I am not seeing?
So my code for testing whether another untraversable tile should be placed has shaped up like this:
bool _tileFitsWell(int tileTypeInt, int row, int col)
{
//...initialise some things, set stuff up
...
if (tile.traversable == true) {
//In this case a new traversable tile is being put in, so no problems.
return true;
} else {
//begin testing what tiles are around the current tile
//Test NW adjacent
if (row > 0 && col > 0) {
temp = tileAt(row - 1, col - 1);
if (!temp.traversable) {
strikeCount++;
}
}
//Test N adjacent
if (row > 0) {
temp = tileAt(row - 1, col - 1);
if (!temp.traversable) {
strikeCount++;
}
}
//Test NE adjacent
if (row > 0 && col < _grid[0].length - 2) {
temp = tileAt(row - 1, col 1);
if (!temp.traversable) {
strikeCount++;
}
}
//Test W adjacent
if (col > 0) {
temp = tileAt(row, col - 1);
if (!temp.traversable) {
strikeCount++;
}
}
}
return strikeCount < 2;
}
The code inside each "initial" if-statement (the ones that check row and col) is a bit pseudocode-ish for simplicity's sake. As I explained in a previous comment, the reason why I don't need to check tiles in the other 4 cardinal directions is since these checks are done while filling the map, tiles in those positions will always be either uninitialised or just out of bounds, depending on what tile the function is called to check at a given time.

HaxeFlixel tilemap collisions

I am developing a game in Haxe with the HaxeFlixel Framework.
I decided to split the map in chunks so i can load new areas of the map at runtime (without loading screen). For that i put every chunk in an instance of FlxTilemap.
Now I noticed that, when i try to move a FlxTilemap (by changing its x and y properties) the collision detection (with FlxG.collide(hero, map)) does not work right.
To test why the collision detection doesn't work, I simply added a FlxTilemap to the scene and collided it with my hero:
map = new FlxTilemap();
var mapData = "";
for (y in 0...8) {
for (x in 0...8) {
mapData += "0,";
}
mapData += "\n";
}
map.loadMap(mapData, AssetPaths.tuxemon_sprites__png, 16, 16);
for (x in 0...8) {
map.setTile(x, 6, SpriteSheet.TILES.FENCE.LOOSE_1_RIGHT);
}
for (y in 0...8) {
map.setTile(6, y, SpriteSheet.TILES.FENCE.LOOSE_1_RIGHT);
}
map.setPosition(
map.x - map.width / 2,
map.y - map.height / 2
);
add(map);
Collision detection is handeled in the update() method of the state:
override public function update():Void
{
super.update();
FlxG.collide(hero, map);
}
Am I doing it the wrong way or did I simply miss something?
EDIT:
There seems to be a problem in the HaxeFlixel collision detection.
The collision will only be detected when the x and y properties of the FlxObjects are positive.
I want to have negative x/y positions as well.
Does anyone know a fix or workaround for this problem?
Try changing the bounds of your world space. Specifically, FlxG.worldBounds.

javascript loop only applying to every other element

i have the following javascript below after i finish an ajax query
all of my images have name="pic"
<script type="text/javascript">
function done() {
var e = document.getElementsByName("pic");
alert(e.length);
for (var i = 0; i < e.length; i++) {
cvi_instant.add(e[i], { shadow: 75, shade: 10 });
}
}
my goal is to apply an image border around using this library:
http://www.netzgesta.de/instant/
the problem is that for some reason this works but it only seem to apply to every other picture instead of every one. any clue why the code above would skip every other element??
EDIT: I added an alert in the loop and it does correctly go 0, 1,2,3,4,5,6 . .
for (var i = 0; i < e.length; i++)
{
alert(i);
cvi_instant.add(e[i], { shadow: 75, shade: 10 });
}
it only seem to apply to every other picture instead of every one
That's a classic sign of destructive iteration.
Consider what happens if, as I'm guessing, the function cvi_instant.add replaces the element named pic with some other element or elements.
getElementsByName returns a ‘live’ NodeList: it is kept up to date every time you make a change to the DOM. So if it had five elements before, after your call to cvi_instant.add it now contains only four: the first node is gone and nodes 1–4 have moved down to positions 0–3.
Now you go around the loop again. i++, so we're looking at element 1. But element 1 is now what was originally element 2! We skipped the original element 1, and we will continue skipping every other element until we reach the end of the (now half as long) list.
Altering a list at the same time as iterating it causes this kind of problem. If the process inside the iteration actually adds elements to the list you can even get an infinite loop!
The quick fix is to iterate the loop backwards. Now you do the last element first, leaving all the other elements in their original positions and causing no skipping:
var e= document.getElementsByName("pic");
for (var i= e.length; i-->0;) {
cvi_instant.add(e[i], { shadow: 75, shade: 10 });
}
Another simple solution if you know you're always going to be removing the element from the list on each call is:
var e= document.getElementsByName("pic");
while (e.length>0) {
cvi_instant.add(e[0], { shadow: 75, shade: 10 });
}
The most general solution is needed when your loop body can do anything to the list, such as inserting new elements named pic at the start of the document or removing other elements from the middle. It is slightly slower but always safe to make a static copy of the list to work from:
function Array_fromList(l) {
var a= [];
for (var i= 0; i<l.length; i++)
a.push(l[i]);
return a;
}
var e= Array_fromList(document.getElementsByName("pic"));
for (var i= 0; i<e.length; i++) {
cvi_instant.add(e[i], { shadow: 75, shade: 10 });
}
My guess is that cvi_instant.add() is doing some incrementing or iteration on the values passed to it. Try doing this instead - it's easier, and I believe it will fix your problem:
function done() {
var e = document.getElementsByName('pic');
for (pic in e) { cvs_instant.add(pic, { shadow: 75, shade: 10 }); }
}
Hi I came across the same problem.
My script was skipping every other
element. I finally solved it by simply
changing the variable name from i to
k in my loop. My guess is therefor
that the variable i is used by
getElementsByTagName internally to
keep track of where it is in the
live nodelist and is leaking out
to the programmers interface somehow.
So its a bug! :-)
-- EDIT:
All of what I claim below appears to be totally wrong. I leave this here as a point for anyone who thought the same :) I tested in FF3. I would love to claim that I saw this behaviour once, in IE, but maybe it was many years ago (come to think of it, it was probably 7 years ago). My memory is probably bad :)
-- OLD:
To slightly expand on my wild guess, if it turns out to be accurate:
From memory, if you don't declare a variable ('var ...') it'll use one from somewhere else.
Thus, without testing, this code:
for(var k = 0; k < 2; k++){
f();
alert("k: " + k);
}
function f () {
k++;
}
Should show the same behaviour. I think TML's solution is quite nice, from a 'defensive coding' point of view, it my analysis turns out to be correct.

Resources