This tool has a great potential in it! Unfortunately on my PC it seems like is not very optimized. It ran for over 10 minutes and was only at 20\79 stitching progress when i aborted it on a medium map. Tried again on a tiny arabia but it took over 8 minutes to complete. Animated water was off. The CPU usage never went above 40%, and i didnt see much ram being used, had 10 gb free during the switching still.

The final image on the arabia tiny run also wasnt perfect, as the columns didnt quite line up. Could the program be effected by ingame scroll speed\inertia settings?

PC specs;
Intel Core i5-3350P (4 physical cores\4 threads)
GTX 1060 6GB (but i dont think the program is using the gpu anyway)
12 GB ram (but ram usage didnt spike much in either run)
SanDisk SSD Amazon link normal, good ssd i guess.
1080p 60hertz monitor

Thanks for the feedback Cataphract887. Yes the only system I have ran this on is my workstation pc, which is admittedly 'high-tier'. Could you by chance share the final result of your arabia capture? And if you're feeling especially generous you can include just a screenshot of the contents of your columns folder w/large icons, from windows explorer, for that same capture (if you still have it). I have plenty experience with looking at bad results and determining what went wrong .

I may have to add some configurable properties to provide more customized optimizations.

The way this app works is by simulating a click on your minimap in order to move the view around, so the scroll speed should not come into play.

I really like the idea. It's great that you are stepping in where the devs have failed to do anything. I would love to see this project succeed.

That being said it still needs some work.
The first problem is that the stitching is sluggishly lethargic. I launched a "normal" sized map and the capturing was nice and fast. However, it took over an hour to stitch it together. During that time I cooked and had dinner and watched two YouTube videos. You need to find a different way to stitch that is lass time consuming. I could have probably arranged the 200 raw images myself in Photoshop in less time than the stitching took.

The main problem however, is that the stitching messed up and produced a long vertical stack rather than the full picture. I'm uploading the whole operating directory (600mb) of this test run, so that you can look at it for troubleshooting. I'll edit this message to include the link once it is fully uploaded.

Here ya go, think this is what you requested. I should probably mention my internet is on the fritz so even uploading this small 16 meg pictures so i may not be able to contribute much more to this discussion until i have the repairmen out again (third time this year...!)

https://www.dropbox.com/home/Public?preview=AOE+Capture+reduced+size.jpg
https://www.dropbox.com/home/Public?preview=column+folder+screenshot.jpg

@Zetnus, I did expect it to be slow but not that slow! Jeez I'm embarrassed. On my machine the longest it will typically take is ~30 min for a ludakris sized capture. I am really interested to see the result, as I have yet to observe what you're describing.

I think what I'll do now is fire up an old laptop and use that to get some lower performance benchmarks. But thanks for the info, this is the kind of feedback I need while in beta.

@Cataphract887, Thanks, much appreciated.

Here you go:

https://www.dropbox.com/s/hwt10egb0w1qy3n/HD_Full_Map_Shots.zip?dl=0

@Zetnus, Thank you for those. I did notice you are running a smaller resolution of 1366x768, is it possible and have you tried 1920x1080? I have not tested system resolutions lower than 1080p, and this is the first thing that came to mind.

Smaller res > smaller screenshots > more screenshots >
more stitching > more time

In your case is taking forever because the stitching undergoes stages of granularity, and when the faster methods fail it will revert to a very time intensive method that should work in any case. It seems because of the apparently unsupported system res, it was failing on every image (and there where a lot of them due to the res) making it perform the fail-safe time intensive method, for all of them.

Because of something like this I think it's best I add an option that will abort on the first fail, or at least notify the user. I will be testing all resolutions eventually.

For anyone else reading this, so far I have found 1440p to be a good balance between RAM usage and speed, given you have ~2GB of free memory.

Ah, that would explain things.
I currently use a laptop, and my native resolution is 1366x768, so I cannot test anything higher than that. I suppose I could try a lower resolution XD.

You should probably list which resolutions are supported somewhere on the download page.

hi I23BigC, I tried your tool again. This time I ran AoE2HD using an artificial resolution of 3072x1728 on my 1920x1080 monitor thanks to some geforce software. Still took a while to compile these pictures but was actually quite quicker and actually worked, albeit with two imperfections.



If your still developing this tool and want me to upload anything there to help you diagnose it, let me know. And thanks for the tool in the first place, this is very helpful and time saving despite the issue, which I can work around. Saved me lots of time manually stitching.

Hey, great tool! Works wonderfully, if just a bit on the slow side. If you give me some pseudo-code for the stitching part, we (I) can help you improve for speed? (I have a beast rig, yet it takes ~30 minutes to stitch 104/445 images on LUDKris). Are you using gradient descent or pooling in any way? These are two methods that will greatly increase performance when it comes to stitching. Actually, that won't even be necessary. Instead of creating a stream of small .bmp files, you could detect features in the existing temp files. Nevermind, I'm too lazy and you should be too.

My method would be something like this:

Fill out a blank image with destination resolution (based on map size / collected temp files)

You're already quite sure about the position of each temp image, since you're programming the clicks. Can't you do relative positioning or is there some bleed/inaccuracy?

If you can, just overlay the data from each temp file in the respective sector of the destination image.

If that doesn't work because of bleed/inaccuracy in relative positioning, you can program a 'check for accuracy' routine based on the edges (3-4 pixels should be plenty) or corners (10x10?) of the temp files.

if overlap (part of temp matrix equals part of destination image matrix, where the previous temp files have been put already),
detect pixel range of overlap
overlay dest img with temp img

If there's no overlap and the shots are pixel-perfect, then it's pretty easy, just do it based on the screenshot order.

In both cases, you can optimize further with pooling and feature detection
(https://www.youtube.com/watch?v=2-Ol7ZB0MmU&t=797s)

I hope that makes sense somewhat. I'm a lone wolf when it comes to programming, I rarely have to explain anything... Oh, and if you provide some pseudo-code, I can look for optimized methods. I'm pretty sure you don't need to create the stream of small bmp files. Quite sure that's what's taking so long. Writes are slow.

---

Check me out on Steam: GL252 I'm very slowly building a scenario and eyecandy map portfolio.

[This message has been edited by GL252 (edited 03-07-2018 @ 06:07 PM).]

The heroic quest to make the game as functional as it was in v1.0 continues.

Just wait until AoE2 DE arrives. We will lose all modding, and the game will only play on windows 10+windows store Plus the pathfinding will get even worse and probably lots of performance issues when they implement a genius new graphics systems