need help plzzz
Moderator: Moderators
If you are using photoshop, settings should be adjusted to store the swap or whatever it is on a second physical drive (most people seem to have an extra in there anyway)... also, adjust the settings in photoshop to be allowed to use like 90% of your ram, it defaults to like 128 Megs or something which isn't enough... havn't played with GIMP in a bit but I would imagine story is the same there...
Yes! define the texture in per terrain type in the SMD and use the type map as a guide for the compliler. That would mean making the SMD first but that would be ok, we could put all the compiler options in there.
Leading on from that idea...
We would only upload/download the SMD and bitmaps and let the game compile them the first time they are loaded. 7zip will compress bmps pretty well, 31MB down to 1.9MB so it could work very nicely.
Leading on from that idea...
We would only upload/download the SMD and bitmaps and let the game compile them the first time they are loaded. 7zip will compress bmps pretty well, 31MB down to 1.9MB so it could work very nicely.
Well... seeing as I have texture maps that are 600 + meg in size that last bit made no sence..
aGorm
Or have i missed what your saying?We would only upload/download the SMD and bitmaps and let the game compile them the first time they are loaded. 7zip will compress bmps pretty well, 31MB down to 1.9MB so it could work very nicely.
aGorm
the GIMP doesnt like files > 1 GB though i set the max filesize to roughly 3 GB. will change to photoshop or whatever is more suitable.
The Idea of having a "metamap" with different colors for different textures seems needed and appropriate, im sure the developers will come up with a device like that
The Idea of having a "metamap" with different colors for different textures seems needed and appropriate, im sure the developers will come up with a device like that
You have, the BMPs would be just the small texture tiles plus height, metal, terrain and other maps, but not the giant texture.aGorm wrote:Well... seeing as I have texture maps that are 600 + meg in size that last bit made no sence..
Or have i missed what your saying?We would only upload/download the SMD and bitmaps and let the game compile them the first time they are loaded. 7zip will compress bmps pretty well, 31MB down to 1.9MB so it could work very nicely.
aGorm
I have written a program to stitch lots of tiles together into giant bitmaps. Currently it's set up for L3DT tiles but I could make it generic. [jedimindtrick] But this is not the solution we're looking for.[/jedimindtrick]IMSabbel wrote:Of course the easy way would be to modify the mapconverter to be able to process an array of bmps into one map... that way editing could be limited to hand 4x4 pieces which only are stiched together at the end... no need the handle GB files in the meantime...
Weaver.... what would be the difference between what we have now and that then?? It sounds like just more hastle for the poor end user to me. Generating the map would take ages on some machines...
Sounds like your saying, make a sdz with all the imagry in it, but dont compile for no apparent reason.
aGorm
Sounds like your saying, make a sdz with all the imagry in it, but dont compile for no apparent reason.
aGorm
Yes it would only be worth doing if there was a significant advantage in the file size, map size, quality equation. But I think the complile could be quicker with that system as do not ever need to make a giant texture chop it into strips convert it to dds then chop it up into smaller tiles and then compare them.
Irrespective of when the map is compiled the method is a good one I think.
The workflow is different, you still need, height, metal, and feature maps but the terrain type map has a new role as well. It defines where to place your terrain textures.
So when the map is compiled the terrain textures get compressed and dds tiles get made from them but that would be very fast as they are so much smaller than the big map file was. The tile placement system uses the terrain type map. The only extra problem is texture blending, as people may not want jaggies where the terrain changes, that would require some texture blending algorith but it's not impossible to make some extra textures at compile time.
Forget I ever mentioned compile at first run this method gets around the giant bitmap bottleneck while not really hurting the compiler. Plus the maps made will completely compatible with the current engine.
Irrespective of when the map is compiled the method is a good one I think.
The workflow is different, you still need, height, metal, and feature maps but the terrain type map has a new role as well. It defines where to place your terrain textures.
So when the map is compiled the terrain textures get compressed and dds tiles get made from them but that would be very fast as they are so much smaller than the big map file was. The tile placement system uses the terrain type map. The only extra problem is texture blending, as people may not want jaggies where the terrain changes, that would require some texture blending algorith but it's not impossible to make some extra textures at compile time.
Forget I ever mentioned compile at first run this method gets around the giant bitmap bottleneck while not really hurting the compiler. Plus the maps made will completely compatible with the current engine.
TILE BASED MAP EDITOR!
just do what annihilator does minus the height-map management and adding in dds compression... you could import textures (multiple of 32 dimention) and they would be converted into tiles... or you could download pre-made tile-sets from the internet... you could make whatever images/blending you want outside of it with whatever sized images your computer can handle and then just import them... resource use will be even less then spring and you will be able to use the built in features of the dds format to provide zooming wihthout having to scale anything... you could even allow feature placement and height map managing if you want too...
edit:
then... you would have like no compression time at all cause everything would have already been processed...
just do what annihilator does minus the height-map management and adding in dds compression... you could import textures (multiple of 32 dimention) and they would be converted into tiles... or you could download pre-made tile-sets from the internet... you could make whatever images/blending you want outside of it with whatever sized images your computer can handle and then just import them... resource use will be even less then spring and you will be able to use the built in features of the dds format to provide zooming wihthout having to scale anything... you could even allow feature placement and height map managing if you want too...
edit:
then... you would have like no compression time at all cause everything would have already been processed...
seriousely it would work better for what you do anyways... import teragen map image int this fabled program... replace all the tiles that would otherwise be wasted right in the map editor... export the sections you want to have metal by selecting them and choosing "save selection" and saving it as a lossless JPG or PNG (apparatly lossless JPGs are acctually smaller then PNGs) and open it up in photoshop, fill tool in the section you want metal in photoshop, save as a lossless Png or jpg and import it back into as a stamp in the tool (remember it gets tiled out so you can zoom out to view your 32x32 map all on the screen at the same time) and past it in the four corners you need it in... import your taragen texture, for heightmap and flatten out the bits that are supposed to have metal on them by highlighting a section of tiles and adjusting their height (ooh look a sharp cliff and smooth bits on the otherside)... import a metal map and see it previewed as overlay or import 4 of the same small metal maps... ooh lets paste a stamp we imported of an OTA style metal spot here, and then import a "metal stamp" the exact same shape and paste it on top of it... now let's import a 3DO file into our feature manager and set it's properties so we can see it in game, we'll aslo have to import the custom textures we're using for it at the same time... now let's place them on teh map... and while we're at it... let's choose start locations and set the properties for the rest of the smd and see a preview of what the detail texture and water texture are going to look like...
the great thing about this dreaming is that this kind of thing would acctually be pretty easy to do... not all at once... but I don't see any reason why it can't be done by somone who knows how to program... I had a friend look into it but he got mad at the complete lack of documentation for the acctuall map format...
the great thing about this dreaming is that this kind of thing would acctually be pretty easy to do... not all at once... but I don't see any reason why it can't be done by somone who knows how to program... I had a friend look into it but he got mad at the complete lack of documentation for the acctuall map format...
