Messages

1

Graphics / Image.LoadFromFile("sprite.tga") Won't load the im

« on: August 21, 2007, 02:10:10 am »

Did you make sure to put the DLL's in extlibs\bin in your PATH somewhere?

2

Graphics / Some minor issues with sfColor/sfImage

« on: August 20, 2007, 05:51:52 pm »

Using unions for this leads to undefined behaviors (according to the C++ standard). More practically, the result won't be the same whether you run it on a big-endian processor or a little-endian one.
The only way to get a portable behavior is to combine / extract the components using bitwise operators.

Woops, I forgot about the endian issue. You are right, of course. ;-)

Pixels are not stored in a two-dimensional array, so I can't return a pointer to a sub-rectangle. To give access to a sub-part of the pixels array, I'd need to return a proxy class which would have to add offsets to match the new X and Y values.

I wasn't suggesting that you could return a pointer to a sub-rectangle. I was thinking of something like this:

Code: [Select]


int nStartY = 50, nStartX = 50, nWidth = 50, nHeight = 50;
for(int y = 0; y < nHeight; y++) {
  unsigned int *pRow = image.GetPixelsPtr(nStartX, nStartY+y);
  for(int x = 0; x < nWidth; x++) {
    // Generate and set color based on x and y
    pRow[x] = color;
  }
}


See what I mean? I think this is about as efficient as you can get while keeping the code clean. It would be even more efficient to call GetPixelsPtr() once and use pRow += image.GetWidth() after the inner loop, but that would break if the rows have any padding at all.

Actually, was GetRGBA() backwards so these UINT values could be converted to/from sfColor easily? If so, I imagine THAT would break based on whether the system was little-endian or big-endian (though I'm sure there are ways to address that). As a side note, you could change GetPixelsPtr() to a BYTE pointer and have sfColor take a BYTE pointer when it needs to reverse it based on big-endian vs. little-endian.

At this point I'm speaking before I think (I'm in a hurry because I'm supposed to be working), so feel free to ignore all of this. ;-)

3

Audio / I need a way to manually destroy the audio device

« on: August 20, 2007, 03:46:55 pm »

Ok, I'll send you the source with a Ruby test file when I get it cleaned up.

I'll also add a README and perhaps a batch file or two for building/running it in Windows. (Building/running it in Linux should be even easier, but I doubt I'll have time to test it.) I'll also see what I can do about documenting the source code for the extension in case you ever need to maintain it, as well as the minor changes I've made to make it more Ruby-like. I can't promise documentation as nice as yours, but I'll try to come up with something. ;-)

It is entirely up to you, but I would recommend that you add a pre-built Ruby binary download for the Windows crowd. It requires a special build of Ruby, but only until the default Windows installer for Ruby upgrades to Visual Studio 2005 (they're still using Visual Studio 6.0, and the libraries don't play nicely together). It should be very easy for you to build, but most Windows Ruby programmers won't have Visual Studio installed.

4

Graphics / Some minor issues with sfColor/sfImage

« on: August 20, 2007, 03:14:05 pm »

Thanks for #1 and #3.

Regarding #2, you may be right, but at the moment I don't see it. If you're loading an image without an alpha channel, the point is moot. If you're loading an image with an alpha channel, you shouldn't need to call this function at all. If you're creating an image in memory, you should set the alpha channel when you set each pixel's color (which is more efficient than going back to change it later).

If you added another defaulted parameter, like bIgnoreSourceAlpha=true (which I would add after the targetAlpha parameter), I'd be willing to bet that no one would ever want to change it, and the newbie programmers would be a lot happier because "it just works".

I'm not trying to argue. I'm just explaining why I brought it up. It really is a minor issue, and I think everyone will be ok with it either way.

P.S. - As a side note, you could make a small performance enhancement to sfColor by changing it to a union of a UINT and a struct { a,b,g,r }. When someone calls ToRGBA just return the UINT, and when someone calls the UINT constructor, you just set it. (It may seem minor, but if someone is generating procedural textures, it will be inside a very big nested loop.)

P.P.S. - On a similar note, it would be great if sfImage::GetPixelsPtr() took optional x and y parameters (defaulted to 0) and returned a non-const pointer. That way if I want to update a small rectangle within an image, it would be easy to get the starting position of each row and iterate quickly across the row.

5

Graphics / Some minor issues with sfColor/sfImage

« on: August 20, 2007, 03:35:35 am »

1) sfColor::ToRGBA returns 0xFFFF0000, which is backwards. Whenever I've specified RGB values in hex, I've always used FF0000 for red, never 0000FF.


Copied-n-pasted straight from this forum's help:
Font color: text[\/color]  Tip: you can also use color=#FF0000


2) When I call sfImage::CreateMaskFromColor(), I'd like to pass it 0 for black (getting it to use the UINT constructor above). However, it fails unless I set the alpha channel to 255. Since I'm trying to create an alpha mask, I would think it should ignore the source alpha.

3) Just a thought. It might be nice if sfImage::CreateMaskFromColor() took an optional parameter for target alpha (defaulted to 0) to allow simple translucency.

6

Audio / I need a way to manually destroy the audio device

« on: August 19, 2007, 11:55:37 pm »

Thanks. I made my own fix to use temporarily, but it's a cheap hack so I won't bother posting it. ;-)

I'm writing a Ruby extension to allow SFML to be used in Ruby (which doesn't have a good library for writing simple games). I already have all the audio, video, and input classes working. I left out the threading classes because Ruby doesn't support native OS threads. I also left out the networking classes because I believe most Ruby users would rather use Ruby's networking classes.

My next task is to clean up the class interfaces up to make it easier to use them in the "Ruby way". After that, I'd like to add some simple 2D primitive drawing methods (i.e. line, rectangle). My goal is to make it easy enough for my 8-year-old son to write his own simple games in Ruby.

You can have the source code for the extension if you'd like to add it to your project.

Here are my other projects in case you're interested:
http://sponeil.net/
http://g3d-ruby.rubyforge.org/

7

Audio / I need a way to manually destroy the audio device

« on: August 19, 2007, 02:45:05 am »

Right now you're using a static variable inside the static GetInstance() method to control creation/destruction of the sfAudioDevice. When SFML is used in a dynamically-loaded DLL, it will crash every time the DLL is unloaded because that object doesn't get destroyed until AFTER the DLL is unloaded.

Thanks,
Sean

EDIT: I meant to say AFTER the OpenAL DLL is unloaded.