Use the PNG support already present in the client

[m_bee]

Reading these words from CK, I though that the thing about wav/ogg could also be applied to the bmp files that we have:

 

http://www.eternal-lands.com/forum/index.p...opic=26253&hl=#

 

Why dont we use the png format instead of the bmp files?

 

The advantages would be those:

 

1-We would be able to use 16 or even 32bits images for maps, objects and even more things in the future without having 1mb files for the maps (bmps are currently 258k size, and they are only 8bits colour, that sometimes look a bit crappy imo).

2.-The textures in the interface could be impreved as well.

3.-AND VERY IMPORTANT, we could use alpha channels in the png files, that means transparencies without ugly tricks, and, without -wich is more important- trashing the images that cointaing black on them. That would also be useful to take rid of the background of the clock and the compass when pressing f6 to make the hud transparent (could be easily done with a mask too, of course, but alpha in pngs would be cleaner, I think).

 

Are there any plan to do this?

 

The main problem: I dont know how complete this support is. But since the client uses libpng, the functionality should be easy to add. Another problem is that the windows client -wich currently is compiled without libpng and cant make shots- will need this library to install and run EL. I dont know if there are issues about this.

 

Please, illustrate me.

[Roja]

this was discussed previously in this forum somewhere.

 

The conclusion was that there wasn't a need for png support. bmp works just fine.

[m_bee]

Well, I think that to use that png support would be better, because of the image quality and the file size, but that is my opinion, of course.

 

Anyway, then the only objetive of the png support was to include a function to make screenshots? That is a thing that I cant just understand... Cause then bmp would be equally valid for that purpose...

 

EDIT: Plus the fact that I cant understand why are we adding an additional dependence to link against libpng.so /dll if we can do it in bmp and it just works well.

Edited June 26, 2006 by m_bee

[Torg]

BMP should never be used due to the size. However, Ent refuses to add another dependancy, and that is why the PNG support is optional, but only for screenshots.

 

I was planning on converting over all the image stuff to PNG as the code is mostly there, but I have been informed that it won't be approved. Basically, I completely disagree with Ent's decision, but there is no point fighting over it.

[Roja]

it's not such a big deal really. I don't really care what happens either way unless there's some major advantage to having png's that i'm yet unaware of.

 

yes bmps might be bigger on your hdd, but at least for the game download they don't take up more space compressed. The image quality for bmp's would only be worse if you don't know what you're doing when you save the files, because visually to the naked eye there's no difference unless you analyze the pixels.

 

also with the alpha channel in a png file, that would make the file bigger anyway.

[ttlanhil]

also with the alpha channel in a png file, that would make the file bigger anyway.

not really. since PNG has compression (the non destructive sort, like zipping up a file), a photo-type picture will be about the same size, maybe a little larger... images where there's a lot of the same colour (like a red circle on a white background) get compressed very well. there's a slight increase in processing time(a minor issue compared to the 3d stuff that's already done), but el's BMPs converted to PNGs at the same colour depth come out to roughly the same file size (at first I made the mistake of 8bit BMPs to 32bit PNG, which made them come out about 1.5x the file size)

 

PNG would be a lot better than BMP for stuff like icons. for example, the ones in the hud, especially if you have transparency; then you can change the background pattern without having to change each button.

file size, since it's a non-complex image, can go down a lot for things like this (the tab-maps, on the other hand, don't save much size)

 

the ability to alpha blend the images without the need of a seperate alpha image is probably the only significant issue

[m_bee]

it's not such a big deal really. I don't really care what happens either way unless there's some major advantage to having png's that i'm yet unaware of.

 

yes bmps might be bigger on your hdd, but at least for the game download they don't take up more space compressed. The image quality for bmp's would only be worse if you don't know what you're doing when you save the files, because visually to the naked eye there's no difference unless you analyze the pixels.

 

also with the alpha channel in a png file, that would make the file bigger anyway.

 

There are two ways to make the HUD look well.

 

1.-Using masks, hard to implement, lots of new code, probably bugs, and separate files for the mask and pictures, wich is another problem. Plus, as ttl said, images with few colours have a good compression ratio with png, while bmp is 258k size in 512x512x8bits, it does not matter wich file you choose, since there is no compressions at all. The size of the pack is larger, that is another handicap of the bmp format.

 

2.-Using native alpha support present in png, as ttl also well said, the alpha is in the same png file, as a sort of transparency, no need to use masks, cleaner code, faster develpment, no bugs due to that part of the code that draws the transparency using the alpha channels, since the suport is in libpng ans well tested.

 

Of course, the other option is to leave the HUD remain crappy forever. Choice is yours as always Another thing, is that you will have the real transparency support for the icons in the enciclopedia, inventory and the rest of windows (no more black backgrounds). Of course, images would need to be edited to include the alpha, but that is a trivial task in anything like photoshop or the gimp. And saved as png.

 

An example that you can check easy, Roja.

 

A tipical example is that in html pages PNGs are needed when the image above has to let you see some parts of the image behind it, only png can do this. Jpg and bmp do not support transparencies at all. This would make the possibilities regarding the customization and fancyness of the interface a lot more nicer than they are right now, if you ask me, that is an advantage. In the html example, if you dont want to use pngs, you need to paste the buttons of whatever in your graphics editor, melt it with the background so the transparent effect is archieved as a fake, wich will look like crap is the relative position of the back and fore images is changed a bit (and that, in web stuff is always since each browser does the things its own way).

 

Anyway, you have the last word, but... if png is going to be used for that crap only, I would remove it from the code. No one needs libpng as a screenshooter, it is like liking against directx to add a screenshot function, weird. IMO.

 

EDITes for typos.

Edited June 27, 2006 by m_bee

[Roja]

Ok well first off we already have alpha support-sure it's another file, but it's not a big deal so the HUD can probably incorporate the alpha maps too. As for this comment "other option is to leave the HUD remain crappy forever"...well, the interface isn't crappy at all currently. sure if you press that f9 mode or whatever it looks that way, but that thing really isn't used much afaik, nor do i care about it.

 

I'll have to do some testing to see how big the png would become with the alpha.

 

I did testing before with bmp vs. png. uncompressed, the bmp is bigger. compressed(zipped), i believe the bmp was smaller(or at least the same size). I did post this in a thread in this forum a while back. So for the download pack there's no advantage to using png. it would then be hdd for space, which sure, the lesss it takes up the better as always.

 

Again, I really don't care which way we go with this. I will talk it over with entropy if one of you are willing to go all the way for full png support, however realize that this isn't my decision to make as it deals with programming-it's his.

[m_bee]

Ok well first off we already have alpha support-sure it's another file, but it's not a big deal so the HUD can probably incorporate the alpha maps too. As for this comment "other option is to leave the HUD remain crappy forever"...well, the interface isn't crappy at all currently. sure if you press that f9 mode or whatever it looks that way, but that thing really isn't used much afaik, nor do i care about it.

 

All de devs, including graphists, should care about this. The interface is the first thing that a person sees when entering this game -or any other game, in general.

 

Let me explain myself in a softer manner. Bugs are not only compile-time bugs, or incorrect values or layout in the screen, or issues directly related to the programming thing. Interface bugs also exists. If a thing works, it is supposed to work most times and under all possible circunstances in the best possible way. If you provide an option -F6- to change the interface in any way, it is also supposed to work. And an "I dont care since it is optional" does not remove the bug. It is still there, just hidden, but it is there. The obvious solution, would be to remove the F6 thing from the client.

 

I'll have to do some testing to see how big the png would become with the alpha.

 

Simple bitmaps with simple transparencies and no blending on their surroundings will not differ much in that matter from not having an alpha channel. You can think of the alpha like of an additionanl bmp file with the mask, it the file has two colours and no grandients -aka blending- the compresion on png will make the alpha channel size ridiculous. That will open possibilities like adding light/tinting effects on object if you pick them and things like that in the future. Or even in door when you hover them... just imagine.

 

Of course, we would still need the masks for the clock and compass to fix the weirdness in the hud, and that is why you should worry about this It does not matter if it is in a mask file or we have a png with alpha channel, it would need to be done.

 

Again, I really don't care which way we go with this. I will talk it over with entropy if one of you are willing to go all the way for full png support, however realize that this isn't my decision to make as it deals with programming-it's his.

 

Of course, the decission is from both of you, owners and creators of the game. I was just a bit surprised that we are using libpng just for a marginal functionality, and that is why I though of reviving this thingie and hear opinions from you and the rest of contributors to the client code.

 

PS: BTW, to put at least 16bits images in the minimaps wouldnt hurt, anyway, but that is a secondary thing that I dont care too much at all about. Still, it would look nicer.

[Roja]

the problem with the minimaps is not about their bit size but about their pixel size. 512x512 doens't look great when your screen res is higher than that.

 

Of course I agree that the interface is very important, but people do not see the f6 interface when they first log into the game. a lot of players don't even know it exists so there is no harm in having it ther,e although there is no reason to have it either. There are many things in this game that are not finished, and that f6 interface thing is one of the very least important things. so that's why i don't care about it.

 

One question for you, there is some sort of mip-map support in the client. however i don't think it works on static objects. it would be nice if it did because then when you zoom out the details in the textures won't flicker as they get smaller. Is there anyway to make mipmaps with png files or something? I know the dds format uses mipmaps, but that's for directX..i don't know if it's compatible with opengl.

[m_bee]

the problem with the minimaps is not about their bit size but about their pixel size. 512x512 doens't look great when your screen res is higher than that.

 

Of course I agree that the interface is very important, but people do not see the f6 interface when they first log into the game. a lot of players don't even know it exists so there is no harm in having it ther,e although there is no reason to have it either. There are many things in this game that are not finished, and that f6 interface thing is one of the very least important things. so that's why i don't care about it.

 

Ok, that reason seems fair enough for me.

 

One question for you, there is some sort of mip-map support in the client. however i don't think it works on static objects. it would be nice if it did because then when you zoom out the details in the textures won't flicker as they get smaller. Is there anyway to make mipmaps with png files or something? I know the dds format uses mipmaps, but that's for directX..i don't know if it's compatible with opengl.

 

Well, i am not too knowledgeable in opengl -and nothing at all in directx hehe- but for the little I know, you can just read the texture from a file and then use, for example, gluBuild2DMipmaps() or any other similar opengl function to make the mipmap. In that regard, I dont think there is any difference at all. But I dont know if the client uses any other fancy stuff, I would need to look deeper, since I neven looked at the renderer code.

 

I did some quick search in the gl_init code, and it seems that the EL renderer uses some kind of custom function, that surelly is based in those opengl primitives -and it is important that they are opengl primitives, since the standard opengl primitives are the ones that the hardware acceleration can run in a breeze, since they are coded in the video hardware-.

 

I dont think that the graphics format has anything to do, unless there is something that opengl supports natively that I am not aware off (wich, on the other hand, is perfectly possible ). I dont know either if directx has such support that you mention, it might be... but directx is not cross platform, and is not accelerated by most video hardware either, do, it is not an option (no one would want to code such thing for ELC, anyway, since opengl is good, standar, solid, and well supported in many platforms and by all video hardware manufacturers). So, I would say (again, my knowledge is very limited in this things) that the texture format has nothing to do with the use of mipmaps. Since the texture is loaded into an array of bytes, and then processed to create the map by opengl functions.

 

Anyway, there are people around here that could explain this far better than me, and, possible, make some corrections on this that I said.

 

Cheers

[Entropy]

I don't want PNG textures, they have no advantage whatsoever, except the compressed PNGs, which would still have no advantage, as you trade the size for the loading speed.

The alpha channel is not really that great because we don't use alpha that much, except for a few things, where we have a separate alpha map. Many other games use PCX or BMP as well, and they are fine.

 

255 colors/texture is very resonable for me, we don't really need more than that, the game settings is not photorealistic anyway.

[Placid]

255 colors/texture is very resonable for me, we don't really need more than that, the game settings is not photorealistic anyway.

Are you not concerned for scalability?

[crusadingknight]

I don't want PNG textures, they have no advantage whatsoever, except the compressed PNGs, which would still have no advantage, as you trade the size for the loading speed.

Unless we have multithreaded loading (ie we're processing/uncompressing one file while we load the next, and so forth), technically HD access will be the bottleneck instead of CPU time.

Edited June 27, 2006 by crusadingknight

[Entropy]

255 colors/texture is very resonable for me, we don't really need more than that, the game settings is not photorealistic anyway.

Are you not concerned for scalability?

Huh?

 

Unless we have multithreaded loading (ie we're processing/uncompressing one file while we load the next, and so forth), technically HD access will be the bottleneck instead of CPU time.

 

The textures (most of them anyway) are less than 65535 bytes, so the DMA can transfer them in one single burts. Not a big deal.

[Drakos7]

By scalability I think Placid is referring to 3 years from now when "most" people will have broadband and it is decided to increase the visual satisfaction of the players.

 

But Ent does make a good point. The game is not going for photo-realism. Mipmapping the static textures and other tweaks might do enough to move us along for a while.

 

I would propose that we try to build a generic interface that could accept png or bmp. Just develop a reasonable API for it, then things could be switched to png/dds/bmp/... whenever by mainly switching the backend library. I have no intention of coding this myself though

[Roja]

By scalability I think Placid is referring to 3 years from now when "most" people will have broadband and it is decided to increase the visual satisfaction of the players.

 

and png alone won't help make that happen. A lot in the game would have to change to make the game up to date visually..bmp or not bmp would not matter since you can get the same results from it. It's other things that matter for this case.

[Placid]

By scalability I think Placid is referring to 3 years from now when "most" people will have broadband and it is decided to increase the visual satisfaction of the players.

 

and png alone won't help make that happen. A lot in the game would have to change to make the game up to date visually..bmp or not bmp would not matter since you can get the same results from it. It's other things that matter for this case.

Of course, but would support for both not be worthwhile?

[Roja]

Only if it's needed.

[Entropy]

Of course, but would support for both not be worthwhile?

 

No, it wouldn't.

As I was saying, 255 colors/texture is more than enough for pretty much anything. More than that would be lost anywya, because we use texture compression, which does get rid of the somewhat redundant colors.