Spring RTS Engine

IMSabbel wrote:

SwiftSpear wrote:

TA 3D wrote:Thats your only hope, seeing as the SJ's made this for older card texture space limits of 2048x2048. Newer Nivdia cards can support up to 8035x8035 texture space.

Well just have to wait for the new model format, and UV mapping.

You are drasticly misinformed as to the reality of and signifigance of that figure. Doom3 and HL2 both used some texture maps larger then that and radeon cards still outpreformed Nvidia cards in visual quality. Dispite the fact that the new Geforce cards have better preformance ratings then the current top of the line ATI cards, ATI's mid range cards still give you way more bang for your buck then the geforce equivalents. If radeon cards couldn't handle texture planes larger then 2048x2048 no one with a radeon card would be able to render the TAS world maps, as most of them are texture files in excess of 10000x10000 pixles.

Sorry, neither hl2 NOR doom3 used any texture map bigger then 2048x2048.
In fact IIRC correctly, the largest single texture in doom3 was <1024x1024.

but reading your last two sentences... URG. do you have a clue?
Its not like meshes have to use a singly polygon... did you ever think that maybe one can just use 4x4 1024^2 tiles.
Do you have a clue WHY games look better on one architecture than another? like pixelshader precission, AAF algorithms with different angle dependency and mipmap range, for example?
_Please_ dont sprout nonsense here. Youre tone gives the impression that you know what you are talking about, and we dont want noobs to believe in bullshit, right?

Also, did you ever even LOOK at the terrain in spring and notice that the texture map is at a MUCH lower resolution than you think (which is masked by detail texturing)?

They may not by default, but I've used bigger texture maps before and had them work fine :/

They support large texture maps pretty effortlessly. Oh, keep in mind, the model textures are much higher resolution texturemaps then the terrein textures in HL2 and Doom3... They both use 512x512 terrein textures with the very rare larger texture for huge faces. Some models use multiple texture maps so it can be a little deceptive, but you can put a huge ammout of texture information into a single map and it still works.

Spring maps don't compress thier textures into 2048x2048 squares. Most likely they tile. That doesn't change the fact that I'm illistruting, which is that it is still very possible and easy to draw single faces with way more then 2048x2048 pixles in texture information, let alone full models.

I'm not convinced there is any difference in the max rendering potential of nvidia cards compared to ATI cards as I have yet to see any design specs that indicate that. But if there is, rest assured there are effective workarounds in place and it's not a reason to buy one card over another. There are alot of nonstandard things Nvidia does in thier rendering that ATI fanboys have been attacking for years, so it really isn't like a max texture size difference is the one different factor between the cards that should be used to determine which is better.

War at sea is all fixed up (thanks heaps to kuroneko!)

check it out

http://www.fileuniverse.com/?p=showitem&ID=1667

Well, just like ATI had much better than ps2.0 pixel shader capabilities than nvidea with its "oh we cheat and recompile to integer shaders in the driver because fp32 performance sucks" policy.

But thats not the point.
The point is that the "all unittextures into one texturemap" approach is a godawful hack that wouldnt get better just because you make that one texture larger.
For once, it breaks the fragment caching of most modern graphic cards, plus messes around with the agp/pci-e texture memory handling (as even oh-so-great nvidea cards dont support virtual memory like some of the 3dlabs cards and can either swap out a texture or keep it local)

But it will certainly be changed soon...at least it's what I can see from this :
http://cvs.sourceforge.net/viewcvs.py/s ... iew=markup

That would be really nice.
I heard of it months ago, but i followed every cvs commit the last quarter and found no commits that seem to touch that matter.
So i was a bit annoyed, because i hate seeing hard work wasted (for example by doing optimisations to get something to work in the current model format only to have it obolete later)

edit:

but a big YEHAA! at those specs. Refraction and specularity map with an option for future bump-mapping...

almost need a development topic devoted to textures rather than war at sea at this rate (hint hint)

ahhh.
Back to the topic :)

I personally LOVE naval battles (mostly because of the lack of terrain and the detailed units )...
My gripe with ota and xta naval battles were always the small weapon ranges compared to the ship sizes. Its true for land units, too, but with battleships that always resulted in ungainly piles of metal stuck together...



Well, with the new unit format (and increased weapon numbers), i would LOVE to see a Yamato after the second refit in spring in one mod or another...
(the one that installed the additional AA gear.
Just imagine a battleship with:
3*3 45cm Main guns
2*3 15cm Main guns

52(!)*3 25mm AA gun (drooooool)
12*2 12.7mm AA maschingun
and aircraft launch capabilities

Hey, isn't there support for mobile units building mobile units now?
Imagine a multiplayer skirmish on a 28x28 purely sea map, you get a fleet of battleships and torpedo boats (no pure cons though) at the start and some of them can build and launch spotter planes (real long build time, or only enough metal to build one or two ... challenge is to find enemy and destroy them- really have to think about strategy then (arcs of fire) etc.

mecha wrote:Hey, isn't there support for mobile units building mobile units now?

I think support for mobile units building mobile unit was there since first Spring release. Just, the unit built are built on the land, like if they were building, and becomes mobile once finished. So the planes would have to be built on the sea floor, next to the boat.

zwzsg wrote:

mecha wrote:Hey, isn't there support for mobile units building mobile units now?

I think support for mobile units building mobile unit was there since first Spring release. Just, the unit built are built on the land, like if they were building, and becomes mobile once finished. So the planes would have to be built on the sea floor, next to the boat.

How do shipyards decide where to get built? they always end up on the surface of the water irrelevent of the depth it is.

IIRC its an .fbi tag. Unless I'm wrong it is "CanFloat=1;"

Doesn't appear that way.
My guess is, waterline in combination with yardmap?

FizWizz, you are wrong. "CanFloat=1;" doesn't even exist as a FBI tag. There is a "Floater=1;" tag, but that is used only by boats. Hovers don't even have "Floater=1;" and Pelican has a strange "Floater=0;".

You can check, not any floating building has "Floater=1;"

What makes building be built on ground, water surfaace, or sea floor, are the tags:
MaxWaterDepth
MinWaterDepth
YardMap

If the yardmap is made of y, o, c, g, G, O, f, then the building is either ground, underwater, or both.

If the yardmap is made of Y, w, C, then the building is floating.

Ground and underwater yardmaps:
- y=left free
- o=always occupied
- c=open when open and closed when closed
- O=ground, closed when open and open when closed
- G= geothermal vent
- g=geothermal vent
- f=feature(????)

Floating yardmaps:
- Y=left free
- C=open when open and closed when closed
- w= part above water


A typical ground building uses:
MaxWaterDepth=0;
YardMap=yocoy oocoo yocoy;

A typical underwater building uses:
MinWaterDepth=31;
YardMap=yocoy oocoo yocoy;

A typical amphibious land and underwater building uses:
YardMap=yocoy oocoo yocoy;

A typical floating building uses:
MinWaterDepth=30;
YardMap=YwCwY wwCww YwCwY;

Amphibious land and floating building is not possible. A water yardmap building can't be built on land. You'd have to make two separate buldings.

(That was from TA, and not re-tested on Spring.)

If any one is interested in taking over completing the port of War at Sea to spring... It'd be good to see a mod that Imp put a lot of work into make it to being truly playable in spring(provided he hasn't got anything to say to the contrary that is). It could look even more impressive given some effort. What has been done to FF is pretty inspiring. Have a look over the previous posts for some of the pictures showing it off.

This time do not hijack this thread for completely unrelated arguments about technology... you know who you are ...disappointing

Imp had posted here that he had lost all his work on War at Sea in an HDD crash. Bad news.

Yeah I saw that... The original release is still excellent work though even though it doesn't have the updated ships. We didn't even integrate the british ships expansion for the OTA version. This is still on FU. Imp may have lost his work but that doen't mean that the mod is a lost cause. (Its buggy but playable)

is anyone still working on this?

Nope, go for it. Could be an awesome mod... most of the modelling has already been done courtesy of imp. whats on FU is what exists. Heaps of scope for ramping up the weapon and smoke effects. Could even be integrated with AATA for distorted historical warfare.

mecha wrote:Nope, go for it. Could be an awesome mod... most of the modelling has already been done courtesy of imp. whats on FU is what exists. Heaps of scope for ramping up the weapon and smoke effects. Could even be integrated with AATA for distorted historical warfare.

I might just revive this but i need some more info aswell like other forces any other buildings if there are any it might take some time aswell 'cause im lazy
i mucked around with the second alpha which STILL works needs build pics im going to be busy. ps i have no modding skills whatsoever wish me luck

good luck!