Map Editor: progress and some questions

[nerd256]

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!

[Dragon45]

Ewww Java >_>

(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.

(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.

Either way you would have to rewrite code heavily -> UNLESS -> Good OO principles so that you could plug in whatever Map.Write you wanted

[Dragon45]

Doublepost ftl.

[Gabba]

Hi nerd256, and welcome aboard.

First of all about your question tile file question, I found this in the wiki by searching for "tile":

You 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.

Check out the rest of the page here: http://taspring.clan-sy.com/wiki/Maps:Compiling

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.

[SinbadEV]

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.

[AF]

backwards compatability with the current map format is to eb kept. The future is multiple map formats not a new map format.

[PauloMorfeo]

Ewww Java >_>
...

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.

Ain't Microsoft's marketing machine great?

[Kuroneko]

Ewww Java >_>
...

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.

Ain't Microsoft's marketing machine great?

Acctually, they both suck. However, this is not the thread for such arguements -_-

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!

[jcnossen]

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.

[robed]

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

[FLOZi]

Java owns you all!

[PauloMorfeo]

And yet, i'm willing to bet that none of you 2 (Dragon45 and robed) even know how to program anything in Java and are basing your coments on what you read from other people.

Anyway, Kuroneko is right and i'm sorry for snatching this thread into a programming languages discussion .

[SwiftSpear]

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

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.

[mother]

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.

Unfortunately this code is all legacy SJ stuff, so I'm not so much of a help.

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.

(3) <snip>Would it be more efficient to bypass mapconv entirely and compile directly to Spring's format?

Without getting into the technical merits of Java...

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?

[nerd256]

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.

[SinbadEV]

Spring Break... heh...

[Dragon45]

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...

[FLOZi]

1.5 is a big step in the right direction for Java, don't overlook that.

[nerd256]

It's small enough for basic tasks and powerful enough for big ones.

Agreed. But I don't know C++.

Java requires way too much excess code (I have to instantiate an InputStreamReader object to read from the console? WTF?)

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...

Anyways, got something I ain't too embarassed of:
http://fileuniverse.com/?p=showitem&ID=2726

[Ajxl]

I think you are right guys! :)