Current Roadmap for next version

[zakath]

This is just a short update for what is happening with the next version of soldat.

* No portal.
* May be hardwareIds instead of the tagId from portal but its lowpriority.
* Bugfixes, we are focusing on stuff like map load times, fps issues, netcode issues and such.

Not sure if I missed something but then the other devs can fill that in.

[freestyler]

Are script features like InterfaceImage and such work as they did in 1.5.1 beta or they're deleted? Any other scriptcore updates?

[Mittsu]

i have a question regarding MM's statement from 2 months ago

Hey,
I haven't read the thread. Just wanted to say that we agreed with EnEsCe to release 1.5.1 as quickly as possible with disabled Portal functionality cause that isn't finished and was lagging the development significantly. As far as I know just the dedicated server needs to be compiled on linux. After 1.5.1 is out I will make further announcments for Soldat's future.

could you just finish that compiling and release the version as it is (obviously as long as it hasn't got some critical bugs)? It has some useful stuff (for example DM bug fix) and i think people are dying to get it already. You could release next versions with other fixes later.

[jrgp]

i have a question regarding MM's statement from 2 months ago

Hey,
I haven't read the thread. Just wanted to say that we agreed with EnEsCe to release 1.5.1 as quickly as possible with disabled Portal functionality cause that isn't finished and was lagging the development significantly. As far as I know just the dedicated server needs to be compiled on linux. After 1.5.1 is out I will make further announcments for Soldat's future.

could you just finish that compiling and release the version as it is (obviously as long as it hasn't got some critical bugs)? It has some useful stuff (for example DM bug fix) and i think people are dying to get it already. You could release next versions with other fixes later.

The current development versions of the soldat client and dedicated server are incompatible with each other. That must first be remedied prior to a release.

[Horve]

indexing most of the default textures or converting them to uber-compressed png's (obviously without any transparency) would greatly increase fps. Same goes for default sceneries.

Also, looking into creating a soldat tutorial would be recommended, but further discussion of this should be left for the suggestions thread.

Godspeed and don't fuck anything up.

[VirtualTT]

indexing most of the default textures or converting them to uber-compressed png's (obviously without any transparency) would greatly increase fps. Same goes for default sceneries.

This would only increase loading times... Pngs need to be unpacked in memory  before they can be used for rendering.

[jrgp]

Also, looking into creating a soldat tutorial would be recommended, but further discussion of this should be left for the suggestions thread.

As in fixing the manual or adding more useful things to the soldat wiki or something else?

[Horve]

indexing most of the default textures or converting them to uber-compressed png's (obviously without any transparency) would greatly increase fps. Same goes for default sceneries.

This would only increase loading times... Pngs need to be unpacked in memory  before they can be used for rendering.

That is most unfortunate, however I remember you mentioning something regarding a completely different file format for game graphics: dds, was it?

And by a tutorial I meant something like a map which would contain basic introduction to movements, a shooting range for target practice, introduction of all the weapons, an automatic turret which would fire at the player in order for the newcomer to learn to crouch, dodge, fly away and whatnot. I've found that many new players who join their first public servers for the first time get annihilated by more experienced players and then consider the game too hard, relentless and leave forever.
A single map like that would, in itself, not be enough, as the automatic turret would need to be scripted. The point would be to show the player how soldat works and then throw him into a server prepared.

[jrgp]

indexing most of the default textures or converting them to uber-compressed png's (obviously without any transparency) would greatly increase fps. Same goes for default sceneries.

This would only increase loading times... Pngs need to be unpacked in memory  before they can be used for rendering.

That is most unfortunate, however I remember you mentioning something regarding a completely different file format for game graphics: dds, was it?

Well what about converting the bigass bmp's to single-frame non-animated gif's? That'd totally lessen the filesize but I'm not sure about performance.

[VirtualTT]

indexing most of the default textures or converting them to uber-compressed png's (obviously without any transparency) would greatly increase fps. Same goes for default sceneries.

This would only increase loading times... Pngs need to be unpacked in memory  before they can be used for rendering.

That is most unfortunate, however I remember you mentioning something regarding a completely different file format for game graphics: dds, was it?

Well what about converting the bigass bmp's to single-frame non-animated gif's? That'd totally lessen the filesize but I'm not sure about performance.

Using animated gifs wasn't a good idea from the begging. Using simple non-animated gifs is even worse. Not even speaking that gifs aren't suitable for full-colored images. And they don't even support alpha channel.

Compared with plain bmp, gifs and pngs reduce file sizes greatly. However they need to be programmatically unpacked (this step is resource-consuming since good compression requires a lot of resources to decompress) and only then sent to video memory so they can be used for rendering. Plain bmps don't require any decompression so they can be sent to video memory with minimum transformations (e.g. properly byte-aligned). Unlike all those previous file formats, dds stores images in the way they will be represented in video memory. So image can be loaded into video memory directly from HDD. Moreover de/compression methods dds supports are hardware accelerated so such textures can be present in video memory in compressed state while GPU unpacks them on the fly without performance penalties. Actually this approach saves a lot of memory. That why dds and / or similar formats are used in majority of games.

However i think that various soldat performance issues aren't related to texture formats (except for gif). So i don't see any point in converting everything into png of dds.

[Horve]

<Vig> http://forums.soldat.pl/index.php?topic=37753.0
<Vig> is the polybug problem going to be addressed?
<Fryer> i've thought a bit about maybe trying to fix the polybugs
<Fryer> so i have some ideas about how to do that
<Vig> will it eradicate intentional bouncy polygons?
<Fryer> if i fix them i'll add a bouncy poly type
<Fryer> that will be stackable for more effect

[CheeSeMan.]

I just hope I can chase a low-hp efc without automatically dropping my weapon... and spawn without weapons reloading

anyhows sounds good! Good luck

[jrgp]

indexing most of the default textures or converting them to uber-compressed png's (obviously without any transparency) would greatly increase fps. Same goes for default sceneries.

This would only increase loading times... Pngs need to be unpacked in memory  before they can be used for rendering.

That is most unfortunate, however I remember you mentioning something regarding a completely different file format for game graphics: dds, was it?

Well what about converting the bigass bmp's to single-frame non-animated gif's? That'd totally lessen the filesize but I'm not sure about performance.

Using animated gifs wasn't a good idea from the begging. Using simple non-animated gifs is even worse. Not even speaking that gifs aren't suitable for full-colored images. And they don't even support alpha channel.

Compared with plain bmp, gifs and pngs reduce file sizes greatly. However they need to be programmatically unpacked (this step is resource-consuming since good compression requires a lot of resources to decompress) and only then sent to video memory so they can be used for rendering. Plain bmps don't require any decompression so they can be sent to video memory with minimum transformations (e.g. properly byte-aligned). Unlike all those previous file formats, dds stores images in the way they will be represented in video memory. So image can be loaded into video memory directly from HDD. Moreover de/compression methods dds supports are hardware accelerated so such textures can be present in video memory in compressed state while GPU unpacks them on the fly without performance penalties. Actually this approach saves a lot of memory. That why dds and / or similar formats are used in majority of games.

However i think that various soldat performance issues aren't related to texture formats (except for gif). So i don't see any point in converting everything into png of dds.

Was tga considered at any point?

[10th_account]

...

However i think that various soldat performance issues aren't related to texture formats (except for gif). So i don't see any point in converting everything into png of dds.

At least when it comes to load times, wouldn't it be an improvement to replace the BMPs with PNGs to reduce HDD read time?

[DarkCrusade]

PNG&APNG instead of BMP&GIF is the way to go. A good rate of compression, real transparency for animated stuff, no displaying issues caused by GIF.

I am so for hardwareIDs! Administrating servers is hard enough already, considering the flood of youngsters and hackers. If I ban someone, I don't want him to come back in 5 minutes.

[VirtualTT]

Was tga considered at any point?

Soldat already supports tga. However tga can only use RLE compression which often gives the files of the same size as bmp.

[Monsteri]

There really should be full Windows-7 and full-HD support.

[Jerkington XIII]

I am so for hardwareIDs! If I ban someone, I don't want him to come back in 5 minutes.

That. Go for it, so we can finally say Goodbye for good ol' troublemakerz(mainly m79 n' LAW-TKers and haxahs with proxies).

[Illuminatus]

full-HD support.

This would be 1920x1080-resolution which is not 4:3 like it should be for Soldat but 16:9 which would distort the image. So what you want is a higher 4:3-resolution than 1600x1200.
But still, it would look like shit because all the game-graphics (except the GUI) have a quite low resolution so it would look really fuzzy.

[Phobos]

Can libjpeg-turbo (http://libjpeg-turbo.virtualgl.org/) be used in Soldat? I think "no" as Soldat is in Delphi, but I'm not sure.