Map Editor: progress and some questions
Moderator: Moderators
Map Editor: progress and some questions
Hello peoples of the well-respected TA Spring, this is my first post; hopefully I put it in the right thread.
Anyways, I have been working on a map editor for Spring in JAVA, since it seemed easy enough.
Here are some screenshots:
(requires Java3D)
and
As you can see, I have been trying to implement time-saving features such as transparency, streamlined compiling, and terrain preview. My guess is that people will still import images from outside programs.
Anyways, my questions:
(1) Mapconv.exe mentions a tile file to assist it in finding tiles. Because my program relies on tiles for the texture anyways, I was curious to know what the format of this tile file was.
(2) Would someone be interested in making a JAVA SMD creator GUI that I could plug-in ? As of now, I am just using maelstrom's for great user unfriendly-ness.
and finally
(3) There are rumors on the internets that there is development on a new map engine. From what I hear, old maps will still work, however, do I need to consider working on optimisations for the new one? Would it be more efficient to bypass mapconv entirely and compile directly to Spring's format? I don't understand C++ very well and I don't feel like reverse engineering the source.
Thanks for your time!
Anyways, I have been working on a map editor for Spring in JAVA, since it seemed easy enough.
Here are some screenshots:
(requires Java3D)
and
As you can see, I have been trying to implement time-saving features such as transparency, streamlined compiling, and terrain preview. My guess is that people will still import images from outside programs.
Anyways, my questions:
(1) Mapconv.exe mentions a tile file to assist it in finding tiles. Because my program relies on tiles for the texture anyways, I was curious to know what the format of this tile file was.
(2) Would someone be interested in making a JAVA SMD creator GUI that I could plug-in ? As of now, I am just using maelstrom's for great user unfriendly-ness.
and finally
(3) There are rumors on the internets that there is development on a new map engine. From what I hear, old maps will still work, however, do I need to consider working on optimisations for the new one? Would it be more efficient to bypass mapconv entirely and compile directly to Spring's format? I don't understand C++ very well and I don't feel like reverse engineering the source.
Thanks for your time!
Ewww Java >_>
Either way you would have to rewrite code heavily -> UNLESS -> Good OO principles so that you could plug in whatever Map.Write you wanted
(DISCLAIMER: From what I understand) Spring's terrain format itself will drastically change with the next version of the mapping engine- mapconv and will have to be rerendered in the new uber-format, and i wouldnt surprsied if the current format is done away with entirely in v.99c or something.(3) There are rumors on the internets that there is development on a new map engine. From what I hear, old maps will still work, however, do I need to consider working on optimisations for the new one? Would it be more efficient to bypass mapconv entirely and compile directly to Spring's format? I don't understand C++ very well and I don't feel like reverse engineering the source.
Either way you would have to rewrite code heavily -> UNLESS -> Good OO principles so that you could plug in whatever Map.Write you wanted
Last edited by Dragon45 on 02 Mar 2006, 03:59, edited 1 time in total.
Hi nerd256, and welcome aboard.
First of all about your question tile file question, I found this in the wiki by searching for "tile":
I don't know much more about map making or the new map format, but you might want to PM our head developer Zaphod, since he's the one who talked about it (from what I remember). He said that the new map format would support bump mapping.
Keep up with the good work - I think it's great you're using Java, it's a very nice and clean language. The lobby server is written in Java too, even though some people don't know it - and it's working very well.
Finally, maybe a post in the maps forum would get you more attention, since most people that would have use for your program post there.
First of all about your question tile file question, I found this in the wiki by searching for "tile":
Check out the rest of the page here: http://taspring.clan-sy.com/wiki/Maps:CompilingYou should also put, if you are using them, your type map (Type.bmp) and your tile map (Tile.bmp). Most maps do not use these, so you do not usually need to worry about them.
I don't know much more about map making or the new map format, but you might want to PM our head developer Zaphod, since he's the one who talked about it (from what I remember). He said that the new map format would support bump mapping.
Keep up with the good work - I think it's great you're using Java, it's a very nice and clean language. The lobby server is written in Java too, even though some people don't know it - and it's working very well.
Finally, maybe a post in the maps forum would get you more attention, since most people that would have use for your program post there.
Okay, the optional map tag is used when you want mutiple maps to share an smt file... so basically you make 2 maps that have some huge part in common, then after making the first one, you specifi the smt it creates and if it can find the tiles it's trying to make in the smt it just references those in the smt of the second file...
also, if what you are making is just going to spit out the 4 neccessary image files that you need to feed into mapconv... make sure you use mother's specifications for the files, as it has more control of the final map http://taspring.clan-sy.com/wiki/Create ... rs_MapConv
if you are planning to basically remake the whole thing, then make sure I can choose which color grass is going to show up.
also, if what you are making is just going to spit out the 4 neccessary image files that you need to feed into mapconv... make sure you use mother's specifications for the files, as it has more control of the final map http://taspring.clan-sy.com/wiki/Create ... rs_MapConv
if you are planning to basically remake the whole thing, then make sure I can choose which color grass is going to show up.
- PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
Acctually, they both suck. However, this is not the thread for such arguements -_-PauloMorfeo wrote:On the other hand, .NET, which is basically the same, is the greatest thing in the world, is going to end world hunger and it is going to cure cancer.Dragon45 wrote:Ewww Java >_>
...
Ain't Microsoft's marketing machine great?
Moving along... This looks like a very promising project :) I remember hearing some people talking about making a map editor a few months ago however nothing ever got done. How well is it able to update the real time image? Like, are there 'tools' you can use to instantly change the topography of the level? Or the ability to paint textures onto the map? Will it render features in the map? Most of what I've just asked about are far in the future, but, oh well, call me overly hopeful Looks great so far, keep it up!
3)
I'm working on a different format and rendering of the maps (see this). I haven't set the format in stone yet. It will be based on a text file largely and specified as I implement it into spring. Because the old format and rendering will be the same, there are no new optimisations that can be done.
1) You should be able to look around in the tile loader to see what the format of the tile structures is. Since you know java this shouldn't be a big problem.
I'm working on a different format and rendering of the maps (see this). I haven't set the format in stone yet. It will be based on a text file largely and specified as I implement it into spring. Because the old format and rendering will be the same, there are no new optimisations that can be done.
1) You should be able to look around in the tile loader to see what the format of the tile structures is. Since you know java this shouldn't be a big problem.
Java sucks arse as anything but a "look what i coded in 5 minutes" thing. Same with .NET, .NET = M$ Java
As for this project, awsome idea, but forget about doing anything detailed, be simple and pipe into mapconv.exe when building the map. A GUI to create and sort all the RAW files, and one program to be piped to to create the final map = less coding for everyone, and less changes to code :D
As for this project, awsome idea, but forget about doing anything detailed, be simple and pipe into mapconv.exe when building the map. A GUI to create and sort all the RAW files, and one program to be piped to to create the final map = less coding for everyone, and less changes to code :D
- PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
- SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Not really. Java is almost as language powerful as C++ and has WAY more available libraries to work with if you go hunting. The real limitation of java is that although running through the virtual machine allows multi platform compatability quite easily it also robs alot of speed and robustness from the overal java runtime. Concequently java programming always feels a little bit teddy bear compared to C++ because the programs feel bloated and slow even when they really aren't that big.robed wrote:Java sucks arse as anything but a "look what i coded in 5 minutes" thing. Same with .NET, .NET = M$ Java
As for this project, awsome idea, but forget about doing anything detailed, be simple and pipe into mapconv.exe when building the map. A GUI to create and sort all the RAW files, and one program to be piped to to create the final map = less coding for everyone, and less changes to code :D
Re: Map Editor: progress and some questions
Unfortunately this code is all legacy SJ stuff, so I'm not so much of a help.nerd256 wrote:Anyways, my questions:
(1) Mapconv.exe mentions a tile file to assist it in finding tiles. Because my program relies on tiles for the texture anyways, I was curious to know what the format of this tile file was.
What I do know: The tiles themselves are 32px32p DXT1 format, the .smt file is essentially a collection of these tiles. I believe that after the initial SMT file header the tiles are just packed back to back- sans metadata. [But don't quote me on that last bit]
I think the mapconv feature you are referring to is for instances where there is a lot of overlap (i.e. multiple versions of a single map), and therefore you don't want to recreate the wheel. The map's .smf will reference all used .smt filenames, from which the pool of tiles is generated.
From what I [think I] understand- the .smt file format is trivially simple compared to that of the .smf file.
Without getting into the technical merits of Java...(3) <snip>Would it be more efficient to bypass mapconv entirely and compile directly to Spring's format?
If you plan on dealing with the .smt files, I would say that it is worth considering. The painful part of map compilation is generating those tiles [which is done by an external Nvidia toolkit anyhow].
Im pretty sure most of what mapconv does for you is trivial compared to what you're going to be going through to parse the features and generate a terrain preview.
Good luck with this, people will be thrilled to have it!
PS What did you mean by transparency?
Hehe, again the JAVA, C++, VB argument surfaces, better not get involved.
Addressing some of the questions in the thread:
I aim for the editor to be realtime, however, when editing giant maps (32x32), it is pretty much impossible to do it without lag (15sec for some operations) without switching to a faster language and library. However, I think this is better than trying to load a file into the GIMP, which miserably fails at creating the 2GB file. On a side note, I was able to write out the bitmap, but mapconv ran out of memory when compiling.
As stated before, I am using mapconv right now, and will continue to until I get the interface working more smoothly. I also use Maelstrom's SMD creator to configure the smd file. But the texture format I use is composed of tiles ( to save memory), so I should have the "painful part" done already.
By transparency I mean that you can set up the editor to see each layer superimposed on top of eachother. For example, you can line up the metal map with your metal texture, or view where the mountains are when making the height map.
But for now, I have a spring break, so I probably won't work on it this week.
Addressing some of the questions in the thread:
I aim for the editor to be realtime, however, when editing giant maps (32x32), it is pretty much impossible to do it without lag (15sec for some operations) without switching to a faster language and library. However, I think this is better than trying to load a file into the GIMP, which miserably fails at creating the 2GB file. On a side note, I was able to write out the bitmap, but mapconv ran out of memory when compiling.
As stated before, I am using mapconv right now, and will continue to until I get the interface working more smoothly. I also use Maelstrom's SMD creator to configure the smd file. But the texture format I use is composed of tiles ( to save memory), so I should have the "painful part" done already.
By transparency I mean that you can set up the editor to see each layer superimposed on top of eachother. For example, you can line up the metal map with your metal texture, or view where the mountains are when making the height map.
But for now, I have a spring break, so I probably won't work on it this week.
C++ > j00
It's small enough for basic tasks and powerful enough for big ones. Java requires way too much excess code (I have to instantiate an InputStreamReader object to read from the console? WTF?)
And yes, I can code both, so I'm fairly confident in my assertion.
And Java has more libraries!?!?!? How long has Java been out, versus how long has C++ been out?
The "look harder" argument holds no water
Edit: In fact, Morpheo, just about anything I can do C++, I can do in Java... of course because its Java, its far far more inefficient and just generally more painful...
It's small enough for basic tasks and powerful enough for big ones. Java requires way too much excess code (I have to instantiate an InputStreamReader object to read from the console? WTF?)
And yes, I can code both, so I'm fairly confident in my assertion.
And Java has more libraries!?!?!? How long has Java been out, versus how long has C++ been out?
The "look harder" argument holds no water
Edit: In fact, Morpheo, just about anything I can do C++, I can do in Java... of course because its Java, its far far more inefficient and just generally more painful...
Agreed. But I don't know C++.Dragon45 wrote: It's small enough for basic tasks and powerful enough for big ones.
If you include all the library code, yes, but I can actually spit out something (especially GUI) with a lot less code than C++. Of course this means I have to use some not-so-friendly coding practices...Dragon45 wrote: Java requires way too much excess code (I have to instantiate an InputStreamReader object to read from the console? WTF?)
Anyways, got something I ain't too embarassed of:
http://fileuniverse.com/?p=showitem&ID=2726