I just got my 40" HD widescreen LCD TV Friday morning and today I went out and bought Call of Duty 4 needing a new game to play now that I've beaten Rainbow Six: Vegas.
Wow. Just wow. This game is amazing.
Here's the trailer:
And here's some sample gameplay footage:
Update: Already beat the game... guess I'll go back now and try to get all the achievement points I missed.
Every once in a while, it becomes necessary to parse an integer from a string. The trick is doing so correctly and without the need to use an integer type larger than what you are parsing into (i.e. if you are trying to parse a 32bit integer, you don't want to have to use a temporary 64bit int value for checking overflow - this is especially desirable if you are trying to parse larger int values, such as a 64bit int because you won't likely have access to a 128bit int type).
The following macro correctly implements an integer parsing routine for a given number of bits:
#define STRTOINT(bits, max) \
static int \
strtoint##bits (const char *in, char **inend, \
int##bits##_t *retval, int *err) \
{ \
register const char *inptr = in; \
int##bits##_t val = 0; \
int digit, sign = 1; \
\
while (*inptr == ' ') \
inptr++; \
\
if (*inptr == '-') { \
sign = -1; \
inptr++; \
} \
\
in = inptr; \
while (*inptr >= '0' && *inptr <= '9') \
digit = (*inptr - '0'); \
if (val > (max / 10)) { \
*err = EOVERFLOW; \
return -1; \
} else if (val == (max / 10)) { \
if (digit > (max % 10) && \
(sign > 0 || digit > ((max % 10) + 1))) { \
*err = EOVERFLOW; \
return -1; \
} \
\
if (sign < 0) \
val = (val * sign * 10) - digit; \
else \
val = (val * 10) + digit; \
\
inptr++; \
if (*inptr >= '0' && *inptr <= '9') { \
*err = EOVERFLOW; \
return -1; \
} \
\
goto ret; \
} else { \
val = (val * 10) + digit; \
} \
\
inptr++; \
} \
\
if (inptr == in) { \
*err = EINVAL; \
return -1; \
} \
\
val *= sign; \
\
ret: \
*inend = (char *) inptr; \
*retval = val; \
\
return 0; \
}
To expand this macro to parse a 32bit integer value from a string, you would do:
STRTOINT(32, 2147483647L)
The resulting function would be named strtoint32().
Why implement my own integer parsing routine instead of using libc's strtol(), you ask?
For a variety of reasons:
To generate functions to parse 8, 16, 32, and 64bit integers, you would write:
STRTOINT(8, 127) STRTOINT(16, 32767) STRTOINT(32, 2147483647L) STRTOINT(64, 9223372036854775807LL)
What about unsigned integers, you ask? Not to worry, I have an implementation for that as well:
#define STRTOUINT(bits, max) \
static int \
strtouint##bits (const char *in, char **inend, \
uint##bits##_t *retval, int *err) \
{ \
register const char *inptr = in; \
uint##bits##_t val = 0; \
int digit; \
\
while (*inptr == ' ') \
inptr++; \
\
in = inptr; \
while (*inptr >= '0' && *inptr <= '9') { \
digit = (*inptr - '0'); \
if (val > (max / 10)) { \
*err = EOVERFLOW; \
return -1; \
} else if (val == (max / 10) && digit > (max % 10)) { \
*err = EOVERFLOW; \
return -1; \
} else { \
val = (val * 10) + digit; \
} \
\
inptr++; \
} \
\
if (inptr == in) { \
*err = EINVAL; \
return -1; \
} \
\
*inend = (char *) inptr; \
*retval = val; \
\
return 0; \
}
STRTOUINT(8, 255)
STRTOUINT(16, 65535)
STRTOUINT(32, 4294967295UL)
STRTOUINT(64, 18446744073709551615ULL)
And there you have it.
Note: these routines require [u]int[8,16,32,64]_t to be defined. If you are on Linux, #include <stdint.h> should do the trick.
Update: Miguel's blog goes into more detail on why this code was important for Mono.
Matt Asay, in a recent blog on CNET, tries to imply that Mono/Moonlight are a waste of Miguel's time/talents.
For these reasons I can't help but wonder why he's squandering his talents on writing largely irrelevant code (Mono, Moonlight) that appeals to himself, Novell, Microsoft, and no one else.
Really? No one else? Are you saying that the thousands of users and developers involved in the Mono community are nobodies? Are you saying that OTEE, the developers of Unity3D, are nobodies? Are you inferring that Codice Software and the growing list of companies/projects basing their software on Mono are nobodies?
Miguel says that he's doing this to bring the proprietary world into the open-source camp. It's not working, Miguel. You don't convince by capitulating. You convince by winning
Based on the growing number of users and developers getting involved with the Mono project (and recognizing that there are probably far more out there that just haven't made their presence known), I would say it is working. Because of the Mono project, more people are taking an interest in Open/Free Software, which I and many others would call "winning".
Rather, Miguel de Icaza can turn the industry on its head by putting his knowledge of interoperability and open source to work on developing the next-generation desktop (and not by recreating the "best" of Microsoft on Linux).
It's unfortunate that you are so short-sighted, Matt. That seems to be one of the more important differences between you and Miguel. Miguel sees the big picture. He knows that in order to create the "next-generation desktop", he'll need better tools in which to do it. He also sees that "winning" takes "developers, developers, developers!" He knows that you can't "win" if it takes developers on Linux 2 or 3 times as long to write an application as it takes to write on Windows with proprietary tools.
I think Miguel de Icaza is an exceptional developer. He's also a fantastically effective community leader.
All the more reason to let him continue doing what he does best.
Update: Joe Shaw makes an excellent point.
Update: It appears that Matt Asay has retracted his post and made an apology.
I was just pointed at a nice article by Tom Adelstein called The Mono Project: You Might Expect the Unexpected.
It makes me happy when people publish insightful pieces like this. It's a nice change of pace from all of the lies and false propaganda that so many people are spreading without actually doing any fact checking (they make Fox News look credible).
Thanks Tom.
Moonlight has some fairly unique text rendering requirements that I've not seen done anywhere else in Linux, Gtk+ application or no. Most applications stick to rendering text horizontally or vertically, they rarely, if ever, perform unusual matrix transformations on text (e.g. rotations).
When I first implemented text rendering for Moonlight, I used the obvious choice: Pango, using the Cairo backend (since we're using cairo in Moonlight for 2D graphics rendering anyway).
Unfortunately, we ran into some problems...
The first major problem is that as we applied rotation transforms and called pango_cairo_show_layout(), we'd get rendering glitches in that each glyph seemed to have its own independent baseline and so each frame, glyphs appeared to jitter.
The second major problem was that calling pango_cairo_show_layout() each frame had some major performance problems.
Thirdly, there appears to be no way to tell pango to load a font face from a specific file path.
As far as the rendering performance issue, we considered caching the layout path but my discussion with Owen suggested that it would gain us nothing. That, plus the perceived difficulty of doing this (since we may have to change brushes mid-stroke), shied me away from bothering to try.
These problems led me to consider implementing our own text layout/rendering engine to see if we could solve the above problems since the pango maintainers didn't seem to know what the problems could be offhand and thus had no suggestions for us.
At first, my text layout/rendering engine only handled rendering of glyphs via bitmaps, but even so, the result was that this new layout/rendering engine was quite a bit faster than pango.
Seeing this, Chris Toshok, Larry Ewing and I started digging into pango text rendering performance problems a bit more, not quite willing to give up on pango.
Toshok noticed that pango was loading the same font over and over again each frame, so started digging into that aspect a bit and came up with a patch to pango to fix a bug where it used the entire transform matrix as part of the hash instead of just the scaling component (which is all that was needed for uniqueness).
For one of the very simple text rendering test cases we had (the text "Moonlight in 21 Days" spinning and resizing via cairo matrix transforms), Toshok's patch nearly doubled the speed of pango rendering from something like 20 to 40fps (40fps was our cap, so it may have even rendered faster).
Meanwhile, I began looking into that cairo path caching idea and discovered it wasn't nearly as complicated to implement as I had originally feared. The results were just as amazing, again doubling the performance or better, altho this was before I had applied Toshok's patch (so don't get the idea that my patch + Toshok's patch = 4x speed improvement).
Not only did my patch make a huge performance improvement, it also got rid of the glyph jittering.
Unfortunately, this still left us with problem #3 as well as a few other problems regarding layout dissimilarities between pango and Microsoft's text layout in Silverlight, so for now, it seems I needed to go back to my own text layout/rendering engine.
Once I had finished adding support for rendering glyph paths, I implemented a similar cairo_path_t caching hack for my own text rendering engine and made it possible to choose which text layout/rendering engine to use at runtime via an environment variable.
Out of curiosity, I decided to compare performance of my own text layout/rendering engine vs pango on a test case I had of several "Hello" strings each having different combinations of matrix transforms applied to them in an ongoing animation. One of the "Hello" strings was simply undergoing FontSize changes which cause each of the text layout engines to have to recalculate the layout (wrapping, etc).
The performance difference was shocking... the pango implementation (which doesn't even render the underline for one of the text strings due to a bug in my cairo_path_t caching hack? If anyone has any suggestions on how to fix this in mango.cpp, don't hesitate to poke me) only gets about 23fps while my home-rolled implementation gets 45fps.
It might be possible to improve the performance of my home-rolled implementation if I were to fix my code to use a true FT_Face LRU cache... right now it simply keeps a hash of loaded FT_Faces with a ref_count, when that ref_count hits 0, it gets removed from the hash table. This means that each frame it has to load a new FT_Face from FontConfig because the FontSize attribute changes and since it was had the only ref on that particular FT_Face, it goes away and has to be reloaded again next time it changes back to that size. Oh, and the 45 fps was with debug spew turned on showing me whenever a new font got loaded - so turning off that printf() would probably bump me up to 50fps (which is the new fps cap on my machine).
As a further test, I removed the "Hello" TextBlock that had the FontSize attribute changes each frame. The result was that both pango and my own text layout/rendering engines jumped to ~50fps.
This suggests pango's layout calculation is where the performance bottleneck is.
I guess I'll have to dig into this problem some more later... Or, even better, maybe one of the pango developers can take a peek at Moonlight's font.cpp and see if they can maybe glean some ideas from there that they can apply to pango :)