Spring RTS Engine

Well, if you can't work out how to make a decent entry into this competition, don't? Imagine if you turned up to F1 and said "yeah, these cars are kind of stupid and pointless because they are attached to the ground so today I will be competing in this here 747"

I am tempted to play too but will need a few days since not at home right now.

Silentwings wrote:Imagine if you turned up to F1 and said "yeah, these cars are kind of stupid and pointless because they are attached to the ground so today I will be competing in this here 747"

That isn't an even remotely comparable situation...

I feel that this competition is semi-worthless if not using the latest methods

I want to see you enter a 64kb demoscene contest with a 64mb entry, on the ground that Java is a better language and assembly obsolete.

That is the dumbest argument ever, in context.

You win 1 free internet.

but is your arguement

No, my argument is that it is worthless to flood spring with more crappily textured maps using old mapping methods. What is not worthless, it more maps using the latest methods and minifying them as much as possible, demonstrating that less really can be more without sacrificing quality.

You, on the other hand, just want a bunch of maps with shitty textures and low filesize, which is pointless, because spring has hundreds of those already.

Then start your own competition. Knorke set clear enough parameters; If you don't wish to abide by them, do your own thing, but don't waste everyone's time complaining about it in the rudest manner possible.

Forboding Angel wrote: And cheese, this is for you, in the hopes that you might read it.

Well Forb you know that very little knorke does makes practical sense. But nobody forced you to enter either. When you decide to enter, you should at least feel obligated to follow the rules. Besides, there's a lot of room for unconventional solutions using lua. There's no need for all this bickering..

Here's a 39kb normal map:

Compressed in 7zip it's only 23kb. That's 22 of these in 512kb. I'm pretty sure very few people could tell the difference between this and the original 4mb version ingame.

random tip: uncompressed png compress better in 7zip then compressed png.

Funkencool wrote:random tip: uncompressed png compress better in 7zip then compressed png.

That's a jpeg. Png is too beaucoup.

no, I meant png

and that's just with a small image, its much more noticeable in large

Ah I thought that was directed at the image I posted. Png was never an option given the size limitations, since there's a factor 10 difference between lossy jpeg and lossless png.

ahh ic I guess I've never mapped with jpeg or was that just for the forum? Does jpeg work well/at all for mapping?

Cheesecan wrote:since there's a factor 10 difference between lossy jpeg and lossless png.

Depends on the image. For a photo, yes, jpeg is better. (jpeg would have much smaller filesize, data loss invisible to the naked eye).

But for something like a schematic image with pixel-perfect straight and sharp lines, png is better (png would have both smaller filesize, and better quality).

Exemple: On a 512x512 white background I drew a black cross made with two 48-wide lines. Saved as png, the file is 2k. Saves as jpg with 99% compression, the file is 6k, and the artefacts are visible even when zoomed out.

Funkencool wrote:ahh ic I guess I've never mapped with jpeg or was that just for the forum? Does jpeg work well/at all for mapping?

No, that would be counterproductive. But in the case of say a specular map or grass map that has had gaussian blur applied, nobody is going to be able to tell a difference without closely inspecting screenshots side-by-side.
That said, I noticed Forb already did this here now.

Cheesecan wrote:

Forboding Angel wrote: And cheese, this is for you, in the hopes that you might read it.

Well Forb you know that very little knorke does makes practical sense. But nobody forced you to enter either. When you decide to enter, you should at least feel obligated to follow the rules. Besides, there's a lot of room for unconventional solutions using lua. There's no need for all this bickering..

Here's a 39kb normal map:

Compressed in 7zip it's only 23kb. That's 22 of these in 512kb. I'm pretty sure very few people could tell the difference between this and the original 4mb version ingame.

Dude, how, after all this time, do you not know the difference between splat and normal map? Are you just getting mixed up about them? I could understand that, but 3 times I have said this in different ways. 1 is an oops, twice is a coinkydink, 3 times is O_o.

The splat map is 4mb. It can't really get any smaller filesize than that. (It can, but you wouldn't like the results ... Your splats will look pretty fugly)

Fact of the matter is, your splat texture is 4 images baked into one, so trying to save filesize in that portion is a "good luck!" sort of deal. I tried several different formats and honestly, tga ended up being the most useful overall. Go figure.

The normalmap for this is 282kb, so I dunno what you're on about, wrt normalmaps.

zwzsg wrote:Depends on the image. For a photo, yes, jpeg is better. (jpeg would have much smaller filesize, data loss invisible to the naked eye).

But for something like a schematic image with pixel-perfect straight and sharp lines, png is better (png would have both smaller filesize, and better quality).

That's true in principle. As someone who has used CAD a lot (for example for scanning in landscape maps and then using them as background in CAD software), I have noticed that jpegs are almost always better, even if png theoretically would be the best solution here (landscape maps have few colors, like blue for water, red for roads, black for houses etc).

For a given quality, jpegs will almost always produce smaller file sizes (and better transparency too, although png:s should be good at that in theory). Earlier before the png:s were invented, there was the same discussion between jpgs and gifs.

Feel free to correct something. It's all empiric from my point of view.

For a given quality, jpegs will almost always produce smaller file sizes (and better transparency too, although png:s should be good at that in theory)

What do you mean "a given quality"? png is loseless, quality is always best since the image is not altered.
transparency with jpeg sucks because:
http://www.faqs.org/faqs/jpeg-faq/part1/section-12.html
The problem is that a typical alpha channel is exactly the sort of image that JPEG does very badly on: lots of large flat areas and sudden jumps.

Yeah, that's the theory. But in practise, I say that jpeg works better with at least Autocad.But bear in mind, the quality I am talking about is the resolution of the final autocad drawing, that means combining a scanned image (what autocad calls raster image) with vector graphics, including transparency. For a given resolution, jpeg yields a smaller file size, and it also manages tarnsparency better. No idea how they do it then.

I guess i mean with this:

What do you mean "a given quality"? png is loseless, quality is always best since the image is not altered.

That jpegs compress better because they are lossy.

It's not purely theorical.

Here is a practical exemple where PNG is better on all counts:
The metal map of my latest map.

PNG : 1 214 bytes, sharp
JPEG : 2 480 bytes, blurry