[Dev] Early 0.2 "Carthage" Progress Thread

[Flintlock]

Alright I have an initial implementation of repeating map scrolling. It doesn't work when the map is zoomed in/out yet but you can now mouse drag the map without ever reaching the edge. I can't push it to the C7 repo since I don't have permission, could I get that, please?

 

[Puppeteer]

What's your GitHub name? I'm not sure if I can grant access or not. It may need @WildWeazel

 

[Flintlock]

My name on GitHub is maxpetul. I'm already part of the C7-Game organization but can't push maybe because I'm only a member not an owner like the rest of you? I'm not sure how it works either.

 

[Puppeteer]

Ok, I added you at the repo level. I don't think I can change permissions at the org level.

 

[Flintlock]

Thanks a lot! I got my changes uploaded on branch repeating_tile_map. Also in the mean time I adjusted the new camera movement function to account for different scales, it's not pixel perfect but it works pretty well now when zoomed in or out. The next thing to do would be to center the map properly in the viewport so the edges aren't visible and to make it change size depending on zoom level (right now if you zoom out you can still see the whole map but that's kind of useful when working on it).

 

[Puppeteer]

Looking good. I'm not fully grokking it yet, but then I'm not grokking most of this code, even the parts I wrote months ago .

Usually just changing the position of a Node2D (or descendant) should "fix" the top and left edges, but I see you're using global position references, so that may not work here. I'd have to stare at it a bit longer.

 

[Puppeteer]

I tried a few things including subtracting tile size from position. That seemed to make some difference.

        MapView.GlobalPosition = new Vector2(-cameraPixelX, -cameraPixelY) - (tileSize*2);

FYI, Node2Ds are infinite, so you can use negative coordinates to draw tiles. That might make more sense, but I'm still figuring out the scrolling.

Edit: Oh, I remember another reason we were trying so hard to make the Godot camera/player feature work: right now we have a single graphic per tile, but we're going to be stacking quite a few: base terrain, overlay terrain, roads, railroads, rivers, mines, cities, units, etc., etc.. Redrawing stuff could get expensive.

On the other hand, all the textures should remain in memory, so maybe it won't actually be cumbersome.

 

[Flintlock]

That's basically what I was thinking to hide the left & top edges, just start drawing the map off the screen. The only catch is that then we'd also want to start drawing at tile (-2, -2) or something instead of at zero so (0, 0) is still in the top left.

About how scrolling works (I'll add this as a comment too): For small movements, the map itself is moved (amount is in cameraPixelX/Y) but once the movement equals an entire grid cell (2 times the tile width or height) the map is snapped back toward the origin by that amount and to compensate it changes what tiles are drawn (cameraTileX/Y). That way the MapView always covers the screen and simply provides a window into the game map.

Edit in response to your edit: I don't see what that stuff would be related to the player or camera, but I just started using Godot yesterday so I'm probably missing something. Based on what I read after a quick search online, the way to do layered tile maps in Godot is to have multiple maps drawn one atop the other. That might be a performance problem depending on how well TileMaps handle empty tiles since some layers will be mostly empty. For units I don't think we can use a TileMap since units have to move off the grid when playing movement or attack animations.

 

[Quintillus]

Sounds like good progress on the map! FWIW, I suspect performance is not going to be a major issue. In my editor (which is CPU-powered), I redraw everything that's visible all the time, and even with that inefficient approach and without GPU acceleration, it performs well on systems a decade old or newer. Fast is always better, but I wouldn't get bogged down on performance unless we see a problem, especially since there are more than enough functional questions.

EDIT: The map things are probably more properly in 0.1 "Babylon" than 0.2 "Carthage". (Which only adds to the reason to be looking at them now)

 

[Quintillus]

Initial support for this is now in the 'getImageFromPCXWithAlphaBlend(Pcx imagePcx, Pcx alphaPcx, int leftStart, int topStart, int croppedWidth, int croppedHeight)' method in PCXToGodot.cs. It does not yet handle the fact that the alpha files may be smaller than the non-alpha ones, and meant to be repeated across them, beyond that it will stop and not crash if the alpha is smaller, while still applying alpha to the alpha-file-sized area. This is good enough for the menu icon to be alpha, though fleshing that out more fully will be necessary for e.g. the hover state menu icon to be alpha.

I just added a fix for the case where alpha files may be smaller than non-alpha ones. This comes in the form of an optional alphaRowOffset parameter for getImageFromPCXWithAlphaBlend in PCXToGodot.cs, as well as a re-writing of that method.

The first fruits of this is that the advisor button in the upper left now has a hover effect.

 

[Puppeteer]

I just enabled file loading from main menu, and then I noticed that's a "Carthage" target. But before we've declared Aztec done the old 3-terrain-only map code was becoming a bit of a blocker, and swapping it out led to an initial save format because importing a Civ3 map was immediately achievable unlike full-featured map generation (or anywhere near it).

So with all the functions lying around and a file browser already made, it made sense to plumb them up. If the picked file ends in ".SAV" it runs it through the Civ3 importer, otherwise it optimistically hands it to the JSON deserializer.

But the real motivation was trying to figure out if the Mac export was crashing because of being unable to find the default json save or something else. Now that I can load a file, I can see that it works, so it *is* a problem of not finding the default json save when the Mac .app is exported.