Like the others said, you can attach your file directly. I'm no Ruby wizard, but I'll tell you one thing already: I'd use proper indention. It makes reading scripts so much easier and you won't have those bugs you are experiencing right now.

Could you perhaps upload your code somewhere?

In my opinion it's not working to call $game.draw within update to get the exception - because whatever the exception was, it could be gone or it could be something completely differently.

As far as I know (and back then it was like that), draw is called by Gosu when everything was set for drawing. This isn't the case in update - and if you are trying to draw stuff within update, everything could happen.

It's a horrible idea to call drawing related stuff in update - you will crash the application, sure, but that won't necessarily be the error that happened earlier.

It's not AJAX - it's just a little client sided scripting. I also just realized that a few icons here are broken. I might have to patch Quickreply soon, expect some update work. :P

Well, Chuadrat was one. But I left its code in the middle of a transition (P<->P to Server-Client with as many clients as possible), rendering it itself unusable. As far as I can tell is TCP pretty well.

Main reasons that something does not work with sockets are "I forgot to update() every socket", "I forgot necessary bindings (onReceive)".

A while ago you told me to replace Gosu::Colors::red with Gosu::Color::RED. And now you remove it.

I feel betrayed.

YAY THREADING!
YAY TOPIC MODERATION!

Rebuild all. Also remember that VS2008 and VS2010 have different toolsets. They are incompatible. If you want to use your vs9 lib in your vs10 project, you have to set the toolset to v90.

bump. Did you try to clean up the whole solution and rebuild it?

>and Left 4 Dead get any remaining time atm

Basic++

>or a like download portal?

Steam would be awesome, specially Steamworks, but since this is serious business I believe it's impossible to do that with OpenSource (except the developer has an own "Hah my Steam"-Branch and keeps merging trunk into that and releases it this way...)

Why don't you use NET/HTTP or whatever that HTTP-class for ruby was called?

You have to declare a name for your Gosu::Window-var.

>Gosu::Window win(640, 480, true);

should do the trick.

And you won't see anything, since you don't run it -

>win.show();

How would you implement a search engine in JS...?

>Did any of your friends suffer from color blindness?

As of now the colors are created randomly. As soon as I've implemented Widgets::Slider there will be an option for that ;). The red side is by the way the last drawn.

>Looks like it's pretty hard then ;)

Sometimes it's hard to see, I agree.

>(You should embed the screenshot I think)

Oops, I've forgotten that.

I would like to see the namespaces in the C++ documentation again because now there are many functions missing that are floating around in Gosu::.

SHOW_NAMESPACES        = YES
into the doxyfile please.

Chuadrat, swiss german for a square as somebody with a broken 'R' would pronounce it, is a simple version of Dots & Boxes, or something like that. It's a 2 player game that works over the internet. Its multiplayer has been tested by me and some friends. It includes a random map generator ('R' while in hosting state), you are also allowed to import own maps (15 lines à 20 chars max, 'X' for "square", everything else for empty space, \n is the definition for the next line, \r is ignored, Drag-Drop into the window while in hosting state).

How to play:
You need 2 instances of the program. Both can be on the same machine but don't have to. You can play over the internet with your friend without problems as long as the host has forwarded TCP 13458. The network part is currently in re-development to allow more players and even spectators. As host you can type in your name with clicking on the 'Lokaler Spieler' widget and type in a new. It won't be saved at the moment. Same goes for the IP when you are joining. As soon as you hit 'Join' you will connect and the game will start.

A person will be chosen to begin. You can click a not-yet-drawn-side and it will be drawn. If you draw the fourth side of a square, you get a point. And that's what you do the whole game: Draw sides.

If you draw a side and get a point you can draw one more side, as long as you do points. If you draw without getting a point, the other is able to draw.

You play until there's no square left undrawn. The number left is your score, the number right your partner's. The number in the middle shows the empty squares.

As of now I don't plan to make it OpenSource, you have to life with the Windows compiled version.

>instead of adding random features that may never or hardly be used

I can't remember Gosu doing something like that.

>#2 - Dual game pad support for Windows,Mac and Linux preferably with Vibration Feedback Support

I think there are only a few people that really would use that .

You're welcome to catch the loading exception and tell the user the programmer has been drunk. Users should *not* be the one that debug your program. If they miss an image, it's mostly your fault (or the extractor, hello IzArc).

>So the way I understand it now, StaticText uses the Font just to get the font name and height. Couldn't it do that in the constructor and then forget about the Font& altogether afterwards? (Haven't used Text, sounds like it actually uses the Font dynamically)

Could, yes. But I think you may want to get the Font again and this way, you can get it.

>But it's still the root of the C++ class hierarchy ;) And classes meant to be derived from should always be noncopyable IMHO. Otherwise, the compiler will allow this: Widget a = otherWidget;, something that can happen implicitly if you forget a & somewhere, but which will crash at runtime.

OK, will do that next time.

>Yeah, but if these widgets need anything from a Window (or MyWindowSubclass, or MyCustomUnrelatedClass), couldn't they take it in their constructors?

And then save it as? Reference? shared_ptr?

>• SimpleButton is a bit weird to use. Why are its states Widgets again? I think I'd prefer subclassing it to show some Gosu::Images, but I guess I can just do that, so no problem :)

Because of the Design. Since it's just a "wrapper" for three other Widgets (and in my local, newest version) they really can be any widget, you could also do Text-Things - but I think that there will be something like "SimpleColorTextButton", or something like that.

>• StaticText requiring a shared_ptr<Font> is evil when it just needs it to extract the font name and height. Even if you insist on the existence of a font (I happen to have it), Font& would be nicer

Text requires a shared_ptr to a Font, so does StaticText. I don't know if you could set another font anyway, I'm changing the font in a program of mine for example. Also, I don't know how the memory management with many Widgets with the same font-reference would be (you have to keep the Font in your Window-class?)

>• As the root of the class hierarchy, Widget should be boost::noncopyable to avoid slicing and double-freeing.

It's not the root. You can put a Widget into a Widget into a Widget into a Widget, as often as you like, for 'layers' or better said 'groups'. Also, since everything in the Widget-things is using shared_ptr now, that shouldn't be a problem.

>• I don't always have a Gosu::Window& in my code. The game uses one, the editor doesn't (yet). What are you using it for other than the mouse position?

Custom widgets. Because you can (and are allowed/expected to) create new Widgets, based on the default widgets, you may require something from the Window. I thought about storing the window in a weak_ptr or something like that. However, if you use the widgets I expect you to have an instance of Gosu::Window or a childclass. Since updating/drawing requires this variable anyway... Or did you thought about the StaticText::setText-thing?

>• Beware, Input::mouseX() can be negative ;)

That's a fossil. Widgets were unsigned int with x/y/height/width once. It's fixed in my local version.

Since a screen wouldn't show much more than just drawing Gosu::Image / Gosu::Font, no. I think the name could be miss interpreted, this is *not* for some kind of sidebar.

GosuWidgets is a simple way of creating an own "UI" for Gosu. It actually supports Images, Buttons, Cursors, Texts (static and 'dynamic') and inputs (for text). Everything is in its namespace 'Widgets'. Every widget can fire callbacks (boost::function, use boost::bind to bind them), some are useful, others aren't. An (stupid but working and documentated...!) example is included.

MEET THE WIDGET:
The widget is the basic class for this whole thing. It can be just a container, means it has no x/y/z/width/height values and (itself) does not trigger any events but it could also be an "invisible" layer of area that triggers onHover/onBlur/on(Left|Right)Click (as used in SimpleButton). It's recommended to have a WidgetPtr defined as rootWidget in your Window-class. Widgets can have children, which can have children, which ..., you see my point. If you hide the parent the children won't be drawn (unless they're in another, visible widget, which isn't recommended). You can mix all different z-Levels into a widget. They do *not* respect that, i.e. having two visible and active widgets at the same position with same size will fire the events twice, for both widgets (for menus etc: Disable the whole UI, which you put into another widget than the menu, and enable the menu then).

MEET THE IMAGE:
Maybe the most used widget. Like a widget but it can (or better said: should) have a shared_ptr to a Gosu::Image, which is drawn. This class accept many attributes Gosu provides, such as different color, different alphamode or "stretching factors".

MEET THE SIMPLEBUTTON:
SimpleButton is (somehow) an example how you can easily build something new out of the basic widgets. It always requires an Widgets::Image-ptr to the default (= not hovering, not disabled) widget. If an hover widget is defined, it will be shown when the cursor moves over it. If a disabled widget is defined, it is shown when the widget is disabled (it doesn't matter if the cursor is above it or whatever). You should always bind to the SimpleButton, not to its Image-Widgets.

MEET THE SIMPLECURSOR:
Well, takes an Image and a z-Position and is doing a great job as cursor.

MEET THE TEXT:
"Dynamic text", based on Gosu::Font. This widget does not trigger onHover when the mouse is over a letter, just when it is over the rect that the text produces. Can have a different color, alphamode, factors or relations.

MEET THE STATICTEXT:
StaticText, quite the same as Text, except it is writing its data to an Gosu::Image, which is somehow "caching". Faster than Text if not changed very often. If your text changes often, go and use Text instead.

MEET THE TEXTINPUT:
TextInput, allows you to simple let the user enter something. You can define textcolor, the color of the caret (the, usually, blinking thing, which isn't blinking here because that would be annoying) and the color of the selection (passing Gosu::Colors::none if you don't want that). This kind of widget has a new callback: onReturn. It's fired as soon as the user presses the return ('Enter') key (Gosu::kbReturn).

The whole thing is thought to be built as a lib and requires, of course, Gosu-Headers (to build the lib it shouldn't be necessary to link against the libs of Gosu though) and boost. I don't know if it's already out there, may you will need an SVN version of Gosu to build it correctly.

The whole lib hasn't been tested and I'm quite sure they are some bugs around because I simply don't use that silly stuff I put in somehow ("setAlphaMode"?!). The code is a bit messy, I haven't cleaned it yet and I guess some things are only settable in the constructor. If you find something like this, tell me. I will fix it.

What I've tested are mostly basic things ("create everything in the Window-constructor and change only things like the text or something like that") under WinXP 32bit SP3 which is working quite well. All headers are documentated, the c++ files aren't. The example contains a C++-file, the images and the Inkscape .svg they were created with.

Don't expect crazy things like the things the guys do in the ruby section about UIs - it's not thought to "imitate" the OS or to have everything. I think there will come more things in the future, like some kind of a list (but mostly only when I require it in a application/game).

Set your include path to there where the .sln is (you should include 'GosuWidgets/GosuWidgets.hpp' for example), if you want to use it as lib the MSVS2008 project will build it into libs/.

Well. Have Fun.

Update 19.06.2009
Now using shared_ptr<Widget> (aka WidgetPtr) for almost everything. Using widget[5] is not possible anymore, use ->getChild to get the pointer to that child. However, the [] for a simple Widget will still return Widget&. Some few fixes with canHover (unsigned-thingy) and SimpleButton.

Depends but I voted for a jump button because there are many other ways to spend KbUp to something useful (ladders, portals, cake)