• 10
• 12
• 12
• 14
• 17
• entries
570
2427
• views
216659

# Untitled

90 views

zomg map editor

There are still some issues with it - stuff like deleting a tile sheet that is being used on the map. Yeah, that isn't good :|

It'll take another little refactor job (basically an extension of the one I did earlier - move all map-related resources into a shared "Map" class. Dur dur why didn't I do that from the beginning?). But yeah, shouldn't be too hard.

The other (really weird) thing is that the top-left tile doesn't want to get set. I MSPaint'ed it in to hide that fact, but I can't seem to figure it out. Once I write the event handler code to right-drag scroll the map I think it'll turn up though. At least, I hope it will :X

AHA.

See if you can spot the error -
int _getIndex( int x, int y ) {	if ( x > _maxX || x < 0 ||		 y > _maxY || y < 0 ) return -1;	return y * _maxX + x;}void _setTile( TileType tile, int x, int y ) {	if ( int pos = _getIndex( x, y ) ) {		_tiles[ pos ] = tile;	}}

Cookie for the first person to find it!

Quote:
 The other (really weird) thing is that the top-left tile doesn't want to get set. I MSPaint'ed it in to hide that fact, but I can't seem to figure it out.

Sounds like the kind of thing I'd turn into a 'feature'. [smile]

"And check the awesome, fearsome Tile Of Unchangibility! For an additional \$14.99 charge, you can fill your whole map with these amazing broken, er, specially featured tiles!"

Either that or I'll work it into the plot -

"..and must destroy the evil Communist Hitlars who have stolen the top-left tile of the world!!!"

* Apoch hands Mushu a != -1 to go in that if statement.

And among other things, the tile at (0,0) will have an index which evaluates to 0. False. Which means it doesn't get set :)

Hooray!

Argh, just fixed another bug -

The display of the map is an array (vector) of pointers to tiles. The tiles are stored in a tilesheet (vector). Guess what happens when you create a tilesheet, make some tiles on the map with it, then go back and edit the tilesheet?

WHOO WHOO YOU GUESSED IT!

Iterator invalidation. Swapped it over to a list of tiles; since I'm accessing the data directly with a pointer anyway, there won't be that much of a performance hit. But I need to be guarenteed that it's not going to reallocate my tiles somewhere random.

Damn you vectors, damn you! :O

void _setTile( TileType tile, int x, int y ) {
if ( int pos = _getIndex( x, y ) ) {
_tiles[ pos ] = tile;
}
}

why not?

void _setTile( TileType tile, int x, int y ) {
int indx = _getIndex( x, y )
if ( indx >= 0){
_tiles[ indx ] = tile;
}
}


Not like it should optimize any different.

Shouldn't it be >= _maxX and >= _maxY, instead of just >?

MustEatYemen - Yeah, that's what I ended up doing.

Steve - the maximum element of a vector is vector::size() - 1. Allowing it to be equal to the maximum size would cause an access violation.

Exactly:
int _getIndex( int x, int y ) {
if ( x > _maxX || x < 0 ||
y > _maxY || y < 0 ) return -1;

return y * _maxX + x;
}


If y == x == vector::size(), access violation. Using >= would fix that.

Oh, so i c.

I think _maxX and _maxY are set to the size-1 already. I think, because I honestly don't know, but my "OMFG CLICK EVERYWHERE" test didn't crash it :]

But yeah, that's why you have a job and I don't [sad]