ChessPlusPlus Questions

Pages: 12
OK I keep thinking I have time to contribute to this, but life keeps proving me wrong. Anyways, here's another one of those times, and I'm hitting a snag.

I've forked the master branch, went to build and hit an issue with missing json.h. I don't know anything about json so I'm not really sure how to go about fixing this. If LB or Thumperr is around to assist that would be great :)
git submodule init lib/json-parser
git submodule update lib/json-parser
Ran that, was able to build. Tried running, closed instantly. Checked debug_log.log,

N7chesspp9ExceptionE caught in main: Error loading JSON: 1:0: Unexpected
Are you building the master branch?
Ah, I forgot to fix that bug in the master branch - it's fixed in my fork:

I'll fix it in the main repo when I have time. In case you're curious, it has the wrong path for the config files so the string being passed to json-parser is empty.
Last edited on
@LB, is your fork considered the up-to-date? As in, should I fork your's and work on that or fork the master?
LB's has the most up to date code and is more functional, so yeah fork his.
Ah cool sounds good
Trying to understand this code...
SFMLEventHandler has all the methods for handling various forms of events.
AppState inherits this class, then Application holds a pointer to AppState.

Application uses this pointer in the onEvent() method to call the various input handling methods defined back in SFMLEventHandler.

So, do new states inherit from AppState, and then they override any of these methods defined back in SFMLEventHandler to provide custom event handling based on whatever state we happen to be in?

Just trying to understand the event processing :(

Ooh didn't even see the ChessPlusPlusState class there... Looks like my theory was right. I'll still take general outlines on the flow of control in this.
Last edited on
If it helps, you should be able to generate basic documentation with Doxygen, though most of the code is not documented with doc comments yet.

But yes, your understanding is pretty much right.
Your understanding's right, RB.
To possibly help clear things up:

Suppose we wanted another app state that acts as an intro that waits for 5 seconds then swaps to the game state, or swaps to the game state if the left mouse button is clicked (maybe there's a splash screen or something, this is largely conceptual).
This is what that class would look like:

Of course, we would also have to go into Main.cpp and swap the initial app state to be the intro state.

Then it just boils down to a chain of states, one that links to the next.
Last edited on
Yes, this is exactly how we plan to add the menu screens :)

On a side note, maybe it would be good if each state class had a static function changeTo that too the application, and it would call changeState for you. This would reduce code duplication...

EDIT: ResidentBiscuit, you've made history!
Last edited on
@Thumper, that example definitely helped.

I've been going through and getting notes on how exactly this all works. Sometime I plan on making these notes look nice (wiki perhaps) and placing it out so new contributors know what's going on.

@LB, not sure if asking a question warrants making history :P

Anyways, once I get this all sorta mapped out in my head, I may start working with the network side of things. I assume we're going to need some server? I can't imagine doing this P2P, my network know-how is decent but good enough for that. I wonder if we could use a Koding server for this....

At the very least I'd like to get some basic chat functionality implemented. That wouldn't require any extra game mechanics that we have now to get up and running.

Thoughts on network design in general? What functionality should be included?

Actually, how are we handling the GUI? Does SFML provide utilities for this?

I should learn to look stuff up before asking questions -_- SFML does not provide this (which you all probably knew). There is a library called SFGUI that claims it is for SFML applications. That might be worth trying out.
Last edited on
Ah that's cool, I didn't know what people had planned out :) I will definitely like to assist at least, networks are interesting to me.
EDIT: Heh, deleted my post and reposted, but you saw my original post X)

Actually I was planning on handling the networking - check out the discussions in the issues:

The networking library I plan to use is liblacewing. Separating the client and server logic will be the next major task after my current PR is accepted.
Last edited on
LB wrote:
(NOTE: Both playing applications will take the role of both the client and server
in every session)

So, are you saying P2P? I don't really see how this would work without a server to at least facilitate the initial connection. I'm pretty bittorrent has to do this to get around NATs.

If we have to make a server anyways, why not make the server to be the mediator? Would definitely make things easier on us.
Last edited on
I'm not the one who wrote that! Read more carefully - I am assigned to the issue but the first post in the issue is by Script Coder. ;)
Last edited on
Ah damnit you're right -_- I read the second link first, then assumed the first was also by you.

Sounds like what you have in mind is more or less what I had in mind :)
LB wrote:
The networking library I plan to use is liblacewing.
Why add another dependency when both SFML and boost have networking capabilities?
Because the design of liblacewing 0.2 already matches what we would have to otherwise construct ourselves. It's about not reinventing the wheel.

If you or someone else makes a more elegant design with boost or SFML, then of course we will use it.
Pages: 12