(updated 9/21)
Will RomTerraria work with the Mac/Linux versions of Terraria introduced with 1.3.0.7?
Not at this time. Soon.
Are you planning on making RomTerraria work with the Mac/Linux versions?
I'm currently working on it. When it's done, you'll need to copy your Mac/Linux executable over to a Windows machine and patch it.
Do you have an ETA?
Not at the moment.
July 25, 2015
July 19, 2015
RomTerraria 4 v0.8 Feature List
Still working on the next update while my ankle recovers. As I get things working, will add them to the list here so you'll know what's in the next update.
- In windowed mode, you'll no longer be restricted to the size of your primary desktop. However, if you stretch your window so that it is larger than 8192 pixels in any direction, the game may crash.
July 13, 2015
Update on RomTerraria Ultra-High Resolution Support
If you are still crashing with resolutions higher than 4096 pixels in any one direction (for example, 5760x1080) after updating to 1.3.0.5, I'm sorry. I've put in as much troubleshooting as possible without being able to reproduce the issue in-house...which is my next step.
Right now, I'm running on a 2560x1440 monitor with a GeForce GTX 760. I'm going to see if I can get another two monitors attached to this guy this week in hopes of breaking the ultra-wide resolution barrier and I'll see if I can reproduce the issue under a debugger then.
It's currently looking like a write-after-free bug with a render target.
If anyone can attach a debugger to their Terraria.exe process patched to 1.3.0.5 with v0.7 before then and can get me any detail, I can work on patching it, but until then, I'm stuck.
Sorry for the delay.
Right now, I'm running on a 2560x1440 monitor with a GeForce GTX 760. I'm going to see if I can get another two monitors attached to this guy this week in hopes of breaking the ultra-wide resolution barrier and I'll see if I can reproduce the issue under a debugger then.
It's currently looking like a write-after-free bug with a render target.
If anyone can attach a debugger to their Terraria.exe process patched to 1.3.0.5 with v0.7 before then and can get me any detail, I can work on patching it, but until then, I'm stuck.
Sorry for the delay.
July 12, 2015
RomTerraria 4 v0.7 Released
Taking care of a sick friend this weekend has pushed a lot of stuff back.
Download link on this page.
In this release:
Download link on this page.
In this release:
- Option to force Terraria to catch CorruptedStateExceptions. This option adds the HandleCorruptedStateException and SecurityCritical attributes to Terraria.Program.LaunchGame.
- Added tooltips to currently enabled options.
July 10, 2015
Trip This Weekend; Updates Sunday Evening
Almost done getting RomTerraria's code cleaned up for release on GitHub, but may not have it done tonight. The only issues that I'm aware of right now are that people who are using RomTerraria on certain multimonitor configurations are crashing out without a stack trace. Enabling the legacy corrupted state exception mechanism should have worked to let me diagnose that, but it turns out that it didn't. I'm now looking into injecting exception handlers into methods to try to help with diagnosing.
I've got an unexpected trip down to Yosemite tomorrow morning, but I'll be back on Sunday.
I've got an unexpected trip down to Yosemite tomorrow morning, but I'll be back on Sunday.
July 9, 2015
RomTerraria 4 v0.6 Released
Main post here.
In this build:
In this build:
- Updated patcher to work with Terraria 1.3.0.4. They renamed InternalMain to LaunchGame and it broke the patcher.
- Added a new flag to Terraria.config to allow Terraria to catch CorruptedStateExceptions and report the stack trace. This will not fix the weird multimonitor crashes that some of you are getting, but should allow you to get the stack trace so I know where I need to patch stuff up.
July 8, 2015
RomTerraria 4 v0.6 Coming Thursday Evening
I don't have time to test this release and get it out tonight, so it will come out tomorrow.
This release will not fix the "crash without stack trace, aka NullPointerException, aka access violation" issues, but will allow me to get a stack trace from them.
If you are wondering how I'll get the stack trace, it's going to be a bit tricky, but here's the article I'm using to figure it out.
Update: Home, and working on updating RomTerraria to work with 1.3.0.4 first.
This release will not fix the "crash without stack trace, aka NullPointerException, aka access violation" issues, but will allow me to get a stack trace from them.
If you are wondering how I'll get the stack trace, it's going to be a bit tricky, but here's the article I'm using to figure it out.
Update: Home, and working on updating RomTerraria to work with 1.3.0.4 first.
July 6, 2015
Calculate OpenCV warpPerspective Map For Reuse (C++)
At work, I was working on an OpenCV project that utilized warpPerspective quite extensively for real-time perspective correction. It worked great, but it was slow. When I profiled my solution, warpPerspective was taking ~20% of the CPU on my MacBook Pro.
Now, if you look at the code for warpPerspective, it's essentially doing quite a bit of matrix multiplication for each pixel. Since I'm assuming that my camera won't change position during a run, that's a lot of wasted effort.
I use the following code to calculate the map that is generated by warpPerspective up front so I can use it in a remap call later to get the same results for less than half the CPU cost. I store the final map in cv::Mats named transformation_x and transformation_y.
transformationMatrix = cv::getPerspectiveTransform(originalCorners, destinationCorners);
// Since the camera won't be moving, let's pregenerate the remap LUT
cv::Mat inverseTransMatrix;
cv::invert(transformationMatrix, inverseTransMatrix);
// Generate the warp matrix
cv::Mat map_x, map_y, srcTM;
srcTM = inverseTransMatrix.clone(); // If WARP_INVERSE, set srcTM to transformationMatrix
map_x.create(sourceFrame.size(), CV_32FC1);
map_y.create(sourceFrame.size(), CV_32FC1);
double M11, M12, M13, M21, M22, M23, M31, M32, M33;
M11 = srcTM.at<double>(0,0);
M12 = srcTM.at<double>(0,1);
M13 = srcTM.at<double>(0,2);
M21 = srcTM.at<double>(1,0);
M22 = srcTM.at<double>(1,1);
M23 = srcTM.at<double>(1,2);
M31 = srcTM.at<double>(2,0);
M32 = srcTM.at<double>(2,1);
M33 = srcTM.at<double>(2,2);
for (int y = 0; y < sourceFrame.rows; y++) {
double fy = (double)y;
for (int x = 0; x < sourceFrame.cols; x++) {
double fx = (double)x;
double w = ((M31 * fx) + (M32 * fy) + M33);
w = w != 0.0f ? 1.f / w : 0.0f;
float new_x = (float)((M11 * fx) + (M12 * fy) + M13) * w;
float new_y = (float)((M21 * fx) + (M22 * fy) + M23) * w;
map_x.at<float>(y,x) = new_x;
map_y.at<float>(y,x) = new_y;
}
}
// This creates a fixed-point representation of the mapping resulting in ~4% CPU savings
transformation_x.create(sourceFrame.size(), CV_16SC2);
transformation_y.create(sourceFrame.size(), CV_16UC1);
cv::convertMaps(map_x, map_y, transformation_x, transformation_y, false);
// If the fixed-point representation causes issues, replace it with this code
//transformation_x = map_x.clone();
//transformation_y = map_y.clone();
I then apply the map using a remap call:
cv::remap(sourceImage, destinationImage, transformation_x, transformation_y, CV_INTER_LINEAR);
Ended up dropping CPU usage for the call down to ~8%. I'll take it.
Now, if you look at the code for warpPerspective, it's essentially doing quite a bit of matrix multiplication for each pixel. Since I'm assuming that my camera won't change position during a run, that's a lot of wasted effort.
I use the following code to calculate the map that is generated by warpPerspective up front so I can use it in a remap call later to get the same results for less than half the CPU cost. I store the final map in cv::Mats named transformation_x and transformation_y.
transformationMatrix = cv::getPerspectiveTransform(originalCorners, destinationCorners);
// Since the camera won't be moving, let's pregenerate the remap LUT
cv::Mat inverseTransMatrix;
cv::invert(transformationMatrix, inverseTransMatrix);
// Generate the warp matrix
cv::Mat map_x, map_y, srcTM;
srcTM = inverseTransMatrix.clone(); // If WARP_INVERSE, set srcTM to transformationMatrix
map_x.create(sourceFrame.size(), CV_32FC1);
map_y.create(sourceFrame.size(), CV_32FC1);
double M11, M12, M13, M21, M22, M23, M31, M32, M33;
M11 = srcTM.at<double>(0,0);
M12 = srcTM.at<double>(0,1);
M13 = srcTM.at<double>(0,2);
M21 = srcTM.at<double>(1,0);
M22 = srcTM.at<double>(1,1);
M23 = srcTM.at<double>(1,2);
M31 = srcTM.at<double>(2,0);
M32 = srcTM.at<double>(2,1);
M33 = srcTM.at<double>(2,2);
for (int y = 0; y < sourceFrame.rows; y++) {
double fy = (double)y;
for (int x = 0; x < sourceFrame.cols; x++) {
double fx = (double)x;
double w = ((M31 * fx) + (M32 * fy) + M33);
w = w != 0.0f ? 1.f / w : 0.0f;
float new_x = (float)((M11 * fx) + (M12 * fy) + M13) * w;
float new_y = (float)((M21 * fx) + (M22 * fy) + M23) * w;
map_x.at<float>(y,x) = new_x;
map_y.at<float>(y,x) = new_y;
}
}
// This creates a fixed-point representation of the mapping resulting in ~4% CPU savings
transformation_x.create(sourceFrame.size(), CV_16SC2);
transformation_y.create(sourceFrame.size(), CV_16UC1);
cv::convertMaps(map_x, map_y, transformation_x, transformation_y, false);
// If the fixed-point representation causes issues, replace it with this code
//transformation_x = map_x.clone();
//transformation_y = map_y.clone();
I then apply the map using a remap call:
cv::remap(sourceImage, destinationImage, transformation_x, transformation_y, CV_INTER_LINEAR);
Ended up dropping CPU usage for the call down to ~8%. I'll take it.
July 4, 2015
Sick
Woke up with a hell of a cold and can't concentrate on much of anything.
Taking the day off from everything, including side projects.
Update: Still sick. RomTerraria FAQ updated.
Update part deux: Getting better, but still enjoying NyQuil-induced comas every evening. Will try to get back on RomTerraria tonight.
Update the third: Feeling a lot better. Should be back on RomTerraria Thursday evening.
Taking the day off from everything, including side projects.
Update: Still sick. RomTerraria FAQ updated.
Update part deux: Getting better, but still enjoying NyQuil-induced comas every evening. Will try to get back on RomTerraria tonight.
Update the third: Feeling a lot better. Should be back on RomTerraria Thursday evening.
July 2, 2015
RomTerraria 4 v0.5 Released
In this build:
- If you are crashing after an alt-tab or changing from windowed mode to full screen or back, RomTerraria may spit out some crash information into a text file in your save game folder called CrashInInitTargets.txt.
- General logging support into RomTerrariaDebug.txt in your save game folder.
- If you have been experiencing flickering or missing textures, I've got a potential fix in to work around a race condition in Terraria.Graphics.TextureManager.Load.
July 1, 2015
RomTerraria 4 v0.4 Released
Link back to main blog post.
Rendering issues with missing transparent surfaces, missing items, and some rendering crashes should be fixed now.
Last update for the night. I have work in the morning.
Rendering issues with missing transparent surfaces, missing items, and some rendering crashes should be fixed now.
Last update for the night. I have work in the morning.
RomTerraria 4 v0.2 Released
Wow...3,200 downloads in less than 24 hours. Nuts.
- Found the issue with the crashes in single- and multiplayer on x64 boxes. Turns out there is a knowledge base article about it. The Terraria.exe.config file now included should take care of it, whether you use RomTerraria or not.
- Added "Disable Achievements" per request.
Subscribe to:
Posts (Atom)