Messages

121

Feature requests / ResourceStream class for custom resource loading

« on: June 14, 2011, 06:14:20 am »

OK this is with the official release of stb_image.  Now images can be loaded without the stream needing to be rewound.

So a few changes to stb_image.h and ImageLoader.cpp

https://legacy.sfmluploads.org/index.php?page=view_file&file_id=15

Hopefully now it's done for reals.

122

SFML projects / SFSL - SFML File System Library

« on: June 14, 2011, 01:10:25 am »

I guess it will not depend on SFML, so why do you call it "SFML file system library"?

I actually was planning on making it depend on SFML and act as sort of an add-on library.

But you're right, it doesn't have to be dependant.

As for the name, I'm open to better suggestions.  I honestly didn't put a whole lot of thought into the name  XD

EDIT:

Actually, I remember now...

I need SFML for threading stuff.  Archives will need to be threadsafe and since this lib is designed to be used with SFML it makes more sense for me to use SFML threads.

So yeah, SFML is a dependency.  The system package only though.

123

SFML projects / SFSL - SFML File System Library

« on: June 13, 2011, 04:21:05 pm »

Are you going to provide a stream interface similar to the standard library? Maybe you could even use std::ostream and std::istream, so that existing << and >> operators also work with your library...

Deriving from ostream/istream is definitely on my todo list.  The problem is it's ridiculously complicated to do.  I don't know why they made it so hard.  I mean you'd think all you'd have to do is provide seek/tell/read functions...

It won't have that support immediately, but it is planned.  Hopefully I can make it work.

By the way, don't you want to reuse portable code like Boost.FileSystem internally? I don't think it makes much sense to reinvent the wheel for every platform... You can still provide an interface that abstracts from the details

For systems like *nix where additional dependencies are trivial, yes.  You're pretty much expected to have boost installed if you're on Linux so it's not really an issue.

For Windows users though, the extra dependency will be a hurdle, so I would rather stick to WinAPI.  I already have plenty of dependencies with SFML and zlib.

Do you intend just to use zip, or might you use something like the LZMA SDK to support .7z files, etc as well?

.zip is just the most common, so I was going to start with that.  I see no reason why future archives couldn't be supported, though.  In fact I'm designing the framework to be easily expandable to allow for new formats (or at least, making it as easy as I can).

I assume you won't be providing encrypted file handling, whether due to annoying laws on export or whatever

I hadn't really thought about it.  Would there be any point?

124

SFML projects / SFSL - SFML File System Library

« on: June 13, 2011, 05:07:49 am »

I figured I would mention this now that I'm more or less done with my other SFML related project.

I'm starting work on an add-on library to SFML... SFSL (SFML File System Library).

As the name implies, one of the primary goals is to provide cross-platform way to interact with the file system.

It'll have the expected goodies:
- File I/O
- File/Folder creation, renaming, deletion
- Directory scanning (iterating over files/folders)

Plus some perks.  The biggest one being .zip file reading/writing in a sane manner (most libs I've seen/used expect you to bend over backwards to use zips)

Benefits over stdio/iostream for normal files
- 64-bit offsets
- Ability to truncate/shorten files without having to completely wipe them
- Unicode filenames (windows' standard libs choke on this hard)
- Utility functions for endian-safe read/write of integral types

Benefits over boost::filesystem
- Seamlessly integrates with SFML
- Abstracted interface.  Not strictly a singleton.

Use it to...
- Manage user profiles
- Manipulate easily distributable "packages" to allow for additional/customized levels
- ...and more!


Imagine if i/o with files in .zips were as simple as i/o with normal files.  There's no reason it can't be!


I did something similar to this with another lib I wrote a long while back.  Some of the code should be adaptable, but most will need to be rewritten to make it thread safe and exception safe.

125

Feature requests / ResourceStream class for custom resource loading

« on: June 12, 2011, 07:57:07 pm »

I'm going back and forth with Sean now about some changes to stb_image's API.  So I'll have to revise the files again in a bit.

It will be for the better, though.  Should have some performance increases when loading files, and less demanding requirements for streams.

126

Graphics / Does anyone have a .pic file?

« on: June 12, 2011, 04:12:57 pm »

Sweet!  It totally does have .pic exporting.

That's exactly what I needed.

Thanks!

127

Feature requests / ResourceStream class for custom resource loading

« on: June 12, 2011, 04:00:58 pm »

Don't forget to test the code in pure standard C; something that compiles/works in C++ may be completely wrong or broken in C.

The stb_image stuff all works in C and C++.

Obviously I didn't try compiling the SFML stuff in C.

Do you plan to write an example implementation of a derived class?

I suppose I could, but the thing is it's more of a feature that would be used in non-trivial cases, so an example class would either be too complicated or kind of useless.

I plan on writing an SFML extension that works with .zip files and the like, which is the main reason I wanted it.

128

Feature requests / ResourceStream class for custom resource loading

« on: June 12, 2011, 07:25:18 am »

Finished up the stream stuff for Music, SoundBuffer, and Font as well.

Updated files (including the image stuff, so you can ignore that previous link) :

http://www.filedropper.com/customstream_1


Also, I spotted a potential memory leak in the Font loaders.  If FT_Select_Charmap fails, then 'face' leaks because the function returns before freeing it.

I fixed that in the files I uploaded.


* starts another project while he awaits judgement *

129

Feature requests / ResourceStream class for custom resource loading

« on: June 12, 2011, 03:43:00 am »

All done with stb_image and the SFML wrapper for it.

Complete with Doxygen comments.

stb_image itself was tested on:
- VC++ 2010 Express on Win7
- Fedora 11 i386 (Linux) g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)

Given that there's nothing platform specific or unusual about the code, I don't expect problems on other platforms/compilers.

The SFML stuff was only tested on Win7 with VC++ 2010 Express, but the code is especially trivial so I'm confident there won't be any portability issues.


Files:

http://www.filedropper.com/customstream


All modified files included in the archive in the original directory structure.  Unchanged files are not included.


Here's to hoping it gets added to the official release!

As always, I'm looking forward to hearing your comments and feedback, Laurent.


EDIT:  actually I didn't get to test the .pic file loading because I couldn't get a .pic file.  But I doubt it got broken in the update.  Who cares about that format anyway.

EDIT 2:  I submitted the stb_image update to Sean as well via email.  I didn't hear back yet but once I do I'll report back.  Especially if anything needs tweaking.

EDIT 3:  On to music!

130

Graphics / Does anyone have a .pic file?

« on: June 12, 2011, 12:03:05 am »

Yeah I checked the wikipedia page already in hopes of finding a sample, but no luck.

I'm not that worried about it, but it would be nice to be able to test it if possible.

131

Graphics / Does anyone have a .pic file?

« on: June 11, 2011, 11:37:24 pm »

I'm trying to test the .pic file support in stb_image to make sure I didn't screw it up, but for the life of me I can't find a .pic file anywhere on the internet.  Nor can I find any free program that will allow me to convert to it.

Does this format even exist!?!??!?!!

If someone could post a pic file I'd appreciate it.  I don't care what the image is.

EDIT:  doh, probably should've put this in the general board.

132

Feature requests / ResourceStream class for custom resource loading

« on: June 11, 2011, 06:28:45 pm »

OK!

bmp, gif, png, tga, jpg, psd loaders all check out.  At least when you load from file.  Didn't test loading from memory yet but I don't anticipate a problem, as I hardly touched that code.

File loading now uses the callback system, so if loading from file works, then loading from callbacks will also work.  But I'll test that too for due dilligence.

The biggest problem now is I cannot find any .pic or .hdr files to test those loaders.


Does anyone have any example .pic or .hdr files that I can get a copy of?

Once I finish up the testing, writing sf::Image::LoadFromStream should take me all of 5 minutes.

133

Audio / Music Error

« on: June 11, 2011, 09:16:43 am »

oggs are pretty much superior anyway  ;P

mp3 is only around because of familiarity and portable devices *cough*ipod*cough* seem to refuse to want to support ogg.

EDIT:  also, +1 for your musical taste.  Devo rocks.

134

General discussions / A few beginner questions

« on: June 11, 2011, 09:09:57 am »

I've heard of static linking, but I've also heard it's better to copy the DLLs anyway. Why?

I don't know where you heard that.  If you statically link, the DLLs are not used.  They'd be 100% worthless.

What are the advantages/disadvantages of static linking?

Biggest advantage:  always sure that the user has the right version of the right lib installed.

Biggest disadvantage:  your exe is bigger


Personally I strongly prefer static linking on Windows.

And how do I go about doing it, anyway?

When you compile SFML, set up the project so it compiles statically.  There are options for that in CMake (See the tutorial page:
http://www.sfml-dev.org/tutorials/2.0/compile-with-cmake.php )

EDIT:  specifically, the BUILD_SHARED_LIBS option is how you choose whether you want static or dynamic.

You'll know you did it correctly if your libraries have "-s" in the name after you build them.

Do I need to link to them in Build Options?

Yes.  You link to them the same way you link to dynamic libs.  The only difference is you don't need the DLL to run the program.

Second, I dislike having to manually go into Build Options and link all the libraries I need each time I start a new project.

There's a workaround this for Visual Studio that uses #pragmas, but I don't think it would work for C::B.  =(

135

Feature requests / ResourceStream class for custom resource loading

« on: June 11, 2011, 09:02:54 am »

I just finished up the changes to stb_image.

Well not finished.. but I think I've changed everything that needs to be changed, and it's compiling OK.  Now I have to actually test it.

but it's already passed midnight, so it'll have to wait until tomorrow.

zzzzzz