Optimized for speed and accuracy, better benchmarking and smaller files. Tournesol helped me with it quite a lot, thanks!
EDIT:
v4 released!
-still faster
-lots of bugs fixed
Thanks rafal99 for reporting some bugs!
http://www.fileuniverse.com/?p=showitem&ID=3182
Krog's Metal Class v0.4
Moderators: hoijui, Moderators
-
Targ Collective
- Posts: 202
- Joined: 12 Nov 2005, 14:16
Well I've taken notice and v3 was almost going to make it into XE8, hwoever after I added it and made a few other little changes NTai stopped building mexes, so i removed it and found the problem which wasnt related to the class but by then I didnt have time to re-integrate it.
Krogothe, ahve you asked Zaphod to run an example of this class with a map test from hsi enw map renderer? I'd like to see how it performs on gigantic map sizes of 500x500+, aswell as what the filesizes on cached data looks like.
I may also have soem code for you later for the LoadData that'll mean it can save v4 data and laod v2/3 data and convert it....
Also you change thigns betwene different versions, could you adopt somethign like XE8 has using the file extension .mvx where the x is the version of the metal class? atm XE8 uses .mv1, and my own personal copy witht he enw class uses .mv3, and when i update it it'll be .mv4.
Considering that Veylon has agreed to share the data structure loading data from the same folders as NTai in OTAI 1.14.
Krogothe, ahve you asked Zaphod to run an example of this class with a map test from hsi enw map renderer? I'd like to see how it performs on gigantic map sizes of 500x500+, aswell as what the filesizes on cached data looks like.
I may also have soem code for you later for the LoadData that'll mean it can save v4 data and laod v2/3 data and convert it....
Also you change thigns betwene different versions, could you adopt somethign like XE8 has using the file extension .mvx where the x is the version of the metal class? atm XE8 uses .mv1, and my own personal copy witht he enw class uses .mv3, and when i update it it'll be .mv4.
Considering that Veylon has agreed to share the data structure loading data from the same folders as NTai in OTAI 1.14.
Backwards compatibility would be silly, the old versions had some rare but real bugs that could mess up the spots, and the new version has yet to take longer than 2 seconds to cache any map. There is absolutely no reason whatsoever in my eyes to have backwards compatibility or shared metal data (files are so tiny).
When huge maps are implemented, and in the unlikely event that they become popular (honestly a 500x500 would take hundreds of hours and with spring's current unit limit it would be a desert, plus no one would be arsed making decent maps of such size), then we can discuss that further.
Im open for bug reports though
When huge maps are implemented, and in the unlikely event that they become popular (honestly a 500x500 would take hundreds of hours and with spring's current unit limit it would be a desert, plus no one would be arsed making decent maps of such size), then we can discuss that further.
Im open for bug reports though
The NMF won't support maps really that much bigger. I personally use heightmap size to indicate map size, as that is what all general terrain apps use too. A 4kx4k heightmap is good limit, but is not a lot bigger than springs current maximum. AFAIK this is also the limit that supcom usesI'd like to see how it performs on gigantic map sizes of 500x500+, aswell as what the filesizes on cached data looks like.
a 500x500 map would take hundreds of hours and be too much for any version of the spring engine to open if done with the current map format
However a 500x500 map in zaphods new new map format would be much quicker to create, and much quicker to load and display, making gigantic maps very very feasible. Just remember that creating a map in the next map format doesn't involve rendering a map sized texture like the current format, but instead applies a set of textures to different parts of the map using texture splattering. Thus a 2kx2k map could be made out of 20 512x512 textures rather than a single 1024000x1024000 texture. Thus 5.2 mega pixels of texture under the new new format versus 1.048576x10^9 Mega pixels under the current for a 2kx2k map.
Anyways I'd like to report a bug then.
AI with metal class v2 upgrades to metal class v4. Problem! V2 of the metal class saves to say "map.metaldata" and v4 saves to "map.metaldata", oh wait what happens if a v2 cached data is loaded by a v4 class? V4 saves data using a binary method whereas v2 saves it using a formatted text and line return method! V3/4 also save average metal value data at the beginning but V2 does not! What happens when this data is fed into a v4 class and a vector<> is filled? What happens when that vector<> is used and the data is read and all this corrupt data is worked upon?
How does the v4 class know that the file it's loading has v2 or v1 data?
That and wouldn't it be nice to boast v4 can run through a 500x500 map in x seconds?
However a 500x500 map in zaphods new new map format would be much quicker to create, and much quicker to load and display, making gigantic maps very very feasible. Just remember that creating a map in the next map format doesn't involve rendering a map sized texture like the current format, but instead applies a set of textures to different parts of the map using texture splattering. Thus a 2kx2k map could be made out of 20 512x512 textures rather than a single 1024000x1024000 texture. Thus 5.2 mega pixels of texture under the new new format versus 1.048576x10^9 Mega pixels under the current for a 2kx2k map.
Anyways I'd like to report a bug then.
AI with metal class v2 upgrades to metal class v4. Problem! V2 of the metal class saves to say "map.metaldata" and v4 saves to "map.metaldata", oh wait what happens if a v2 cached data is loaded by a v4 class? V4 saves data using a binary method whereas v2 saves it using a formatted text and line return method! V3/4 also save average metal value data at the beginning but V2 does not! What happens when this data is fed into a v4 class and a vector<> is filled? What happens when that vector<> is used and the data is read and all this corrupt data is worked upon?
How does the v4 class know that the file it's loading has v2 or v1 data?
That and wouldn't it be nice to boast v4 can run through a 500x500 map in x seconds?
i meant to play not to makeAF wrote:a 500x500 map would take hundreds of hours and be too much for any version of the spring engine to open if done with the current map format
However a 500x500 map in zaphods new new map format would be much quicker to create, and much quicker to load and display, making gigantic maps very very feasible. Just remember that creating a map in the next map format doesn't involve rendering a map sized texture like the current format, but instead applies a set of textures to different parts of the map using texture splattering. Thus a 2kx2k map could be made out of 20 512x512 textures rather than a single 1024000x1024000 texture. Thus 5.2 mega pixels of texture under the new new format versus 1.048576x10^9 Mega pixels under the current for a 2kx2k map.
Fix: delete old metal files and/or change folder metal info is saved/loaded to.Anyways I'd like to report a bug then.
AI with metal class v2 upgrades to metal class v4. Problem! V2 of the metal class saves to say "map.metaldata" and v4 saves to "map.metaldata", oh wait what happens if a v2 cached data is loaded by a v4 class? V4 saves data using a binary method whereas v2 saves it using a formatted text and line return method! V3/4 also save average metal value data at the beginning but V2 does not! What happens when this data is fed into a v4 class and a vector<> is filled? What happens when that vector<> is used and the data is read and all this corrupt data is worked upon?
How does the v4 class know that the file it's loading has v2 or v1 data?
Time will tell, sooner or later, time will tell, and i doubt maps this big will be AI playable on non-supercomputers or even fun to play by normal players. No spring mod atm supports nowhere near this sort of gameplay, with maps greater than 30x30 already being planewars all the way.That and wouldn't it be nice to boast v4 can run through a 500x500 map in x seconds
Id say the player distribution on map sizes could be estimated using a normal distribution, with the mean being the average width or height of the map:
X~N(12,4)
Judging how even with 40x40 maps available and that probably less than 2% of the games are played on anything bigger than 24x24 im giving each player an average play of once per lifetime on maps bigger than 100x100, just to test it out and not actually finishing the game.
Last edited by krogothe on 14 May 2006, 17:57, edited 1 time in total.
And I meant both. Zaphod wouldnt be making a new renderer that had a maximum of 4kx4k in total atm if it was unfeasable to play it at those sizes, nm 1/4 the maximum. Zaphod has said that rendering this map format will be a lot quicker than the current format, and that he's investigated different methods of displaying large quantities of map when zoomed out such as in supcom.i meant to play not to make
4kx4k maps that can be played are feasable under his new renderer both to make and to play.
And aside from that, Users are already expected todo work installing an AI, i tried to negate this by having them run an installer which did all the work for them. Remember what warlord zsinj said about when he posted at supcom forums and they foudn spring too hard to deal with installing? Or the notes in PC Zone when they mentioned the Starwars mod? You should prepare for every eventuality, because if something can go wrong it will go wrong, what would a major software company say if you said to them that the user can manually delete the cached files themselves to prevent a crash? How can we possibly hope to compete with any other project if we're doing things like that?!
From the looks of it it seems NTai and OTAI will be using file extensions with a version number in them to prevent this, while KAI suffers from that sort of attitude, and possibly AAI unless submarine adopts a similar approach, as I doubt greatly that he'll load OTAI and NTai caches and instead create his own as he's always done.
Did I get it right:Zaphod wrote: The NMF won't support maps really that much bigger. I personally use heightmap size to indicate map size, as that is what all general terrain apps use too. A 4kx4k heightmap is good limit, but is not a lot bigger than springs current maximum. AFAIK this is also the limit that supcom uses
Currently, a 513x513 pixel heightmap is a 8x8 "map units / screens" map. Like say, small divide. I think the most common map size is 16x16.
So a 4kx4k pixels heightmap would be 64x64 map units? It would be like a 8x8 grid of small divides.
Isn't currently altored earth 20something x?
Sounds big, and probably useful. Maybe some new mods and engine features then would make that big maps playable...
KAI generates its own folderstructure, detects older files and discards/overwrites them automatically, its not really an issue, all the user has to do is put the dll in the globalAI folder, then he can play pretty much any mod and map.AF wrote:And aside from that, Users are already expected todo work installing an AI, i tried to negate this by having them run an installer which did all the work for them. Remember what warlord zsinj said about when he posted at supcom forums and they foudn spring too hard to deal with installing? Or the notes in PC Zone when they mentioned the Starwars mod? You should prepare for every eventuality, because if something can go wrong it will go wrong, what would a major software company say if you said to them that the user can manually delete the cached files themselves to prevent a crash? How can we possibly hope to compete with any other project if we're doing things like that?!
From the looks of it it seems NTai and OTAI will be using file extensions with a version number in them to prevent this, while KAI suffers from that sort of attitude, and possibly AAI unless submarine adopts a similar approach, as I doubt greatly that he'll load OTAI and NTai caches and instead create his own as he's always done.
The versioning code is not yet implemented as of now, and it will be using functions and defines that only KAI uses, which would increase implementation time. The reason it is not yet implemented is the simple fact that KAI will not be released every other day so when it is released the metal format will probably be final.
You forget im posting this class here for YOUR benefit, not mine, i took my time to comment code i fully understand and then to upload it, so please think about it.
It is not my fault if you are reluctant to change the metal folders or set up a installer that deletes the metal folder. It seems keen enough on doing other things like installing 1000 random apps/mods/groupaisthat i dont want.
I see no problem whatsover, its your choice to use my metal class and you could easily change it yourself, its two goddam characters in the whole file that will solve your whole problem, yet you write thousands of them here for no avail since i wont change my stance.
And no, linux is not in the roadmap yet.
You forget im posting this class here for YOUR benefit, not mine, i took my time to comment code i fully understand and then to upload it, so please think about it.
It is not my fault if you are reluctant to change the metal folders or set up a installer that deletes the metal folder. It seems keen enough on doing other things like installing 1000 random apps/mods/groupaisthat i dont want.
I see no problem whatsover, its your choice to use my metal class and you could easily change it yourself, its two goddam characters in the whole file that will solve your whole problem, yet you write thousands of them here for no avail since i wont change my stance.
And no, linux is not in the roadmap yet.
Not really, maybe for my AI but everyone else will have the problem. You're setting a standard when you release and the standard is incomplete.
OTAI and NTai data sharing only occured because our data formats for cached files for many things where the same and that's lead on to other things, which wouldnt have been possible if the data hadnt been the same to begin with.
It's also setting an example for newcomers.
OTAI and NTai data sharing only occured because our data formats for cached files for many things where the same and that's lead on to other things, which wouldnt have been possible if the data hadnt been the same to begin with.
It's also setting an example for newcomers.
no, im not gonna make a change just for you, the jokes gone a bit far now and ill be quite frank:
I couldnt care less if my metal class is not to your specifications or anyone elses, im not releasing this so i can give my insecure self some dignity provenient from positive criticism and approval by others. In other words, i dont give a shit, the class is there, use and change it if you want, else dont, thats the end of it.
Bug reports are one thing, but custom-features you can implement youself in under 10 seconds is another. Talk to veylon and agree on standards or whatever, ive done my part.
I couldnt care less if my metal class is not to your specifications or anyone elses, im not releasing this so i can give my insecure self some dignity provenient from positive criticism and approval by others. In other words, i dont give a shit, the class is there, use and change it if you want, else dont, thats the end of it.
Bug reports are one thing, but custom-features you can implement youself in under 10 seconds is another. Talk to veylon and agree on standards or whatever, ive done my part.
Like the colour diagram drawer with the metal map displayed and the spots chosen I submitted that was rejected?
Or the problem dealing with spring style metalmaps that for more than a week was ignored as you said it didnt exist untill i shoved examples and screenshots and debug data on the forum?
Or the variable "bool metalmap;" you talk about which mysteriously dissapeared from the public releases in V2 and hasnt been seen since?
Or the array of features you implemented, then later on say you tested while saying they havent been implemented yet in the same post a paragraph later =s?
Or the problem dealing with spring style metalmaps that for more than a week was ignored as you said it didnt exist untill i shoved examples and screenshots and debug data on the forum?
Or the variable "bool metalmap;" you talk about which mysteriously dissapeared from the public releases in V2 and hasnt been seen since?
Or the array of features you implemented, then later on say you tested while saying they havent been implemented yet in the same post a paragraph later =s?