Spring RTS Engine

Pretty much all of what smoth said is right on the money.

No one has a gun to your head asking you to download it. If your internet sucks, maybe you should do something about it.

Reducing filesize would be nice, but I refuse to do it at the expense of quality.

I had a thought. What if a new map file was included, this file would allow you to control the detail textures. Basically, a color points to detailtex1, detailtex2, detailtex3 etc, and defines where it would go.

This would allow us to stop baking on bumpmapping, and just use elaborate detail textures instead, which would drop filesize big time. The only thing is tho, the detailtex would HAVE to be visible no matter how far zoomed out you were.


Anyway, there is a good suggestion, unfortunately, I doubt any of the devs care enough to implement something like that, but I'd like to be wrong...

dude, you're not understanding me. I could give a flying crap about sm3, as JC has no interest in developing it in spring, so the least that could happen would be that we could control detail mapping for smf. That would be made of win.

Just compress the damn map...

TradeMark wrote:Just compress the damn map...

:idea: Just stop asking before you get flamed

Why would i get flamed...

KingRaptor wrote: :idea: Just stop asking before you get flamed

You gotta understand that this is an old argument that we are tired of hearing

Forboding Angel wrote:The only thing is tho, the detailtex would HAVE to be visible no matter how far zoomed out you were.

AFAIK the detail textures are rendered when zoomed out, but it is so small that it is only a little 2x2 or 4x4 noise texture and when zoomed out more it's just a 1x1 solid color texture. (Just calculate which mipmap level would be used at a certain zoom level if you want it proven)

Allowing different detail textures to be set sounds like an interesting idea tho. (Even the 1x1 solid color mipmap of the detail texture can tint the tile)

Anyway, there is a good suggestion, unfortunately, I doubt any of the devs have enough time to implement something like that, but I'd like to be wrong...

fixed

*spam*

The problem with large maps is that the game starts when the player with the slowest connection finishes downloading the map. At that point, most of the other players, tired of waiting, will have left. The game might never start, despite the number of actual map downloads.

I just wonder, what the hell are you trying to protect in your maps by saving them with zero compression?

(Deserted Sinkhole 28x28)
When i zoom in, i just see ugly pixels:


Dude. Just compress the maps, and maybe those pixels will fade a bit too?

Funny...some maps you zoom in and see annoying gray squares.

TradeMark wrote:I just wonder, what the hell are you trying to protect in your maps by saving them with zero compression?

(Deserted Sinkhole 28x28)
When i zoom in, i just see ugly pixels:

Dude. Just compress the maps, and maybe those pixels will fade a bit too?

Trademark, what happens when you zoom in really close on an image in photoshop? Now what exactly do you think you are doing there? You are zoomed in enough so that the detailtex starts to show, therefore... Besides, I know what causes that stuff (the stuff you are thinking of) and imo it's not a big deal.

FACT, running compiler with .5 compression and then sd7ing the thing YEILDS THE SAME COMPRESSION RESULTS as .0 compression in the compiler and then sd7. They come out to the same size. BTW the compiler compression is really, really, bad on the higher ends.

THere is a thread about it in the mapping forum.

Back to my vacation...

It doesnt always end up to the same size, depends on the textures.

My point was, that you dont want to compress your maps by the compiler, because it makes your maps look worser, but actually you can see the bad looking things only when you zoom in. And now i zoomed in, and i still can see bad looking things. So whats the point to not compress maps by compiler? Try it.

You once made some remake of "king of the hill" map, and i noticed the file size was 10 times bigger than the older release, you didnt answer why, but now i know: you didnt use compression. So there is at least one evidence that it works.

TradeMark wrote:My point was, that you dont want to compress your maps by the compiler, because it makes your maps look worser, but actually you can see the bad looking things only when you zoom in. And now i zoomed in, and i still can see bad looking things. So whats the point to not compress maps by compiler? Try it.

The point is that the compression can make the texture look bad, zoomed out not zoomed in. Hell nearly everything in Spring looks fugly as all hell when zoomed which is why no one spends a lot of time with their (figurative/imaginary) camera lens shoved halfway into the ground...

Irregardless of all this discussion of whether compressions should be used or not its still Forb's bloody choice and he'll do as he wants. Just like you, Trademark, will continue to make speed maps the way you are. No one can really stop you so why don't we all just stop wasting our energy trying to make other people do what we want and get back to making stuff... or playing stuff.

TradeMark wrote: You once made some remake of "king of the hill" map, and i noticed the file size was 10 times bigger than the older release, you didnt answer why, but now i know: you didnt use compression. So there is at least one evidence that it works.

You fricking dumbass, get out of my thread and stop making claimes you know NOTHING about!

God, I cannot deal with this level of incompetence, ffs!

If you were as smart as you think you are, you would hav noticed that there are many more texture layers in the new version of KOTH. You would also notice that there is bumpmapping.

More textures + bumpmapping = large file size.

Go away! I'm tired of trying to be nice to this nitwit.

Look Trademark, I am not going to spend a lot of time getting it through your thick skull why compression via compiler has no real benefits but I will tell you this, The compiler starts adding really bad artifacts at a compression 1+, most notably wavy lines all throughout the texture. It also causes significant blurring of the texture at less than 1 compression.

Something else your highness should know... The benefits of filesize in compression .5 - 1 are negligable (roughly about 5 megs worth).

And last but not least, if you compile a texture at .5 compression, and then compile the same map at 0 compression, then put them both in seperate 7zip files, the final filsize is almost exactly the same.

Posted a long time ago concerning ^^ http://spring.clan-sy.com/phpbb/viewtopic.php?t=8418

Now fuck off, I am tired of your personallity.