I think it should be gooooood :3

here is a list....

semi vector based; (flash like)
doodle in chat as well? (so people can draw their language)
mac/win/linux?
gimp-based? (ignore the first one if this one is easier)

many people have been working on one, myself included, but if you ask  brokenwing he can tell you all the issues that may arise from using the oC protocol. Some of the biggest hurdles to creating an oC clone imho is re-inventing the wheel. The languages I personally am familiar with would require me to make all these routines for brush interpolation, pressure sensitivity, event files, and so forth. It's not a simple task to undertake -- oC's GUI is remarkably deceptive. Anti-aliased lines are a pain, also; and let's not forget tablet support. That's huge. Try messing around with WinTab.dll (it's not fun) -- data comes to the application in Packets, and you need to manage these packets to get a good balance between smooth lines and a responsive application. Drop too many packets, and lines look blocky -- drop too few, and the application slows way down and your packet queue gets huge.

I'd be interested in knowing what language you'd plan on working on something for this on. The last attempts I made were in .NET, since GDI+ I thouht would be "fast enough". (It's not, but only because blitting 2000x2000 bitmaps in software hurts it so much). If you want to experiment with some of the crap I worked with, go here: http://nobuyuki.gpknow.com/lab/

My next attempt may be in Java......

P.S. if you think you can do an OC clone that's cross-system compatible, you're in for a surprise. There's no such thing as tablet support which works on all the major operating systems -- Windows uses WinTab.dll, Mac OS has its own built-in library, and Linux uses Wacom's open source driver. It would be really helpful though if someone in the open source community created a cross-system tablet library that's easy to use and drop into our projects, hint hint ;3

I'm using C# on Mono, with Gtk#. Honestly, brush strokes, interpolation, and tablet support haven't even been registering on my radar at the moment... right now it's network code that's the top priority. I was just planning on putting a dumb 1x1 pencil tool in for starters. 90% of the oC collaborations people post around here don't touch the advanced pressure sensitivity and brush stroke features of oC, they just use it because it's a network drawing program. That's why I'm focusing on network code... I plan on putting in Avahi support so it can autodiscover oC servers on the same network, for example.

It'll all be open source (BSD) too so anyone can play around with it.

Didn't realize tablet code was so complex, but that sounds odd since oC runs on Wine, and I haven't heard any problems with tablets. How does Wine do tablets, then?

dude, I know you're not an artist or nothing, but how do you know to what extend people use the tablet functionality in oC? It should be one of the absolute highest priorities for most people who'd know what would need to be implimented into the program. On the other hand, if you wanted a non-pressure sensitive cross system compatible "OC Clone" you can use Shi's PaintChat3, which is based on PaintBBS. There's a couple of reasons that's not as popular as it is...... oC had tablet users in mind from the beginning. Do you know what those scroller bars are in the brush panel? They control the tablet expression (how it reacts to pressure sensitivity, tilt, and etc).

BTW I've looked into Mono too. Its GDI+ drawing routines are based on Cairo, which is even slower, and definitely not well-suited to large canvases. If your code gets far enough, you might run into these same issues.

I really appreciate that it will be BSD though, the network code would be really helpful at least ;3


Tablet support on Wine in general is not fantastic. You should ask around and find out for sure, because oC is a very quirky program with how it implements things like windowing, tablet support, multiple screen support, and etc. I'm not familiar with Wine's tablet support since I don't run linux on the machine I do artwork on, so I googled it: http://www.winehq.org/pipermail/win.....er/012111.html
This seems to back up what I'm saying about oC's tablet support under Wine (probably nothing). So, to answer your question "How does Wine do tablets?" the answer is "Probably it doesn't do tablets at all in this case".

For brush strokes, you'll have to use some form of interpolation, because strokes is not how the input from mice and tablets are natively expressed. They express in discrete packets, which means you'll get little dots whenever you make a stroke with no interpolation. Most easy solutions then just connect the dots (this is linear interpolation) using lines. That option is less feasible when pressure support is added, since line widths in GDI+ are static. You would then have to figure out a way to interpolate line widths, or just throw either pressure or fancy interpretation out the window. The form of interpolation that Painter and oC uses is arc spline interpolation, which GDI+ DOES have, lucky you -- but again, with pressure, interpolation would not be possible just by calling Graphics.DrawArc.......


So as not to discourage you, I want to encourage your efforts at producing good netcode for all future potential oC clones. There's a lotttttt of work to be done before a project like this reaches feature parity, though...... (even to the buggy oc 1.1)

If you feel like messing around with it, check out TabletPressure2.rar from my source code. Consider it BSD for now (I haven't really decided how to license it yet). I went and attempted to see how fast it would blit a typical OC sized canvas with all the features and functionality I would have wanted to reach feature parity with oC 1.1. You'll need  greenreaper's VBTablet and VBTablet.NET libraries to compile the source code, but binaries should be included. Check SourceForge for VBTablet (a wrapper for WinTab.dll). My code is in VB.NET but it compiles to MSIL just like C# so you can include it in an assembly if you wanted.

Yeah, I probably don't know enough about how tablets work to really do a satisfactory job, even if I wanted to go to all that effort (I don't :P). Maybe it might be best to write a "liboCnetwork"? Hell, I have a decent amount of that code written already...

Network code is something I *do* know something about, and the current code out there is just awful... I looked at warpaint, and it doesn't even know how to read anything beyond init/chat stuff, it just forwards all drawing messages around. Plus if performance is an issue you definitely don't want slow network code to add to the problem.

slow isn't really an issue, since you can't draw in the same area someone else draws in anyway (the blitter gets confused in oC) -- reliability is key. Does oC use TCP or UDP or both? Cause like, if the clients go out of sync, usually there's a monstrous crash, and THAT'S when things get really hairy. Reliability, very important.

It's TCP, but I'm not surprised about the desyncs. The oC protocol puts a header+length protocol on top of the *byte-based* TCP, which is a bad design. It's impossible to tell where one packet ends and the other begins without scanning the entire stream from the beginning. Also, the protocol makes it impossible to recover from errors: it is literally impossible for any oC client/server to recover from a malformed packet that might arise from a bug in the network code, short of tearing down the connection and starting it up again.

Any good client MUST terminate the connection upon any protocol error (autosaving the current session of course)... if the official oC client does not do this that's very bad, since every piece of data after a malformed packet will almost certainly be garbage.