Cplusplus Community Chess Game

[cire]

The problem I have with keeping multiple images in one file (with the exception of sprite sheets) is that you have to worry about finding the rectangles in which they reside.

It is, essentially, a sprite sheet. If you're going to be using SFML (or openGL, or Direct X, or anything that gets close to the graphics hardware) chances are these things all need to be in the same texture for performance reasons. (Switching textures can be an expensive operation - so it makes sense to draw all of the pieces at the same time, from the same texture.) Generally, this involves specifying the area of the texture a sprite refers to (so you find subrectangles anway.)

That's not to say the current file is optimized, but it doesn't make a whole lot of sense to me to cut the image up into little pieces so you can sew them back together later. More work all around.

[edit: It's also an easy way to keep sets separate if you want to experiment with more than one.]

[ResidentBiscuit]

Due to weather I just got tomorrow off class and work, so I have all day to sit down and code. What needs started still?

[Thumper]

@cire
Either way there has to be memory allocated for the size of each image, whether they're in the same texture or not (albeit there's going to be a little overhead if they're in separate textures, ofc, but as you said, performance doesn't need to be a primary concern.) I separate them into individual images so I can deal with them in memory that way. If I want to draw a black pawn, I ask the image manager to give me a shared_ptr to the texture for the image at "res/img/pawn_black.png", then give it to the render window. That method still seems the most intuitive to me.
I haven't got much experience with the game development scene, so i might have the completely wrong mental picture. Perhaps someone else can deal with that area of the project if I'm off :p

@ResidentBiscuit
Everything still needs to be done :P
https://github.com/naraku9333/ChessPlusPlus/issues/2
We're discussing core design and such there.

[Lowest0ne]

Having all of the pieces on the same image also makes it easier to have an option to switch the style of pieces you want to use:

setTexture("Classic.png");
setTexture("Modern.png");

~I think that's what cire said in the edit~

Anyway, best of luck with this. I'm trying to recreate Quattro Formaggi right now, but I could possibly help at some point:
http://4.bp.blogspot.com/-zH8hPV8qYlA/TdkQfKOZtqI/AAAAAAAAAIE/dBjtuFIaKqw/s1600/Quattro+Formaggi.JPG
(Fit all four pieces in).

[Thumper]

Ahhh, see, now that makes some sense.
By that logic you could change the directory structure as well.
I dunno, there's something about creating images with perfectly aligned sub-rects with images in them that i just can't do.

[cire]

If I want to draw a black pawn, I ask the image manager to give me a shared_ptr to the texture for the image at "res/img/pawn_black.png", then give it to the render window.

Suppose, instead, you asked your resource manager to give you a sprite that represented a black pawn? You don't care what the image is, where it's from, or what texture it's a part of, you just want a black pawn. There are a few operations you'd like to be able to do with this sprite, but you can do them without worrying about the internal representation of the image.

The resource manager can happily give you a sprite that refers to a subrectangle of the texture the black pawn image resides in, since you don't need to know of the internal representation. Dynamically updating the set of graphical representations for pieces becomes a simple matter of updating one texture with a new (compatibly formatted) image.

[Thumper]

Why would you want the resource manager to hand you a sprite (while using SFML)? A sprite is a unique object with a position, rotation, and a ton of other things, and a reference to an existing texture. There will be multiple sprites with the pawn texture. So I couldn't have a resource manager just throw me one (unless it was blank sprite). It makes more sense to me to use a resource manager to store textures, then get those textures to create sprites in a different container, say, a vector<Object>.

My logic is, I would have TextureManager handle all the textures used in the program. Upon creation of the board, you create all the necessary pieces, which have sf::Sprite members. The ctor of the pieces calls TextureManager::Load, and receives a pointer to an already loaded texture if it exists (otherwise TextureManager loads it), and then sets the sprite's texture to what it's received.
Then board could have a subroutine named Draw, which accepts a Piece. Draw then throws the sf::Sprite in Piece to the render window (among other things Board::Draw does).

OR
Piece has no sf::Sprite member. Board::draw(piece) will take the raw position of the piece and create a sprite, and then sends that sprite to the render window.
Although, if we're nitpicking performance, recreating an sf::Sprite object on every call to draw seems like overkill, which is why I initially opted to keep sf::Sprite as a member of Piece.

But either way, one sheet with all the pieces could be used, and TextureManager could be altered to create a blank sprite with a subrect of the existing texture. I just prefer having separated pictures.

You're point about dynamically updating the set does make a good bit of sense as well. I think it's more of the formatting the image so it's compatible is what I have a problem with. It's so tedious.

[ResidentBiscuit]

I think we should move all discussions to the github page.

[Lowest0ne]

I think we should move all discussions to the github page.

I'll make this one my last one here. Interesting, this gitHub. I will have to check it out.

I think it's more of the formatting the image so it's compatible is what I have a problem with. It's so tedious.

I can do this no problem. It's a little late to start something right now, need sleep. I could also write a little GIMP tutorial so you can do it yourself. Doesn't take long really (making the resources rather than ripping from the web would take much, much longer).

[Script Coder]

I would like to assist, who should I speak to?

[3qX21hU5]

Just fork yourself a copy of the project on the github link and you will be added to the project. So far the design discussions are going on in the issues page on github.

[3hM2Nwbp]

I'm getting a 404 when forking.