To make spring support larger maps I would need some data to test on, so if someone could create a big map preferably with an odd resolutions like 28*22 or something it would be good.
The mapconv program should have no problem with this size so there should be no problem to create it.
Give me a big map
Moderator: Moderators
-
TotalAnnihilator
- Posts: 15
- Joined: 27 Apr 2005, 21:16
-
TotalAnnihilator
- Posts: 15
- Joined: 27 Apr 2005, 21:16
-
[K.B.] Napalm Cobra
- Posts: 1222
- Joined: 16 Aug 2004, 06:15
Well I have three 524 meg BMP files ready to be made into a big map, except the MapConv tool throws an "out of memory" error when on the "Loading texture" stage...
And I'm missing a header file it seems so I can't debug the MapConv tool itself. (See dev forum for missing header info). I'm not sure if it's not able to allocate 500 megs of ram, or it's a limitation of the language. I have a gig of ram in this machine. I created the textures, 3 16bit BMP's at 524 megs each.
I'm 7zipping them now, might take awhile @@;;
*edit*
I just did the calculation (why I did them now and not before, don't ask)
a 28*22 map isn't 16392x16392 it's 28672x22528
Needless to say... this is GOD DAMN HUGE.
Maps this size without a new map format will be 200 meg easy.
I suggest for every 1x1 "map square" we go from 1024x1024 vertices to 256x256 vertices, this is a down factor of 4 and I think we can still have excellent detail. On top of that, we need a different method of texturing. My friend and I are working out the specs for a better map format that will require MUCH less size on disk and be more on-par with current engines (Unreal, Half-life, Farcry, etc).
*/edit*
And I'm missing a header file it seems so I can't debug the MapConv tool itself. (See dev forum for missing header info). I'm not sure if it's not able to allocate 500 megs of ram, or it's a limitation of the language. I have a gig of ram in this machine. I created the textures, 3 16bit BMP's at 524 megs each.
I'm 7zipping them now, might take awhile @@;;
*edit*
I just did the calculation (why I did them now and not before, don't ask)
a 28*22 map isn't 16392x16392 it's 28672x22528
Needless to say... this is GOD DAMN HUGE.
Maps this size without a new map format will be 200 meg easy.
I suggest for every 1x1 "map square" we go from 1024x1024 vertices to 256x256 vertices, this is a down factor of 4 and I think we can still have excellent detail. On top of that, we need a different method of texturing. My friend and I are working out the specs for a better map format that will require MUCH less size on disk and be more on-par with current engines (Unreal, Half-life, Farcry, etc).
*/edit*
A 16*16 map is 8192*8192 texels a 32*32 16384*16384.
I dont think our bmp importer supports 16bit bmp files so that may be why it doesnt work. (internally we always use 32 bit format and it will need to hold about 2-3 copies of the map in memory at once)
I noticed another error that prevents mapconv to go beyond about 26*26 maps though so I uploaded another verison to
http://taspring.clan-sy.com/temp/mapconv.exe
I dont think our bmp importer supports 16bit bmp files so that may be why it doesnt work. (internally we always use 32 bit format and it will need to hold about 2-3 copies of the map in memory at once)
I noticed another error that prevents mapconv to go beyond about 26*26 maps though so I uploaded another verison to
http://taspring.clan-sy.com/temp/mapconv.exe
I've traced all the errors I'm getting to this line:
Now, what sucks is I can't follow the code into the odd auxDIBImageLoad method but it sure would be nice to know wtf it is supposed to do and why I'm getting "Out of memory" and "File converstion error" boxes on simple BMP files.
I've tried it on 16, 24, and 32 bit bitmaps, 16 and 24 bit throws the conversion error, 32 throws the out of memory error...
the bmp is 16384x16384 pixels...
-Buggi
Code: Select all
AUX_RGBImageRec *TextureImage=auxDIBImageLoad(filename.c_str());
I've tried it on 16, 24, and 32 bit bitmaps, 16 and 24 bit throws the conversion error, 32 throws the out of memory error...
the bmp is 16384x16384 pixels...
-Buggi
Well how about THIS for a big map!
See once we can change the water texture, or flip a toggle or whatever, and space is their insted of water then i would realy like to have three ginormuse starr vessales, each one damaged and fractured. Each ship would have an intact anti-matter store's so if you blow that up it will create a explosion big enough to toataly vaporise the entier ship. So bomb the antimatter store's or get more metal and energy from the new space. Each starship is made of metal so you can mine it. The gravity would be 1 of course to make a zero G fighting enviroment. The back story would be as sutch: A massive space battle has ended up with a lot of floting wrekage. Both the core and the arm have been sent to retreive any anitmatter stores for use in the war. So if you blow all the other ones up, then you still have yours left!
See once we can change the water texture, or flip a toggle or whatever, and space is their insted of water then i would realy like to have three ginormuse starr vessales, each one damaged and fractured. Each ship would have an intact anti-matter store's so if you blow that up it will create a explosion big enough to toataly vaporise the entier ship. So bomb the antimatter store's or get more metal and energy from the new space. Each starship is made of metal so you can mine it. The gravity would be 1 of course to make a zero G fighting enviroment. The back story would be as sutch: A massive space battle has ended up with a lot of floting wrekage. Both the core and the arm have been sent to retreive any anitmatter stores for use in the war. So if you blow all the other ones up, then you still have yours left!