Hi monster,
I just tried to fix the normals for 256 seg theater and got this error message.
The console window error message:
I used the graphical UI. Does it make a sense to try in command line mode? I guess it does not (no real memory save i guess).
How much memory do I need for such a huge area please? Is it possible to estimate it?
I have 2 GB of RAM and tried to shut down many expendable proceses.
BTW - I am able to load, observe and mod the terrain in GUi, no problem.
Let me start by saying that MakeTerrain and ModTerrain are both very much memory consuming. This was done on purpose, in order to gain speed and not having to read from disk all the time.
This is of course getting worse for bigger theaters. Here's some numbers:
For 64 seg theater: (L0 is 4096x4096) you need approximately 4096*4096*9 bytes = 144 MB
For 128 seg theater: (L0 is 8192x8192) you need approximately 8192*8192*9 bytes = 576 MB
For 256 seg theater: (L0 is 16384x16384) you need approximately 16384*16384*9 bytes = 2.25 GB
In your case (according to the error code in the screenshot), the program loaded around 1.75 GB, then tried to load an additional 0.25 GB and didn't make it.
There is an issue out there with the 2GB limit of 32 bit windows. All the memory that can be used by applications is limited to 2 GB. But there is a solution out there as well (not tried by me). Google up the "3GB switch" followed by your operation system. Apparently, this switch allows 3GB instead of 2GB to be allocated to programs.
There is an issue out there with the 2GB limit of 32 bit windows. All the memory that can be used by applications is limited to 2 GB. But there is a solution out there as well (not tried by me). Google up the "3GB switch" followed by your operation system. Apparently, this switch allows 3GB instead of 2GB to be allocated to programs.
Thanks for answer Monster.
Does it mean the mentioned util can also virtualy simulate additional 1 GB for 2GB XP system? Or it just unlock 3GB memory in XP (if the system is 4GB for example).
I have bought small Win7 ION for my wife few months ago. But the computer is 2GB only as well.
I'm sorry Luke, but the extension of virtual memory space in WinXP is not possible. This "switch" is a specific programming trick that allows the use of additional gigabytes of physical memory actually existing in a kind of like working buffers. This is true in programs such as database engine.For example, those buffers can work like a picture of the most frequently used parts of the base. However, for use in an ordinary program requires a specific programming because it is not a virtual memory space of the user.
The author would have to properly write a program to be able to use this "switch".
From Microsoft -
AWE is a set of extensions that allows an application with the Lock Pages in Memory user right to use physical nonpaged memory and window views to various portions of this physical memory within a 32-bit virtual address space. In this way, applications are able to quickly manipulate physical memory greater than 4GB. Certain data-intensive applications, such as database management systems and scientific and engineering software, need access to very large caches of data. In the case of very large data sets, restricting the cache to fit within an application's 2GB of user address space is a severe restriction. In these situations, the cache is too small to properly support the application.
AWE solves this problem by allowing applications to directly address huge amounts of memory while continuing to use 32-bit pointers. AWE allows applications to have data caches larger than 4GB (where sufficient physical memory is present).
thanks Wlodek.
I searched some technical datails for my notebook and it was rather confusion. Some sources says, there is a limit 2GB for this machine, another says 2GB per slot limit only (means 2x2=4GB limit). I believe the limit is 4GB, but still - i need to launch and set up "unfriendly" utility, all this with unclear result. I think it was a good idea to write a program for speed. I should make my operations in newer system/hardware.
just an idea.
Is it a hard work to implement a feature/parameter into the modterrain window - the possibility to divide the task into the two separated jobs - the upper half of theater and the lower half of the theater?
I am just thinking of the stitched border - perhaps, there would be some artifacts. The algoritm would fix it, counting the whole horizontal border line for 3 joined rows in final (and replacing the original rows)...
Perhaps even in the current stage, i would be able to divide the 256 segment terrain into the 3 parts and count them separately. The border would be placed inside the flat see. I can combine these parts in photoshop, or import as whole region. But imagine the process each time, when the terrain is changed - uff.
I have maybe a silly question - whether the procedure "fix the normals" have to work on the entire map and not, for example, the rows of 256 segments in a row?
Then the memory requirements would be 256 times smaller (perhaps?)
I have maybe a silly question - whether the procedure "fix the normals" have to work on the entire map and not, for example, the rows of 256 segments in a row?
Then the memory requirements would be 256 times smaller (perhaps?)
The angle of neighboring triangles affects the final normal, i guess.
The angle of neighboring triangles affects the final normal, i guess.
OK, but based on the fact that no triangle can not go beyond the boundaries of the segment, the processing of any triangle is enough to have in memory only 9 segments (1 central and 8 border).
So thinking about the speed would be enough work for 3 rows (3 * 256 = 768 segm in RAM), no more!
I'm not an expert on memory management, so I won't try to implement various solutions such as AWE.
The point is, as I said, my program was made having speed in mind, so the faster way is to load all the data in memory (one L at a time) and do everything there. As you see for theaters up to 128 segments there is no problem. I can implement a check, when the storage space we need is too big, the process will be done piece by piece, having the hard disk as swap.
Because right now I'm on vacation, I'll look into it after a couple of weeks.
Thanks for various upgrades of your program Monster (for example BMS support etc..).
Do you still plan to implement "incremental normal fix" function in the future? No stress, just for info...
Thanks
Luk
monster wrote:Unfortunately, although I could enter more than 256 sets in TerrainEditor without any problem, when I tried to fly in Falcon above the area of the new tiles I entered (these that belong to sets above 255), I got a CTD (in OF).
Variable wise, there shouldn't be any problems, because the variable that is used to store the number of sets, is long integer (4 bytes, 32 bits) with a theoretical maximum of 4.294.967.295 sets (or 68.719.476.720 tiles). What I believe is, that this value is limited in the code because of the L0 and L1 tile values.
The L1 tile values are calculated by adding 4.096 to the corresponding L2 tile value. For L0 the value to add is 8.192. I believe, the code checks if the value that is called to display is between the following ranges, to get the tile from the corresponding source:
Error 52 at runtime.
File name or number of incorrect
Do you have anything in registry that is not valid anymore? Any left overs of Falcon installations?
Try to open registry editor (Win+R -> regedit -> Enter), go to "HKEY_LOCAL_MACHINE\SOFTWARE\MicroProse", right-click on it and rename it to e.g. "MicroProse_". After that run TerrainEditor (should be working) and update it. After that you can rename the registry key back to "MicroProse".
Last edited by Snake Man on 2011-10-11 15:58:50, edited 1 time in total.
Reason:please dont quote images.
Version 3.4.2 is out adding a Station+ILS editor plus fixing some bugs. Additionally, MakeTerrain and ModTerrain were updated in order to handle big theaters.
I need some feedback for the Stations+ILS editor, since I only have OF and BMS installations, so it wasn't tested on FF/AF versions.
I was not able to wait until the night....great tool!
I guess the time was roughly similar as lxnormalfix 128 terrain processing. Means it was aproximately 4 times faster than the old util (256 seg theater).
I've been testing TerrainEditor a bit and I wanted to ask first that is my computer running it properly as the speed of navigating the terrain is very slow?
I have AMD Athlon X2 7750 2.7Ghz, 2gb Kingston DDR2 800mhz, ATi Radeon HD 4850 512mb and running win7 64bit with latest drivers.
Important PMC Tactical Forum New User Registration please read new info here.
Generally, the navigation is not the faster it can be. This gets worse if you display a big area on the screen. The fastest results are when you have a grid of let's say 6x6 and the zoom factor is 1 (all the way to the left). Another thing you can do to speed it up is to enable cache (use tile cache) and the smaller the cached tile size, the better.
With the cache option you loose a little bit on tile clarity but you gain on speed. Personally, I use the Theater Preview Window for navigating and adjusting the viewable tiles (by grid size and zoom) to a level that changes are fast.
On my system (Intel Q6600 @2.4GHz) the changes are fast with the above settings (6x6, zoom 1, cached tiles 128).
I have been using Window Tile Lab. When creating textures from a BMP image size 1024 px DDS textures are created but not taken as a reference the BMP image loaded. The program creates new textures from existing textures in the theater.
By creating smaller textures, no problem. 512, 256 px ...
A cut in the region that wish to incorporate:
Image resized. Sorry, Snakeman ;-P
Last edited by Snake Man on 2012-01-12 17:23:33, edited 1 time in total.
Reason:please dont hotlink large (file size) images.
Cordialmente,
NOTE: Apologies my English. I use Google Translator
I'm sorry but I can't reproduce the error you're describing. How big is the image that you're importing in order to create the new tiles? I tried with a 3200x2400px photo and it worked as it should. Maybe is a memory issue and there is no memory available to load the imported image. Do you see the image you want to chop in the TE window and you are able to resize it and all?
Use an image of a 8000x8000 px. The image is loaded, I see and I can move and resize.
If I make it smaller (half size) resizing the program runs directly into the Lab tab to its original size but does not work. When I start the conversion process that consumes about 800 MB on a 1GB I still have free memory.
If I try to load a larger image I have of 20000px by 20000px here and does not load the image.
Cordialmente,
NOTE: Apologies my English. I use Google Translator
Probably a limitation of FreeImage Library that I'm using to manipulate images. I'd suggest to cut the image in smaller pieces (maybe 4 parts of 4000x4000) and try to do it with these.
monster wrote:Probably a limitation of FreeImage Library that I'm using to manipulate images. I'd suggest to cut the image in smaller pieces (maybe 4 parts of 4000x4000) and try to do it with these.
Thanks, Monster.
I will do that.
Cordialmente,
NOTE: Apologies my English. I use Google Translator
monster wrote:Probably a limitation of FreeImage Library that I'm using to manipulate images. I'd suggest to cut the image in smaller pieces (maybe 4 parts of 4000x4000) and try to do it with these.
Thanks, Monster.
I will do that.
Indeed, the size limit that you can import images 6500x6500 px Terrain Editor correctly in the Lab Window.
Cordialmente,
NOTE: Apologies my English. I use Google Translator
By introducing the textures in dds are created texture.bin night, but the textures obtained are completely black. Lights are not created, as did the Seasonswitcher ...
Is that correct?
If this is incorrect What is the most common mistake that I can be making?
If I can get right how an automated nightly dds textures?
Cordialmente,
NOTE: Apologies my English. I use Google Translator
Unfortunately, when you import new tiles in the BIN file, the Night tiles generated are black. There is no automatic night tile creation method. Something is worked on right now but the last version of TerrainEditor doesn't produce night tiles.
Currently the only way I know of is by editing them in Photoshop (or any other similar program) individually.
That been said, there is a very clever method by Khronik (in BMS forums) that is being worked on, that automates the procedure. There is nothing public right now but we should come to that. Take a look here [admin edit: please don't link to private forums]
Last edited by Snake Man on 2012-03-15 11:42:23, edited 1 time in total.
Reason:please dont link to private forums
