Messages

1

General discussions / My plans for the website tools

« on: March 23, 2011, 05:10:53 pm »

...and sourceforge is Ad-Supported. Never liked the commercial feeling of it. Not to say that those ads are annoying; github has a cleaner interface.

We can even say the trend is moving from sourceforge to Git, not just now, since more than a year. Sourceforge didn't innovate much in these past years, and that's why it's getting "rusty", 'cause of sticking to the old ways when something better has been made, instead of adapting to that new thing. However this last comment was more a personal opinion rather than a fact.

Anyway, I love the changes too. Many thanks go to Laurent not just for keeping this up but to keep improving it!

Finally I hope these new tools will boost up the community so it can keep manteining this wonderful software that it's SFML.

2

SFML website / Switching from phpBB2 to SMF

« on: August 31, 2010, 05:46:07 pm »

Unfortunately, SMF does not set release dates for updates, as it relies in many factors. However, I think we'll see an RC4 very soon, as the bug list is being made smaller every further day:

http://dev.simplemachines.org/mantis/view_all_bug_page.php

There you can see what is pending to do for the next release, which is the most similar to a roadmap that you'll find on smf foundation.

Questions about release dates for the stable 2.0 branch have been made in a few trheads on smf official forums, you can google them pretty fast, but as I said, no developer has unveiled any relevant info.

Anyway it's very easy to update the soft from the cpanel, so it is not as risky to use at this time as it was.

If you haven't tried the soft I reccomend you to install it in another DB and hack around with it, then you'll if it suits your needs. Online demos are good for this also, but I find them messed up many times  :roll:

3

SFML website / Switching from phpBB2 to SMF

« on: August 30, 2010, 08:07:18 pm »

Certainly, the current board software (althought functional) is lacking important features, specially when it comes to security. It'd be a good idea to install a new software and migrate the DB, not only for users sake, but, as you said, to save you from doing boring-repetitive tasks.

Someone previously said that fancyness is not the main virtue and I agree with that. A fast, functional, intuitive one is preferred and then it's great if it offers options to customize etc

Having tried many cms and forum softwares I sum up to the ones recommending SMF. At first you'll find configuration options a bit overwhelming, as if you were managing a commercial product like vbulletin, but at the end you're provided with much more power.

On the other hand, PHPBB3 can be configured steadily as it doesn't have even half of smf's options. I also think smf is more efficient consulting the DB.

Said that I'd conclude that SMF is the best open source solution, specially for the long run. Maybe wait for the stable 2.0 branch? That's what I'm doing, I think  

4

Graphics / Problem with colours [SOLVED]

« on: November 25, 2009, 12:12:31 am »

Image Data Field:

This field specifies (width) x (height) color map indices.  Each index is stored as an integral number of bytes (typically 1 or 2).   All fields are unsigned.
The low-order byte of a two-byte field is stored first.

That might be actual problem. So I think I have to make two versions of the decode function decodeRGBA and decode BGRA. :?

And then the before output file was working by fortitude, as I called red blue and blue red LOL

Don't hurry Laurent I think the problem is already clarified. Lots of thanks for the help, I think I was too obfuscated to find the solution myself. :wink:

5

Graphics / Problem with colours [SOLVED]

« on: November 24, 2009, 11:16:38 pm »

Yeah that's what I read but still there's a difference in the ouptut produced by loadFromPixels() and the same content when I write to a file. (If I pass it like BGRA loadFromPixels() work and if I pass it like RGBA the output file is okay) As I'm not doing any operation to change those things and just passing the colour vector both to the file writer and loadFromPixels I don't understand this difference.

6

Graphics / Problem with colours [SOLVED]

« on: November 24, 2009, 10:04:34 pm »

Solved man!! Now what's wrong is the output file LOL

What I still don't know is why LoadFromPixels uses BGRA format as documentation doesn't state that but RGBA. Does this mean that I have to do two decode functions, one for LoadFromPixels(BGRA) and other one for outputting the file? (RGBA)

7

Graphics / Problem with colours [SOLVED]

« on: November 24, 2009, 09:42:00 pm »

Humm... I'm outputing the targa as what I think RGBA format, but maybe I have mismatched the palette's colour, so I'll test changing it so try all combinations and see if the screen image gets correct.

Anyway there are many TGA-based formats depending on the 18 byte header. I was almost sure that the one I use is RGBA but I'd like to try that.
Thanks for the advice!

8

Graphics / Problem with colours [SOLVED]

« on: November 24, 2009, 03:50:38 pm »

Already sent! It has some more innovations haha outputing all frames of the animation as TGA's and of course outputing a single particular frame.

Now I move on to code the animation itself from a firstFrame to lastFrame. Althought it would be bluishAnim lol

9

Graphics / Problem with colours [SOLVED]

« on: November 24, 2009, 02:44:41 pm »

That worked like a charm! Except from the fact that I still see the bluish version of the image while outputting the same data in a file gives a neat image.

Dunno what else try as it seems not to matter to LoadFromPixels. Maybe there's some SFML configuration missing (or extra-configuration) :roll:

10

Graphics / Problem with colours [SOLVED]

« on: November 24, 2009, 02:00:17 am »

O.K. I've modified the code as you pointed out.

Once I have:

   

Code: [Select]

vector <sf::Color> color_Vector; // Create a vector which stores image pixels

decodePixels( color_Vector, nFrame ); // Fill vector with decoded pixels

What sould I do with the vector?? Copying all colour components of the vector to an array of Uint8? That sounds like too much work...

11

Graphics / Problem with colours [SOLVED]

« on: November 23, 2009, 07:59:24 pm »

You suggested in another topic to use ostreamstring for the decoding anyway it won't took much time to replace that with a vector. I'll report when finnished...

12

Graphics / Problem with colours [SOLVED]

« on: November 23, 2009, 07:14:47 pm »

At the end I decided to take a full run with the debugger. As you can see in the following image, loadFromPixels seems to be ignoring the alpha component, just loading RGB values. For example there should be 16 transparent pixels on the beggining of the image, thats 16*4 zeros. But you can see there are much more, as if it was reading incorrectly.

Isn't supposed loadFromPixels to use an alpha channel?

13

Graphics / Problem with colours [SOLVED]

« on: November 23, 2009, 06:16:43 pm »

Okay:

ostringstream outputBuffer( ostringstream::out | ostringstream::binary ); // Output buffer to store decoded ICN frame pixels

Decoding example:
const unsigned char transparentPixel[] = { 0, 0, 0, 0 };

outputBuffer.write( (const char *)transparentPixel, 4 );

Now it didn't throw any null pointer error, althought the output it's still the same: bluish image on sfml screen, but correct pixels in output file.

This is giving me headache lol....

14

Graphics / Problem with colours [SOLVED]

« on: November 23, 2009, 04:48:05 pm »

I tried using ostrinstream.write(); before of using input operators but it throwed me some null point errors on execution. Maybe I'm getting something wrong about ostringstream.


EDIT: Holy sh*t!!! I messed it up with the constructor of the ostringstream and that explain the subsequent errors using write... I'll report again about this after I tidy up this chaos. If you want some advice never code late on night... specially day after day on a regular basis :roll:
 
Thanks as always...!

15

Graphics / Problem with colours [SOLVED]

« on: November 23, 2009, 01:12:40 pm »

I know. But the content of output buffer is the same for both. And I don't even write a header for the tga, just pasted one with the hex editor at the beggining of the written file and opened it.

So if there is no further difference aside from that I don't know why I'm getting different colours on the SFML loadedFromPixels image than in the output file taken from the same buffer.

P.D: I've just sent the code via P.M. (That's because I don't want this class to circulate over the internet, at least yet in such an unrefined state)