Hi there!

Im not sure if this is the right place to post this question.. if not, please move.

What i plan to do is to implement my very own image format in SDL, which will be extracted either from some kind of archive or a single file. My question therefore is how to create a surface from this plain data in the memory?

I see 2 ways:
Create an empty surface and draw each pixel, which needs the surface first to lock and it is slow.
Create a surface from a pixel data pointer, which just uses the data i've loaded.

The first method is, as said before, slow. The second method needs me to create a second surface by converting the 'loader' surface so it will be stored inside the video memory (if this works with SDL_ConvertSurface correctly).

Is there a third, better way? Is there a way to convert a surface to screen->format (for faster blts) WITH alpha, if the format is less than 32bits per pixel?

Is there maybe some complete different way for my achievement?
What I need is the best performance


Thanks so far

_________________
so long ..
Andy

So, why do you want a custom format anyway? .

_________________
Serious game developer

http://www.persistentrealities.com
http://www.persistentrealities.com/vbfibre
http://www.ambiances.nl

Uhm.. good question

I want to make sth. like Blizzard's MPQ achives and the images (sprites) inside it should have additional content like blt borders, collision boxes, multiple images for different resolutions, some information about the units which are represented by the pictures and so on...

_________________
so long ..
Andy

Option 2 is probably your best choice. Just save the image data, and package your other stuff in with it. You'll probably want to do it in an archive too, to save you from having to design your own format (i.e. have the image as a PNG and the other stuff in binary format in another file in the archive).

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

You can always do what I did. Put in all the data you need the "blt borders, collision boxes" at the beginning of the file and then just tack on the image at the end of an existing format. Using SDL_RWFromMem() to load it onto a surface.

_________________
In brightest day, in blackest night. No evil shall escape my sight. Let those who worship evil's might, beware my power... Green Lantern's light!
Twitter!

1st: It makes absolute no sense to double-compress the files with PNG/deflate and ZIP-like/deflate,
2nd: I dont want to use such a overloaded format as TGA for each single picture
3rd: I really dont want to use windows bitmap because of it's name, creator and reserved longs ^^

What I planned to do is to write the pixel data down in the same format as SDL uses it for it's surfaces and putting my own size, etc. header in front of it

Another thing is I dont want to link that many shared libs because it's kinda silly to have 170kB linked just for PNG support (libPNG + zlib) and it looks unprofessional (for windows users), if the program directory is full of open source .dlls


and another library to link ...


Btw. this SDL thing is just the first step towards open gl and the fun of programming and maybe selling (3d) games. I wanna collect as many experience as possible.

_________________
so long ..
Andy

:: it looks unprofessional (for windows users), if the program directory is full of open source .dlls

Hide them in system32 like the professionals do, then.


Seriously, 95% of users won't even look in there for any reason, and 95% of the remainder will find something to point out as unprofessional before your choice of libraries.

yea.. ur right in this point ^^

But whats about the "issues" about the file formats mention in my post?
Another contra for the BMP format: It does not implement an alpha channel by definition.

_________________
so long ..
Andy

I still don't see why you won't go with PNG. Even if you wind up packaging them in a ZIP, I don't see how you're going to suffer any significant performance issues; if it's really bad, extract them all to super secret temp directory first or something.

Meanwhile, you might study Valve's implementation of their custom texture format. I think mostly they brewed it up so they could package material data with the textures, but you might learn something from it. FYI, they're generated from TGA files partnered up with a text file or two.

this discussion leads nowhere ...

Minimizing the data flow and the work means minimizing the time to load. I know that the difference between some zipped PNG and some not-zipped PNG is not that huge nowadays but i just want to learn and try things i've never done before

_________________
so long ..
Andy

Why don't you roll your own archive format like Blizzard? Your archive file doesn't have to compress (just store the bits as-is in your archive). What is the advantage to making your own format? It is just more work to convert art to that format and more work back to the videocard, and it is unlikely to have any features you can't do with PNG. Just make it try to compress the images and if it can't get a space improvement you don't compress it, it will cost you at most an one extra byte per file (to store whether it is compressed or not) and it will be faster than going to filesystem if you code it well.

<PEDANT>
The BMP spec does support 32bit images. However most apps do not recognise it.
</PEDANT>

Doesn't TIFF support meta data? Could you embed extra stuff in your image that way?

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10

thats exactly what i want to do ...

I just dont want to put PNGs inside it but bitmaps / pixel maps with some modified / additional header.

32bpp images are 'allowed' but the additional 8bits are used for faster processing with int32 and not for alpha.

I want to make a Sprite-Class + Loading code within constructor or a static function which loads the meta data to class' variables. For tiffs i'd need to once open the file for the meta data only and once for the pixel data via IMG_Load(...). It is the same thing as if i'd use a additional text file because the file(s) will be archived (map file, data file) or streamed (user pictures / avatars) anyway.

Never mind the discussion about using custom format or not - my question was how to load the pixel buffer to an SDL_Surface? My idea was to create a surface with
Is there another, better way?

Btw. I even could use a Windows Bitmap with a 'legal' header but a moved data address (see the first uint32 within the dib information header) so normal image viewers can display my image, if i wanted to. The only 'illegal' thing would be the additional alpha channel...

_________________
so long ..
Andy

Why not just use them for alpha anyway? You are discussing writing your own format, which would need your own editor anyway... it doesn't take much to see that with the extra byte of padding you can embed your alpha channel in an almost standard 32bpp BMP format. You seem to be being very inconsistent about this... first saying you want to create your own format, then disregarding an option because it isn't a standard format

_________________
God must love stupid people, he made so many.
theraje: 'God doesn't love stupid people, they're just easier to make'
http://sharedillusions.blogspot.com

Sounds like the kind of crap I would pull, doesn't it?

Programming is about making things work -- you already have a wheel handy that with proper manipulation can be used to train goats to harvest jellybeans, why make a whole new wheel that's intended to do such?

yea... what ever..
thanks for help anyway

_________________
so long ..
Andy