Messages

1

Graphics / separate process (not thread) dedicated to display?

« on: October 01, 2010, 04:51:44 pm »

Thanks Spellbreaker, normally I would agree with you.  I also think exceptions + threads will provide 99% of what I need.  I should have mentioned that the goal of this app is specifically to cover more cases, and be as robust as possible -even at the sacrifice of speed.

Many programmers still don't realize how difficult it can be to overcome a system call that is stuck in hardware.  (i.e. slow network, scratchy optical media, or even the graphics adapter when users change displays or settings, etc.)

In the end, I think you are right that it will depend more on the interprocess communication mechanisms supported by the OS.  I guess you are helping me realize I am talking to the wrong forum.  I need to pick an IPC toolkit/api, run some speed trials, and then work with it's own forums if it fails.

I think it is already clear that sfml will work well once I'm ready for it.

2

Graphics / separate process (not thread) dedicated to display?

« on: September 30, 2010, 07:43:55 pm »

I've got this idea, but I don't know if it is crazy:  

I'd like to try having my application spawn a separate process that runs a simple sfml display window.  The main process (MP) will compose and render graphics frame by frame, but then copy each frame to the display process (DP).  I think there would be cool user interface advantages, but will the cost of transferring full graphics frames between processes be too limiting in general?

The advantage would be that if the MP got stuck (waiting for hardware, crash, etc) the user interface could remain responsive.  If the DP doesn't get new frames to display, then it will slowly fade to black and spawn another temporary minimal MP to help manage the situation.  Just a simplified query engine to put up a few options like restarting, waiting, send angry emails, etc.  This would also allow cool interface separation from multiple tasks or GUI views, etc.

Is it crazy to try and pass full graphics frames between processes fast enough?  Is it close enough to depend on the resolution/color-depth of those frames?  Is this commonly done already and I just don't know it?

3

Graphics / Is There A Function To Draw A Single Pixel ??

« on: January 05, 2010, 07:00:46 pm »

Many Thanks!  
throw Horns("sfml rocks");

4

Graphics / Is There A Function To Draw A Single Pixel ??

« on: January 05, 2010, 06:43:01 am »

I found a way to fill a square sf::Shape (no outline) to draw a single pixel, but like the other workarounds mentioned previously, it seems more interesting than practical or efficient.

I know OpenGL isn't that hard, but that doesn't take the painful irony out of saying it to someone who wants to draw one pixel.  

I vote to put something in the API to draw a single pixel (or list of points).  Perhaps even a variation of the sf::Shape class itself, or style of outline even.

It just seems the perfect fit for SFML's level of API:  It would not be as fast as the pure OpenGL, but it would provide a speed up for the many people who expect it.

Hopefully the SFML team will agree, and not see it as lame feature creep...

5

Graphics / how to compose images

« on: May 11, 2009, 03:02:36 am »

I want to compose a picture by drawing multiple alpha-blended sprites.  I already know how to do this once by drawing to the screen.  However, I want to do it in a way that results in another sprite.  

I'm guessing the way to do this would be to draw sprites to an image, and then make a sprite for that image?  How is this best accomplished?

Thanks for any help,
til