|
It would appear that I've been added to Planet GNOME as a result of my summer job working on GNOME Games as a part of Google Summer of Code, so I figured it would only be appropriate if I introduced myself!
I started out as a lurker in this community almost a decade ago, when I was deciding what DE to use on my hand-me-down 100MHz IBM desktop my parents got me so I'd stop breaking their computer by installing a different distro every week. I was still in elementary school at the time, so I was (reasonably) encouraged to not participate in the community for privacy and maturity reasons, and eventually I drifted off to OS X for a few years.
Over the course of the last two years, however, Robb has dragged me to a FOSSCamp and a GNOME Summit Boston (and, we're going to UDS Barcelona, too!), and I've been quite reintroduced to the community. Being off at University (I'm at RPI, studying Computer Science) means I can participate all I want.
Anyway... Robb, Matt (another friend of ours from RPI), and I are the developers of Seed, which many of you have probably heard of (if not, try it out!). I'm using Seed this summer in order to port Mines to Clutter, as well as to complete my port of Same Gnome, and the new game, Lights Off, both of which I wrote during the development of Seed as examples.
I have a feeling that I have a good bit more time in the summer than is required to finish and polish these three things, so I expect to end up doing more; I'm currently in the middle of sending an email to my mentor, Thomas Andersen, to say hello and start to form a course of action (perhaps, once all I've promised to do is done, he'll have some ideas to move forward with!).
In any case... hello, Planet!, and I hope to see you all again, soon.
Yesterday, I got a wonderful email from Google telling me that my proposal for Summer of Code was accepted! So, this summer, I'm going to be working with Thomas Andersen on GNOME Games. I'm going to finish polishing Lights Off and the Seed-Same Gnome rewrite, make it easier to write games in Seed (by making libgames-support available), and (primarily) port Mines to Seed+Clutter. I have a feeling the work encompassed in my proposal might not take the whole summer, so I'm keeping my mind open for anything else that might be interesting to do towards the end. We'll see!
Anyway; thanks, again, to Google, GNOME, Thomas, and everyone, and I hope we all have a great summer!
P.S. A little birdie told me that Mike and Matt both also got GSoC projects this summer! Congrats!
So! Today marks the official end of Summer of Code, at least as far as coding is concerned. Final evaluations are due to Google between noon today and noon on September 1st...
I've decided to call revision c2c3fccb856771bf56fe15ad7c7ff66cf67ed2d9 my reviewable commit; I've not yet tested the Ecore stuff (which has progressed much further in the last 24 hours) in a clean install of Mac OS X, but that (and a patch!) will come soon.
It's been a lot of fun, for sure, and I learned a lot! Especially about Cocoa/CoreGraphics, and a bit about the EFL architecture and what it is the Enlightenment 'team' spends all of their time on :-) I'm not leaving for good, but what with moving back to RPI on Wednesday, and the end of GSoC, etc., I'm probably going to be missing for a week at least.
So I'll say... Nathan and Dan were both excellent mentors (I was sad to see Dan leave Enlightenment, what with his clearly rather rare knowledge of a significant portion of the EFL, but I quite much understand his decision, and hope he finds something excellent to devote his time to in the future), and I'm very glad I got to work with both of them (as well as the brief encounters I've had with other members of the team)!
And, to the project: there's certainly a good bit of awesome stuff going on here; I just hope that everyone can hold it together long enough to bring all the pieces together into something as awesome as the overarching idea of E seems to be. Good luck with that, for sure, and if you ever want an 'outside' head, drop me a line!
I've started implementing Ecore events. Lots of keyboard events work, and mouse events appear to totally work. Pretty cool!
Keyboard stuff is a mess... I'm borrowing heavily from the ecore_sdl module in that regard, but... they're missing a lot of characters. So, that'll be tonight. Then to clean stuff up and send in an Ecore_Quartz patch. Ehh. I named it Ecore_Quartz. It's more Ecore_Cocoa. Maybe I should change that??
Code is in Git. Including stuff to make test/orig/ecore work with Ecore_[Evas_]Quartz
I know Summer of Code is wrapping up (Monday is the absolute-pencils-down date), but I've got more news!
Following last weekend's advances (getting a Cocoa app up without a bundle and a NIB), I've restarted work on Ecore. After fighting a little bit more with Autotools (aargh!) to get Objective-C building successfully (which worked much more easily with Expedite).
After that, I dropped in some code from my Expedite engine, to set up Cocoa. And, as you can see, I was met with success! A tiny Ecore_Evas_Quartz test program, successfully running. No events, yet, but they should come within a day or so...
In any case, my biggest issue right now is I'm not entirely sure what to put in Ecore_Evas_Quartz, and what should go in Ecore_Quartz. Nathan suggested something like that Ecore_Quartz should provide functionality to talk to Quartz that Ecore_Evas_Quartz itself uses; I guess I'm still not entirely clear on what exactly should go where. So a lot of stuff is going in Ecore_Evas_Quartz right now, but I can move it out once I find out what's really what. (probably by reading other people's code, though if I've learned anything from this, it's that that's a bad idea *ahem*Evas_Cairo*ahem*).
Also -- this code is up in Git. Not SVN, though, obviously.
So I made a little discovery in a 7 year old mailing list post yesterday, and found out how to create a fully-functional Cocoa app, without letting the default run loop take over permanently, and without embedding the executable in an application bundle. Here you go:
EDIT: OK Wordpress is being silly; obviously, put < > around the #import file :-)
EDIT 2: Also, obviously, you need MainMenu.nib to be in the same folder as your executable.
EDIT 3: If you want to go NIBless, use NSBackingStoreBuffered, not the default NSBackingStoreRetained when creating your window!
// Build like so: gcc short.m -framework Cocoa
#import Cocoa/Cocoa.h
int main(int argc, char *argv[])
{
[[NSAutoreleasePool alloc] init];
[NSApplication sharedApplication];
[[[NSNib alloc] initWithContentsOfURL:[NSURL URLWithString:@"MainMenu.nib"]] instantiateNibWithOwner:NSApp topLevelObjects:nil];
ProcessSerialNumber psn = { 0, kCurrentProcess };
TransformProcessType(&psn, kProcessTransformToForegroundApplication);
[NSApp finishLaunching];
while (1)
{
NSEvent *event = [NSApp nextEventMatchingMask:NSAnyEventMask untilDate:[NSDate dateWithTimeIntervalSinceNow:0.001] inMode:NSDefaultRunLoopMode dequeue:YES];
if (event) [NSApp sendEvent:event];
}
}
So, I'm not sure exactly where I was last time I wrote about my progress on Evas_Quartz... so I'll just mention the things I know I've done recently...
1) Gradients work now! Except, only some of them. It seems that linear, sinusoidal, and angular gradients work, but I haven't seen a radial gradient out of it yet. Not sure that this is my fault, but it really only seems reasonable that it is. I just haven't figured out why yet (anyone care to help?)...
2) The biggest problems with the text block layout code (actually, the problems were with my functions for querying Core Text font metrics, as I knew) are all fixed now. Text blocks (at least the ones in Expedite, and the ones I made for my little throwaway test programs) all look great! A part of the solution is very clearly hackish, but it works for now. I've come back to this code, revising it massively, a few times during the project... one more pass should probably do it.
3) I spent a lot of time cleaning up memory leaks in #1 and #2. I suppose this is technically part of #1 and #2, but it happened more recently than the initial implementations. Heh.
In truth, I was leaking a lot. A legitimately embarrassing amount, at first... so in an afternoon, it went from >100MB (just silly!) to 100KB, and now it's at 14KB (through the entirety of the test program). The remaining leak is somewhere in the image data access functions (image_data_put, I think)...
4) I've got bits and pieces of the Ecore bits started, if you count... nearly empty files compiling and installing properly as started. I haven't added them to Git yet, and I have to find a home for them in Google Code SVN (since the root of that is currently the evas directory... oops). I think it's pretty clear that between sorting out threads/runloops/etc. and ... just ... making Cocoa work like a more conventional system, I'm going to be at this part for well into the school year, which is fine with me (maybe I can convince Robb to point me in the right direction, once I can show him what's up). But maybe there's others that work like this, I don't know. Carbon would certainly be literally a million times easier. Gah!
So! Tonight I got all of the Expedite tests running. I haven't checked that they're all perfect, and there's some larger issues with the program (it draws the icon for the currently selected test really large in the upper right corner, sometimes the text disappears, or the menu forgets to disappear — not sure why); it's nice at least to have all of the tests starting. So! Pictures and notes follow...
You can see the icon thing I was talking about in the top right hand corner. Other than that, this test works well (at least, it does now that I've turned CGContextFlush(...) coalescing off). Coalescing CGContextFlush is a per-application setting (you set CGDisableCoalescedUpdates to true in the application's Info.plist). I'm convinced this is a good thing, because it seems like a good idea for general applications, to prevent tearing, but it's nice to be able to turn it off, for benchmarking applications and the like.
This test hurts my eyes. I'm not sure if it's because we've only got low quality smoothing, or Expedite just gives yukky data, or what, but I'm just happy that the test runs! I ended up looting bits and pieces of different engines to get these image data access functions working (thanks GL and SDL, mostly!). I'm not sure they're perfect, yet (the last of the tests from the old program pertaining to this still doesn't work), but they're a lot better than they were recently!
I didn't initially understand that I needed to support YCbCr colorspaces in my engine (nor did I, once I knew that, know how easy it would be to implement) — I initially assumed mentions of that dealt with the device's colorspace, which I was already long done with... however, this test shows that it's working now!
I think I caught this one in the middle of a redraw, or something. These run pretty slowly (the styled text tests), I'm not sure why — though starting up Quartz 2D Extreme just about doubles their framerate... the normal, unstyled text tests run ~60fps, which is good enough for me!
Here's the first test that's clearly still broken, though I think it'll only take a little bit of TLC to get it into shape, I just haven't paid any attention to some of the font metrics functions yet...
Runs nice; see how you can see the menu through it? That's not ... right ... but my Expedite... hack... is horrible, and is probably at fault. I'll write later today about the run loop issue that's keeping me from writing a proper Expedite backend, and maybe someone can help me!
Rectangles — yay! So you've probably noticed a theme by now — everything seems to be limited to right around 60fps. Wonder why? SO DO I! I turned off coalescing — that got lots of things from 30 to 60fps. I've seen the rectangles go to around 150fps, but I can't seem to duplicate that! Very very puzzling...
All done! More posts later!
So! I've started working on Expedite, since it really feels like a better test program overall, its what my evaluation is on, and it does more reasonable performance testing (as well as allows me to only run a particular test, if I want!).
I've got a run loop issue that I'm going to write up later and see if I can't get someone else to help me puzzle out... there's just too much code competing for attention, at the moment!
Anyway... it draws... no events, so it's useless, and it's absolutely incredibly hacked up, but I'll work on getting it to work better and fixing things that don't work (especially image data access functions, which need to be implemented, badly!)... image after the break!
Two quick Evas_Quartz updates:
I've published my git repo here. I promise to try to keep it as up-to-date as I can!
The other bit of good news: I got the Evas image loading code working today, replacing the old Apple PNG loading code! This is good for lots of reasons: it opens the door to getting the image data-access stuff working, fixes the smoothing problem, and also gets us that much closer to having a working image cache.
The biggest issue I've noticed is that having smoothing working seems to slow things down a bit. Maybe too much — at least too much for the benchmark. It gets a little skippy... but I don't think this would be a legitimate problem for any real application written using Evas... I'll see what I can do.
|
|