anything against the removal of the SM3 map format?

[abma]

FLOZi pointed to me, that SM3 map format seems to be not used at all. (something like, its used for 3 maps)

any point of keeping the SM3 map format?

there are "small" reasons to remove it:
- maintainance (more code = more time to maintain)
- compile time (more code takes longer to compile)
- executable size (= slower / bigger download)

also, SMF seems to be superiour to SM3:
- SMF should have all features SM3 had... so there is no point to use it
- SMF has two renderers
- fewer code (~6K lines of code, with two renderes!)

also, the existing SM3 maps can/could be "converted" to SMF.

[smoth]

toss that in the trash like rotten eggs. the format is dead and will not be finished.

[Forboding Angel]

Yep. Was an awesome idea, but implementation was QQ.

Maybe save the code in a bin so that later on if someone wanted to do something similar they wouldn't necessarily have to start from scratch?

[Beherith]

let it die

[Kloot]

Just comment out all SM3 .cpp's in rts/Map/CMakeLists.txt, leave the code for historical reference.

[abma]

thanks for the feedback, removed it:
https://github.com/spring/spring/commit ... da74c9dc05

[Anarchid]

It's sad to see SM3 go, even if it never really did go anywhere. By same measure i'd be sorry to see parallax support removed - even if it's also not really useable.

- SMF should have all features SM3 had... so there is no point to use it

The killer feature of SM3 is nowhere around SMF.
You still have to use an obscure unsupported platform-dependant, badly documented and slow third-party tool to produce an SMF.
SSMF being able to pick up non-contrived formats for advanced stuff like normals and speculars doesn't really help here.

[Beherith]

Anarchid, GTFO of this thread. You have no idea what you are talking about.

[Anarchid]

You have no idea what you are talking about.

What, you don't need mapconv to make smf anymore?

I remember making an sm3 without. It was shit, but it didn't need compiling.

I'll mourn that promise.

[The Yak]

What maps exist that are SM3? Are they worth converting?

[Forboding Angel]

The only 3 sm3 maps worth mentioning are ones that I did. Whakamatunga riri, metal heck, and narrow passage.

All had issues with random sm3 fail except narrow passage, which was kind of the prime sm3 example map.

Argh made an sm3 map as well that didn't fail too badly.

Sm3 was a great idea, but in practice it just doesn't work out.

[The Yak]

Narrow Passage looks alright, but SM3 texturing seems completely different then what is used now. It would need a retex and other things.

[smoth]

The biggest reason for SM3 is that you didn't have >9001 tiles which is a big issue. The smf format can be quite taxing with large maps and while I do get the whole pathing is an issue, not having to shuffle around all those damn tiles and not having them all floating around taking up video memory and handled I am not sure there is an easy solution. I think tiles are a backwards way of dealing with things. Most of the modern rts games seem to use both mesh, decal and tiled texturebased solutions. SM3 would be relevant if anyone is working on it. Which they are not. Even still it was written so long ago, who says it is still usefull? There may be better approaches now. As it stands the old code was like a vestigial organ, it had a purpose once upon a time but now is useless.

Any of forbs work with SM3 could be destroyed by his SMF work. JUST PULL OFF THE BANDAID! Before anyone goes "but what about the good maps" the ones you never play? for has like 100 maps I seldom see any of you lot play them and many of them are very fun to play on!

[Forboding Angel]

...forb has like 100 maps I seldom see any of you lot play them and many of them are very fun to play on!

It's getting very close to 200 now

[HeadHunter]

I am very much against removing it - sm3 allows for dynamic map generation. As in, creating maps via scripts and stuff like that. sfm is nowhere near that, as simply rendering a map takes ages. File size is a huge issue as well, and I see no reason to just throw away the new format. Maybe a better idea would be to have a decent documentation for sm3? I mean, the only way to really understand what is happening with the format and how to use it is reverse engineering narrow passage - not exactly my idea of "fun".

Bottomline is - I'd suggest actually making a converter from sm2 into sm3 and supporting sm3 only instead - that should not be hard as sm2 is basically sm3 with only one layer, right? I think that may actually be a better idea in the long run, as sm2 is really really stinky when you are making a map - as in you need a HUGE bitmap, which is not exactly easy to handle.

[Forboding Angel]

You aren't even remotely in the ballpark of being close...

[HeadHunter]

Maybe you could be more specific? As a map maker I never could produce a working sm3 map that would work because of how honky the docs used to be. Later the doc improved but nobody really promoted it - so here we are using a 10-year old tools in a brand new game. And I am not kidding - sm2 is really about 10 years old! I just do not believe it is the best we can do.

[smoth]

Sm2 HAS been upgraded greatly and now exceeds sm3. I don't know what rock you crawled out of under but sm3 had a lot of issues. Want speciffics, too bad that wss years ago and now I have forgotten. I am not wasting the time to go dig it up. You say the docs were wanting but I had no issue the format was never finished not the docs. It was a failed experiment. Your point abour the compiler being 10 years old is moot the tools mappers like myself behe and forb uwe to generats our maps are not.

I am always happy to see some return but as far as I can tell you only want as sm3 out of academic interest or you want something "new" instead of for functional reasons.

[HeadHunter]

Smoth, I get your point. The point that I was trying to make is that sm3 is a much more flexible format with a much more compact representation. Tell me, am I wrong that you still need a huge texture for sm2 that covers the entire map?

Quote: "Caution
The larger the map the greater the file size this texture will be, a 4x4 map at 2048x2048 the diffuse texture image is already at 5.4mb, imagine a 32x32 size map, it would be in the hundreds of megabytes. Working with large textures is difficult, and requires good hardware. " - that is so fucking true! And what it also means is that all of that has to be stored in your video RAM as well! Which means big maps have to look like shit to compress better - or they will not fit. Is it good? you tell me. Is sm3 a solution - maybe not a good one. But we do need one.

[smoth]

sm3 is not worth the time. I am extremely jaded and when it comes to idea guys who show up out of nowhere I am also hostile. So I am not a good conversational partner. I will recommend sinbadev, this is more his area.