Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Clairvoire

Pages: 1 [2]
16
General / gl***() functions aren't defined after including sfml(fixed)
« on: September 21, 2011, 06:42:34 am »
This is probably something silly I'm doing wrong, but the tutorial says I need only include SFML/Window.hpp to be able to use raw OpenGL code, like glBegin() and such.

However, it lists all the openGL code as being undefined.  Everything under SFML itself works fine though.  Am I forgetting to do something?

This is with VS2010, linked against static libraries, SFML_STATIC defined.

Thank you in advance~

17
General / Can SFML operate with C++ Exceptions disabled
« on: September 20, 2011, 02:05:05 am »
Ah, good to know!  Following the Google code style guide, and it expressly forbids C++ exceptions.  

Thanks!

18
General / Can SFML operate with C++ Exceptions disabled
« on: September 19, 2011, 11:25:38 pm »
Does SFML depend on C++ exceptions in such a way that if I disable them, it will hinder it's ability to work?  I went over the code and found no place where they were used, but I wanted to make sure.

19
Graphics / sf::Texture and MaskFromColor?
« on: September 16, 2011, 12:11:21 pm »
... I'm a moron, I forgot to assign the texture to the sprite.  No wonder it was doing a solid colour.  

Thanks for the fast response!  It took having to see it plain daylight for me, bah...

20
Graphics / sf::Texture and MaskFromColor?
« on: September 16, 2011, 11:43:26 am »
Hello!  I have not updated SFML since March, when you changed from SVN to GIT.  (Could have put a warning in the commit log, thought the project died!)

My Question: I have a .png where the black colour in the image should be transparent, and setting the colour of the sf::Sprite determines the colour of the internal sprite.  (monochrome colour for font, this used to work)

sf_image->CreateMaskFromColor(sf::Color::Black);
sf_sprite->setImage(sf_image);
sf_sprite->setColor(some color);

How would I do this with textures now?  When I do the above, but with textures instead.  (the sf::Texture is created from the masked sf::Image) all it produces is a solid rectangle of whatever colour I set the sprite to.

Thanks in advance!

21
Graphics / Most efficient way to draw a picture pixel by pixel?
« on: November 13, 2010, 09:04:37 am »
In the code, you didn't account for x and y needing to move 4 bytes, since every pixel is 4 bytes, but in your array, it's going through it byte by byte.  

Code: [Select]
for(int x = 0; x < 800; x++)
  {
    for(int y = 0; y < 600; y++)
    {
      pixels[(y * x)*4]     = 255; // R?
      pixels[(y * x)*4 + 1] = 255; // G?
      pixels[(y * x)*4+ 2] = 255; // B?
      pixels[(y * x)*4 + 3] = 255; // A?
    }
  }


Made the minor adjustments.  This may be more favourable

22
Graphics / Changing Sprite Hue, Saturation, Brightness
« on: November 12, 2010, 07:56:38 am »
Yeah, was hoping to keep images only loaded up once.  But Shaders... I have heard them here and there when I skimmed the documentation, but never sunk my teeth into them really.  I thought they only worked on the screen itself.  I may be wrong, I'll have to investigate!

23
Graphics / Changing Sprite Hue, Saturation, Brightness
« on: November 12, 2010, 02:45:44 am »
I'd want to make it so I can edit these values with my sprites.  sf::SetColor and sf::SetBlendMode seem to affect the sprites at a point where this sort of thing would be possible, but I cannot pinpoint where they take place in the source code.

Basically, I just want to know how I can take source_pixel.red, and apply a formula I made to it, before it's wrote to screen_pixel.red

Or maybe that ability already exists.  Would be awesome if it did!  It's the only thing I've missed from SDL, the ability to take control at the pixel level.

24
Graphics / Sprites rendered approximately
« on: November 07, 2009, 12:20:06 am »
It took a little getting used to, but I actually like the bottom/right parts of Rect.  Makes resizing subrects fast and painless (in the sense, that you can resize it to make it go straight up, or left, without extra math involved), as well as getting the right_x and bottom_y values.

The only thing that x/y/width/height really helps with seems to be initialization, in my opinion.  Too bad there's no way to just overload that in..

25
Graphics / Sprite::Scale() throws off position
« on: November 04, 2009, 01:17:34 am »
Oh, I made a spritesheet to represent a lifebar.  It grows longer as the player levels up, so the sheet has a 1 pixel wide strip in it that would be drawn repeatedly, each time more 1 pixel to the right, to make it longer.

That is, until I noticed Scale()ing it did the same job with a little less code and a lot fewer rendering calls.

... Reading that thread you linked makes me kinda nervous though.  xD  
using floats for stuff that needs to be pixel perfect already has me a little paranoid.  I hope I'm not undoing some sort of really critical rendering fix by commenting out that, but I'm not sure how else to fix the scaling issue.

[Edit:] I forgot to mention, I use a viewport which zooms the screen in by a factor of 2.  There was an odd 1 pixel offset in the x and y I never understood, which I just noticed was now fixed because of commenting out that line.

26
Graphics / Sprite::Scale() throws off position
« on: November 03, 2009, 11:01:27 pm »
With smoothing turned off, which I do for almost all my images since they're all sprites, scale() will offset the (x, y) coordinates of my sprite by "scalefactor * imagesize * ~0.4"

Luckily, I knew about the offset trick in Sprite's Render() function, "GLCheck(glTranslatef(0.375f, 0.375f, 0.f));".  Commenting this out solves my problem.  

I didn't see it mentioned anywhere, so I thought I'd give a heads up~

27
Feature requests / Greater Pixel Access in sf::Image
« on: October 28, 2009, 08:22:33 pm »
I've replaced the code with the method you suggested, but noticed a considerable loss in performance.  Granted, the difference was from 'nonexistent' to 'trivial', but I'm pretty nit picky about making senseless optimizations.  xD

Most of the pixel data in the new array and old array are the same, with sparse modifications here and there.  Accessing the raw pixel array and making edits directly seems to cut a lot of the time LoadFromPixels() uses to reassign data that doesn't need to be updated, and to make assertions that don't need to be asserted.

For right now, I'm going to take the Strawman approach and add the two functions to sf::Image myself.  I realize this opens me up to being lambasted should SFML change how it internally represents pixels.  But then again, no one deviates from the 8bit RGBA quartet~

28
Feature requests / Greater Pixel Access in sf::Image
« on: October 25, 2009, 05:48:49 pm »
Hm... Taking a closer look at LoadFromPixels(), it doesn't destroy and reassign a new texture or anything, like I thought it would.

This is great, since I can now keep my pixel modification code separated from the library too.  Haha, I can't believe I didn't think of that, I just assumed that Load function was an initialization function and nothing else.  xD

Thanks!

29
Feature requests / Greater Pixel Access in sf::Image
« on: October 25, 2009, 02:24:26 am »
Hello!  Long time user, first time poster.  

I switched to SFML from SDL quite a while ago, and it was a great move up!  But there has always been something of SDL's that I really miss sorely, and that's the ability to perform pixel level modifications efficiently.

I'm aware of SetPixel(), but it has more overhead than I'm sure anyone would care for in a function whom will be called more than a million times a second.  (500 x 500 image, at 60 frames a second, is 15,000,000, so 'a million' is actually a modest accessment.  xD)

What I'm doing right now to circumvent much of that, is this:

Code: [Select]
sf::Uint8 * p = const_cast<sf::Uint8*> (image->GetPixelsPtr());

// ... mess with the pixels here ...

image->SetPixel(0, 0, image.GetPixel(0, 0));


A const cast, and a backwards function call at the end simply for the sake of setting Image::myTextureUpdate to true.  It's not very pretty, even if it works.


Maybe perhaps providing for, say... a public 'Finalize()' function in Image that would set myTextureUpdate to true (and anything else that'd have to be done, in the future), and perhaps another function that returns a non const pointer into the pixel array, that would require Finalize() be called for the image to be valid for rendering?  

It could be done with a boolean flag, that'd be set to false in the pointer retrieving function, set to true in Finalize(), and if it's not true, it can set off an Assert or something if someone attempts to render it.  I'm sure you'd think of a more elegant way, but that's probably how I'd implement it.  


This can't be the first time this has come up, but if it counts at the very least as a vote in the hat, then I'm happy~  Thanks for the awesome library!

Pages: 1 [2]