DDigit Text Rendering Pack For Plugin Writers

[StainlessS]

Excerpt from DDigit.txt


DDigit Plugin Text Rendering Pack for Plugin writers.

// DDIGIT @ http://forum.doom9.org/showthread.php?t=156888


First Release 17 Sept 2010, Wrongly Date named DDigit_25_dll_20101017
Second Release v1.0, 26 Sept 2010, DDigitTest_25_dll_20100926
Third Release v1.01, 6 March 2011. DDigitTest_25_dll_20110306
Speeded up YV12 somewhat, by thieving some of the mods from New Info.H.
Added control code parsing for formatting and color selection within print string.
Fourth v1.02, Release 11 March 2011. DDigitTest_25_dll_20110311
Fix dshift bug introduced in v1.01 Planar.
Fifth Release v1.03, 2nd June 2011. DDigitTest_25_dll_20110602
Adopted a 'new name' for the ColorSpace Independant Renderer in DDigit, new name being
"DDigit MONOLITHIC".
Added 'DDigit DISCRETE', NEW ColorSpace Dependant Renderers.
DDigit DISCRETE, has all the functionality of DDigit MONOLITHIC with the exception
of the vertical print functions.
Added DDigit DISCRETE to the DDigitTest() demo plugin.
Now using modified Info.h of April 2011.
Added unmodified Info.h together with an Info.h companion, InfoF.h which compliments
Info.h with formatted print via embedded control codes (see demo).

------------------------------------------------------------------------------------------

DDigit comprises of DDigit.h, and DDigit.cpp which implement a colorspace independant
text renderer (DDigit MONOLITHIC) and a colorspace dependant set of renderers
(DDigit DISCRETE). DDigit is based on the source Info.h from the Avisynth project,
but provides printing in both horizontal and vertical, pixel or character coordinates
and in 16 colors. The renderers support embedded control codes to provide both formatting
and color selection, within print strings. The renderers are bounds aware and will not
crash if text wraps off screen. Both the MONOLITHIC and DISCRETE renderers provide means
to disable unused colorspace code and also allow selection of the full font for characters
above 127 or you can save 4KB by disabling half of the font. Most of the options of
DDigit are switch off-able, even the ability to parse control codes in strings, disabling
these options will result in a reduction of code size. There is pretty much zero reason
to edit out any source code, so if anyone decides to grab a copy from your plugin source,
they should have the complete source files.

DDigit supports planar formats eg YV12, YUY2, RGB32 and RGB24, and in color for all
except of course Y8.

The only really small problem I see is that there has been no attempt to cope with
any special color palette for Y8, so you would get whatever luma value any
particular color would have had (and they are not in ascending order of value).

Further on color, the colors took a fair bit of time to select, it aint easy finding
ones that dont look rubbish under YV12. However, all colors chosen look pretty good
with the exception of one, DDIGIT_ORANGERED which is a bit blurry BUT was chosen
as a sort catastrophic error denoting color and so is not expected to be used
frequently. The colors chosen, all came from the standard Color Presets AVSI file,
Thought I should restrict myself to using standard color names rather than making
my own up, eg, DDIGIT_FISHFINGER_ORANGE or DDIGIT_PUTRID_PUCE.

Control codes within print strings.
'\n', Newline, positioning cursor 1 line down and at left edge of screen.
'\r', Newline Special, moves 1 line down and positions cursor at original on-entry X position.
'\b', Backspace, obvious, not sure how useful this will be.
'\f', Forward Space, again obvious, re-uses formfeed code for this. Again, maybe not so useful.
'\t', Tab, @ character positions, every 4 characters.(relative screen LHS).
'\a', Color selection control code. Followed by any one of '0123456789ABCDEF-!*'.
0 -> F select the colors 0 -> 15. (lower case also allowed)
'-' selects DDIGIT_DEFAULT.
'!' selects DDIGIT_HILITE.
'*' selects the on entry color.



To configure DDigit, Edit the lines contained at the beginning of the DDigit.H file:-

// ---------------------------------------------------------------------------------
// !!! Below lines configure DDIGIT and remove code, Edit as required !!!
//
// NOTE, DDigitTest enables BOTH MONOLITHIC & DISCRETE colorspace code, you are UNLIKELY to want this.
// NOTE, Enabling any of below, without enabling the code it affects, will do nothing.
// ---------------------------------------------------------------------------------
// ---------------------------------------------------------------------------------
// !!! ONE (or rarely both) OF THE BELOW TWO SHOULD BE ENABLED !!!
//
// MONOLITHIC ColorSpace Independant code, Includes Horiz,Vert,pixel,char, 16 color print, ctrl codes.
#define DDIGIT_ENABLE_MONOLITHIC_CODE // DDigitS()
//
// DISCRETE ColorSpace code, eg DrawStringRGB24() @ pixel coords (optional, color, ctrl codes).
#define DDIGIT_ENABLE_DISCRETE_COLORSPACE_CODE // Does not require additional DrawString stubs.
//
// ---------------------------------------------------------------------------------
// ----------------------------------------------------------------------------------
// MONOLITHIC ONLY config [Stubs Additional to DDigitS()]
#define DDIGIT_INCLUDE_DRAWSTRING_FUNCTIONS // Stubs, Print Strings @ Pixel Coords
#define DDIGIT_INCLUDE_DRAWSTRING_VERTICAL // Stubs, Print Vertical Strings @ Pixel Coords
#define DDIGIT_INCLUDE_DRAWSTR_VERTICAL // Stubs, Print Vertical Strings @ Char Coords
//----
// BOTH Monolithic & DISCRETE color space config
#define DDIGIT_INCLUDE_DRAWSTR_FUNCTIONS // Stubs, Print Strings @ Character Coords
// ColorSpaces to enable support for (Affects BOTH MONOLITHIC & DISCRETE COLOR SPACE CODE)
#define DDIGIT_ENABLE_SUPPORT_PLANAR // Enable PLANAR eg YV12 Support
#define DDIGIT_ENABLE_SUPPORT_YUY2 // Enable YUY2 Support
#define DDIGIT_ENABLE_SUPPORT_RGB32 // Enable RGB32 Support
#define DDIGIT_ENABLE_SUPPORT_RGB24 // Enable RGB24 Support
// BOTH, Enable control code handling support in print strings, including color control.
#define DDIGIT_ENABLE_SUPPORT_CONTROL_CODES // Formatting + 16 color ctrl.
// BOTH, Font, Enable full character set (incl 128 to 223), Comment out saves 4kb (ASCII 32-127 only)
#define DDIGIT_ENABLE_EXTENDED_ASCII // Disable this, omits half of the font.
//
// --------------------------------------------------------------------------------
// --------------------------------------------------------------------------------
// --------------------------------------------------------------------------------
//
// ------------ Other possible configuration stuff
#define DDIGIT_TABCNT 4 // Tab step setting (4)
// Color index's used for defaults
#define DDIGIT_INDEX_TO_USE_AS_DEFAULT DDIGIT_WHITE // DDIGIT_WHITE
#define DDIGIT_INDEX_TO_USE_AS_HILITE DDIGIT_ORANGE // DDIGIT_ORANGE
//
// ---------------------------------------------------------------------------------


DDigit MONOLITHIC:- Enabled via, #define DDIGIT_ENABLE_MONOLITHIC_CODE

// Draw EXT ASCII string at [x,y] PIXEL or CHARACTER coords with color[16] selection
// of forground. pix==true = pixel coords: vert==true = Vertical (top down printing)
// ctrl = false, temporarily disables control code handling, just used in testing full
// character set printing in Demo.

extern void __stdcall DDigitS(const VideoInfo &vi,PVideoFrame &dst,int x,int y,int color, \
const bool pix,const bool vert,const char *s,bool ctrl=true);


DDigitS() is the lo level MONOLITHIC core of DDigit. It implements printing at pixel and character
coordinates, both horizontally and vertically in 16 different colors for strings. There
is no individual routine for printing lone characters, only strings are handled.

The above defines eg: DDIGIT_INCLUDE_DRAWSTRING_FUNCTIONS make available stub routines
which just make the calling of DDigitS() a little easier, in this case it makes available
3 overloaded routines for printing text at pixel positions, horizontally, ie:

DrawString(const VideoInfo &vi,PVideoFrame &dst,int x,int y,int color,const char *s);
DrawString(const VideoInfo &vi,PVideoFrame &dst,int x,int y,const char *s);
DrawString(const VideoInfo &vi,PVideoFrame &dst,int x,int y,bool hilite,const char *s);

where you can call the stub with no color argument (defaults to white), with a bool
to denote hilite ON/OFF status (hi-lite ON in Orange), or with an int to denote
a color index 0-15. The 1st stub above is implemented as so:-

void __stdcall DrawString(const VideoInfo &vi,PVideoFrame &dst,int x,int y,int color,const char *s) {
DDigitS(vi,dst, x, y, color ,true,false, s); // color is an index
}

so there is no iterative calling of DDigitS() to render strings, DDigitS, does it all and
the overhead of the DrawString() type stubs is so small as to make it unnecessary to
disable them, even if you dont use them, but the option is there.

Anyway, take a look at the DDigit.H header file for further info.

If you mistakenly call DDigitS() for a colorspace that has not being enabled, then
nothing will happen, ie it will not crash, it just will not do anything.

// ---------------------------------------------------------------------------------

DDigit DISCRETE:- Enabled via, #define DDIGIT_ENABLE_DISCRETE_COLORSPACE_CODE

Enabling the DISCRETE colorspace code will generate code for the enabled colorspaces,
eg if you #define DDIGIT_ENABLE_SUPPORT_PLANAR then these functions will be added:-

void DrawStringPlanar(PVideoFrame &dst, int x, int y, int color,const char *s,bool ctrl=true);
void DrawStringPlanar(PVideoFrame &dst, int x, int y, bool hilite,const char *s);
void DrawStringPlanar(PVideoFrame &dst, int x, int y, const char *s);

if you also #define DDIGIT_INCLUDE_DRAWSTR_FUNCTIONS then these function stubs will be added for character coords.
void DrawStrPlanar(PVideoFrame &dst, int x, int y, int color, const char *s);
void DrawStrPlanar(PVideoFrame &dst, int x, int y, bool hilite, const char *s);
void DrawStrPlanar(PVideoFrame &dst, int x, int y, const char *s);

NOTE, The MONOLITHIC code requires a VideoInfo reference in the args list, whereas the DISCRETE code does not.

// ---------------------------------------------------------------------------------

Also included, a 'throw away' plugin that just shows DDigit in action,
nothing special but it does the job.
If you do take a look at it, dont forget to remove it from your plugins directory
afterwards. Plugin name "DDigitTest.DLL", compiled for Avisynth 2.5 ONLY, does NOT
Support 2.6 color spaces (except Y8 under 2.6). Perhaps you might like to compile
a 2.6 version yourself.

Args:-
DDigitTest() // Defaults to -1, SHOW MONOLITHIC DEMO
DDigitTest(-1) // SHOW MONOLITHIC DEMO
DDigitTest(-2) // SHOW DISCRETE DEMO
DDigitTest(-3) // SHOW short DEMO for new Info.h
DDigitTest(0) // Speed Test, No Print
DDigitTest(1) // Speed Test, DDIGIT MONOLITHIC
DDigitTest(2) // Speed Test, DDIGIT DISCRETE
DDigitTest(3) // Speed Test, INFO.H

Note, the above args have changed from previous versions of DDigittest.

Use the included AVS files.
DDigitDemo.AVS
DDigitTimeTest.AVS

Anyways, hope you find a use for it.

StainlessS @ Doom9.
// ---------------------------------------------------------------------------------

The new Info.h also now implements bounds checking and can be obtained from the
below address if you would prefer to use that:-

http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/

Or,

The Info.h of 17 April 2011 is included with this package (together with a
companion header, InfoF.h, providing Info.h with formatted printing).

DDigit is now released together with the DDigitTest.dll used as both
a demo and speed test for DDigit, also handy to spot errors if DDigit
is modified. Get the DDigitTest download.

LATEST UPDATE:- v1.03 - 2nd June 2011

EDIT:- Added "InfoF.H" for those that might want to try the
companion header that allows formatted print at both pixel and character
coords via the standard Info.h (April 2011 ver$ included), (of course no
color control is possible). Just include the InfoF.h header after Info.h and
call the InfoF.h functions when either character or formatted print is required.
See:-Info_h_April_2011_Plus_InfoF.H.zip


see HERE (http://www.mediafire.com/StainlessS)

Or the Attachments when approved.

[IanB]

For those who do not want the multimegabyte deluge of advertising just for a 75K zip.

[StainlessS]

Really not sure what I've done wrong again, BUT ...
feel like I have had my arse kicked ... Again.
(Feel like the text in sig, is very pertinent)
PS, Plugin dated 1 month in future, no excuse, never
quite sure what day/month/year it is.
(If it gives the impression that I'm thinking ahead, this is accidental)

[IanB]

@StainlessS,

Nothing wrong. The site linked insisted on getting in my face before letting me download, so as a community service I attached your useful contribution directly to the forum. ;)

[StainlessS]

Thanx Mr B, Must be getting paranoid.

[StainlessS]

I was wondering how DDigit compared with Info.H (from v2.5.8 source) for
speed and so knocked up a little test.

sprintf(buf,"0");
DrawStr(vi,dst,0,0,buf); // Ensure that caching plays no part
sprintf(buf,"TEST 1234567890ABCDEFGHIJKLMNOPQRS"); // Prefill buffer
if(arg) {
if(arg==1) {
for(y=0; y< 16;++y) { // INFO.H
DrawStringYUY2(dst,0*DDIGIT_CHAR_WIDTH,y*DDIGIT_CHAR_HEIGHT,buf);
}
} else {
for(y=0; y< 16;++y) { // DDIGIT
DrawString(vi,dst,0*DDIGIT_CHAR_WIDTH,y*DDIGIT_CHAR_HEIGHT,buf);
}
}
}


and the AVS

AviSource("D:\AVS\TEST.AVI").AssumeFPS(250.0).ConvertToYUY2()
return Test(2) # 0 = no print, 1 = Info.h, 2 = DDigit


Here are results in seconds, to render clip in VDub:


NOPRINT INFO.H DDIGIT
YV12 51 154 86
YUY2 46 116 56
RGB32 58 144 64

EDIT: !!! IGNORE THE ABOVE TIMINGS, TOTALLY MISLEADING !!!
:o

Timing were not very accurate, just used system time/date and
any timing could have been 1 or 2 seconds out. Also did not disable
Anti virus nor HIPS during test, but should give reasonable idea.

The Info.h test called the particular color space code directly where
the DDigit call was colorspace independant, also had to fix bug in
Info.h RGB32 source as it produced an access violation, below line.

unsigned char *dp = &dst->GetWritePtr()[(x + tx) * 4 + (dst->GetHeight()-1 - (y + ty)) * pitch];

Had to add the -1 after GetHeight() as it was "out of bitmap". Fixed this some time ago, in
DDigit, forgot that it was still there.

I was pleasantly surprised, I would have been happy had it been of comparible speed,
but it does quite well.

[IanB]

@StainlessS,

Thanks for reporting the height off by 1 in the RGB code bug.

I had noticed you cleaned up the parsing algorithm in your version. For performance this is a very good example of the "Never look down" rule.

Here is the the original info.h code. It scans across the font element in vertical stripes. It stresses the L1 cache by hitting both the same font and video memory 20 times in the inner loop. Definitely lots of looking down here :devil: const int pitchY = dst->GetPitch(PLANAR_Y);
BYTE* const dstpY = dst->GetWritePtr(PLANAR_Y);
for (tx = 0; tx < 10; tx++)
{
for (ty = 0; ty < 20; ty++)
{
dpY = &dstpY[(x + tx) + (y + ty) * pitchY];
if (font[num][ty] & (1 << (15 - tx)))
{
*dpY = 230;
} else
{
*dpY = (unsigned char) (((*dpY-16) * 7) >> 3) + 16;
}
}
}


Here is StainlessS' implementation it scans down the font element in horizontal stripes. It accesses each font line only once and accesses the video memory strictly sequentially.unsigned char *dpY = &dst->GetWritePtr(PLANAR_Y)[y * pitch];
for (int tyy = 0; tyy < DDIGIT_CHAR_HEIGHT; dpY += pitch, tyy++) {
if((y+tyy >= 0)&&(y+tyy < height)) {
unsigned short fbm=DDigitFont[num][tyy];
unsigned char* rp = &dpY[x];
for (int tx = 0; tx < DDIGIT_CHAR_WIDTH; fbm<<=1U,++rp, ++tx) {
if((x+tx >= 0) && (x+tx < rowsize)) {
if (fbm & 0x8000U) { // Character Foreground SET Pixel ?
*rp = c1; // Set Luma Foreground Pixel
} else {
*rp=(unsigned char)(((*rp-16)*7)>>3)+16;// Background, Luma*=7/8
}
}
}
}
}

A remaining minor optimisation could be to move the 2 bound tests outside the loops and precalculate DDigitFontNum as &DDigitFont[Num][0].

Leaving this as the inner loops :-...
for (int tyy = tytop; tyy < tybot; dpY += pitch, tyy++) {
unsigned short fbm=DDigitFontNum[tyy]<<txleft;
unsigned char* rp = &dpY[x];
for (int tx = txleft; tx < txright; fbm<<=1U,++rp, ++tx) {
if (fbm & 0x8000U) { // Character Foreground SET Pixel ?
*rp = c1; // Set Luma Foreground Pixel
} else {
*rp=(unsigned char)(((*rp-16)*7)>>3)+16;// Background, Luma*=7/8
}
}
}

[StainlessS]

Well, what can I say, The previously posted times are a little misleading,
I had done the tests with a DEBUG version of the DLL which affected timings greatly,
more so for INFO.H than for DDigit, perhaps because DDigit is less dependent upon cache.
Either Ram Cache is disabled during debug execution, or perhaps the system does some
kind of covert monitoring. I tried killing off Antivirus and HIPS, all non essential
services etc including the MS MDM.EXE and still it goes quite slowly.

OK, I know you all hate me, I did try putting my head in the gas oven
(had heard that it is a painless way to go), but just could not do it.
Every time I fell asleep I woke up screaming when I burnt my ear on
the roast potato tin, and my hair kept catching fire.
It aint that painless, I can tell you. :o

Here are the revised timings,


Visual Studio 6

NOPRINT INFO.H DDigit
YV12 49.92 96.22 79.38
YUY2 48.83 63.22 58.53 (No ConvertToYUY2() as source was huffyuv)
RGB32 57.66 73.25 65.70
RGB24 57.66 72.69 65.41
Y8 63.38 76.98 68.11 (With ConvertToRGB32() to view)

Toolkit 2003

NOPRINT INFO.H DDigit
YV12 49.81 87.88 77.02
YUY2 48.55 60.36 56.45
RGB32 57.05 71.86 62.89

Also have folder C:\Program Files\Microsoft Visual Studio 8, dont know
where this came from, have a number of SDK's installed, maybe one of those
installed it, or perhaps left over from VS 2005 Lite edition. Anyway, compiled
with that and:

INFO.H DDigit
YV12 92.31 78.23

Also compiled DEBUG,

INFO.H DDigit
YV12 452.61 95.00

Yes, that's NOT a typo, 452 seconds, about 7 frames per second.

Perhaps it linked with a not quite compatible library or something,
but DDigit worked reasonably well.

Have implemented changes suggested by IanB, dont really think it
can be optimised much more.

@ IanB,

Could you please remove or replace link to Doom9, update DDigit via link in
opening post.

Anyways find second release via first post, also DDigitTest.DLL has been
updated to include the timing test, Compiled with TK 2003.

EDIT: Also note, the speed test has been modified since previous timings,
now fills entire screen except bottom line, reserved for timing readout.

[StainlessS]

@ IanB,

When at last attachment has cleared, can you please delete
the wrongly dated first one (DDigit_25_dll_20101017.zip),
it contains a little bug in that the DDIGIT_CHARACTERS
define is 224 instead of (224-32) ie 192. Thankyou. :)

[frustum]

Stainless, kudos; this has come in quite handy. I had started doing this myself and had spent an hour on it, adding yuy2 and rgb support (and swapping the x/y sweep order), then finding out that rgb buffers are upside down. I accidentally find your lib when looking for some other info. Not only is is more general and foolproof than what I was doing, it took under five minutes to download the zip, copy the files, and slightly change my calling convention. It worked the first time!

[StainlessS]

@Frustum

Glad it worx for U, always nice to hear ones work is of some use.
If you ever try implementing a v2.6 plugin, let us know (either way)
whether it works ok for eg YV24 etc.

[IanB]

I removed the other DDigit_25_dll_20101017.zip download. Hopefully this is the right one this time. :o

Also, all this tuning prompted me to re-factor info.h with major surgery, it does loops in the most optimal order now and the YV12 routine is now planar generic and is renamed to DrawStringPlanar(...). Man was the original code slow!

[StainlessS]

I removed the other DDigit_25_dll_20101017.zip download.

Thankyou.

I would be quite interested in seeing the source for new
Info.h, have you a link please.

EDIT: I did at one point try to call colourspace dependent
fn's from within DDigitS() to do the rendering loops, providing
the pre-calculated args as a structure so as not to have
lots of stack args, but this turned out no faster than the
current DDigitS() method. Idea being that the smaller
and lighter colourspace dependent fn's would provide
better compiler register optimizations. As you seem to have
kept Info.h colourspace dependent, I would expect a little
bit better speed from yours, as the complex/heavy code
in DDigitS() would likely make register optimizations difficult for
the compiler.

[IanB]

As always in the CVS repository, avisynth > src > core > info.h (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/info.h?revision=1.7&view=markup).

No way X86 has enough registers to do all 3 loops plus the decisioning, but it doesn't really matter that much, this is C++, not hand optimised assembler. As I have restructured the code, the inner loop executes 10 times, bit shifting the font mask in a single int and sequentially accessing the pixel line data. The middle loop executes strlen(text) times, it picks up the next font mask and has the inner loop continue sequentially accessing the pixel line data. This maximises L1 cache performance for video pixels. The outer loop executes 20 times and has the middle loop re-access the text string data each time, but this is 1 access per 10 pixel accesses, the L2 cache can easily manage this. The pixels data access commence on the next line. But all this is pretty theoretical, practically all the improvement happened just by reversing the row/column order, moving the text scan into the middle loop gained a very minor amount.

Also the level at which these functions are targeted does not necessarily have access to a VideoInfo structure, to be able to select the appropriate routine would need this information and possibly limit the applicability of the code. When coding Avisynth functions best practice is to make pixel type and other VideoInfo decisions in the class constructor and then have the GetFrame routine blindly crank the handle.

[StainlessS]

As always in the CVS repository, avisynth > src > core > info.h (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/info.h?revision=1.7&view=markup).

Arh well, got to figure out how that CVS stuff works, I got my
copy of v2.58 out of some zip, somewhere. Thanx for the link,
dont need to ask again.

Will come back when less well served with ale.

However, I do think I should point out something, I dont know
whether you rejected or did not spot the significance,
but the code marked in DDigitS() as EXT ASCII bug fix
might demand a little more consideration.

The code in the new Info.h does not strictly detect and avoid
problematic cases where out of font access is concerned.
As far as I know there is no Avisynth mandate that 'char' should
be either signed or unsigned, but in either case, the new Info.h
code dont perform to exacting standards.

Valid characters are from 32 (SPACE) to 223 (ydieresis) with
font index's of 0 to 191.

EDIT:-
Current Info.h
int num = s[si] - ' ';
if (num < 0) num = 0;

The DDigitS() code, (replacing CONSTANTS) :-



int num = s[si]; // or *s;
num = (num - ' ') & 0xFF; // Conv font ix, Ensure +ve char (Fix EXT ASCII bug)
if(num >= 192)
num = 0; // Not in font, convert to SPACE

The subtraction and AND, result in an unsigned 8 bits of int
whether signed or unsigned char was concerned
(with or without the Visual Studio /J switch)
The comparison with 192, detects both characters that were less
than 32 (SPACE) or greater 223 (ydieresis) as all of the
invalid characters less than 32 will wrap around
to the font index interval 224 to 255. The invalid characters
224 to 255 will be in the font index range 192 to 223.

Also, the above snippet will correct any sign extension probs
propagated from, eg clients of the old DrawDigitYUY2 that
might use eg " *s - 32 " whether char is signed or not.

Info.h, as it stands, when signed char is used EXT ASCII
characters 128 & above [eg (c)opyright, chr$(137), I think]
will not print (never did under old Info.h) and if unsigned
then characters 224 and above will reach out of font with
rubbish results and potential access violation.


Still gotta digest the new Info.h, well impressed.

Gotta go chuck another can of Swan on the barbie.

Thanx for being Mr B, :)

[StainlessS]

Have knocked up a new version of DDigitTest which does a simpler
series of tests for the new Info.h, showing the full character set,
chars 0 through 31 (invalid), 32 though 191 and 192 through 255
(invalid).

Also timing test included for new Info.h.

Here's some test timings:

NOPRINT NEW_INFO.H DDIGIT
YV12 65.92 73.83 103.72
YUY2 23.63 26.66 28.06
RGB32 21.89 28.86 28.42
Y8 35.28 37.19 37.77

WOW!, Mr B, looks like I could do better with YV12.

Included in this temporary pack are three dll versions,
orig new info.h both with and withough /J switch,
ie unsigned and signed char versions, both showing
font range errors. And, a modified version new info.h
with the EXT ASCII fix applied showing proper output.

Got to dash before the bank shuts.

Here's a temporary link to this release, It will at some
time be deleted.

EDIT: Link DELETED

EDIT: The EXT ASCII bug fix is switched via "#define FIX_EXTASCII"
near the beginning of "Info_NEW.h".

[StainlessS]

New Version DDigit v1.01 see first post.

v1.01, Mar 6 2011, Added control code parsing within print strings.
'\n', Newline, positioning cursor 1 line down and at left edge of screen.
'\r', Newline Special, moves 1 line down and positions cursor at original X position.
'\b', Backspace, obvious, not sure how useful this will be.
'\f', Forward Space, again obvious, re-uses formfeed code for this. Again, maybe not so useful.
'\t', Tab, @ character positions, every 4 characters.(relative screen LHS).
'\a', Color selection control code. Followed by any one of '0123456789ABCDEF-!*'.
0 -> F select the colors 0 -> 15.
'-' selects DDIGIT_DEFAULT.
'!' selects DDIGIT_HILITE.
'*' selects the on entry color.

YV12 speeded up somewhat.

Revised timing using DDigit v1.01 and Timings for new Info.h
of Oct 2010.

NOPRINT INFO.H(new) DDIGIT (1st figure average of 3, 2nd best time of 3 runs)

YV12 68.48 76.60 77.74
67.83 76.27 77.38

YUY2 24.22 27.16 28.71
23.80 27.03 28.50

RGB32 21.87 27.31 28.89
21.84 27.13 28.22

RGB24 25.64 28.41 29.95
25.61 28.28 29.83

Y8 35.04 38.88 39.33
34.50 38.75 39.28

[StainlessS]

New Version DDigit v1.02 see first post.

Fix for planar dshift bug introduced in v1.01 6 Mar 2011.
Would not really affect YV12 (except perhaps printing last character in font,
ie ydieresis). Would though present problems in planar colorspaces where
there are vertically 4 luma samples to 1 chroma sample.
Hopefully, I got it right this time. :)
PS, planar speed test times may have gone up one or two tenths of a second.

[StainlessS]

New Version DDigit v1.03 see first post.

Adopted a 'new name' for the ColorSpace Independant Renderer in DDigit, new name being
"DDigit MONOLITHIC".
Added 'DDigit DISCRETE', NEW ColorSpace Dependant Renderers.
DDigit DISCRETE, has all the functionality of DDigit MONOLITHIC with the exception
of the vertical print functions.
Added DDigit DISCRETE to the DDigitTest() demo plugin.
Now using modified Info.h of April 2011.
Added unmodified Info.h together with an Info.h companion, InfoF.h which compliments
Info.h with formatted print via embedded control codes (see demo).

No timing test at present, really got to get some sleep before I fall down.

[StainlessS]

Timings for DDigitTest v1.03, 2nd June 2011

Compiled with Toolkit 2003, Optimizing Compiler.

DDigit DDigit April 2010
NOPRINT MONOLITHIC DISCRETE INFO_H

RGB24 23.70 27.62 28.03 26.02
23.66 27.19 27.33 25.98

RGB32 20.09 26.68 26.88 25.46
19.98 26.66 26.86 25.45

YUY2 22.77 24.14 24.05 24.17
22.75 24.11 24.05 24.17

YV12 55.50 65.45 65.09 64.64
55.45 65.38 65.06 64.59

Y8 31.86 35.90 35.40 35.90
31.38 35.80 35.34 35.86

Compiled with MS VS6

DDigit DDigit April 2010
NOPRINT MONOLITHIC DISCRETE INFO_H

RGB24 23.70 28.67 27.90 27.65
23.66 28.66 27.02 27.52

RGB32 20.10 27.78 26.97 27.08
20.05 27.75 26.95 27.00

YUY2 22.85 25.12 25.55 23.88
22.80 25.08 25.53 23.56

YV12 55.38 67.52 65.58 65.92
55.36 66.92 65.58 65.89

Y8 31.27 37.36 35.46 35.97
31.25 37.31 35.41 35.92


1st Time = average of 3 runs, 2nd = fastest of 3 runs.

RGB32 was without ConvertToRGB32 (BlankClip default)

Y8 was with ConvertToRGB24 for viewing.

Timing can vary by as much as ~ 1.25 seconds.

[StainlessS]

A VERY minor mod to InfoF.h, the Info.h companion for printing
formatted text, no real need to change it but here it is anyway.

These are the lines as they were:


const unsigned char *se, *ss; // unsigned
for(ss=(unsigned char*)s; *ss; ss=se) { // while, some to do
int n;
for(se=ss; n = *se, n>=' ' && n <= 223; ++se); // Find end+1 of printable
int len = se - ss; // Len of printable
if (len) { // Some to print
DrawStringPlanar(dst,x,y,(const char*)ss,len);

And here is the entire mod:

void __stdcall DrawFStringPlanar(PVideoFrame &dst,int x,int y,const char *s,bool pix = true)
{ // Draw formatted string at pixel or character coords, pix == false = character coords
if(pix == false) {x *= 10; y *= 20;} // To Chars
int in_x = x; // REM x for '\r'
const unsigned char *se=(unsigned char*)s; // unsigned
while(*se) { // while, some to do
int n;
for(s=(char*)se; n = *se, n>=' ' && n <= 223; ++se); // Find end+1 of printable
int len = (char*)se - s; // Len of printable
if (len) { // Some to print
DrawStringPlanar(dst,x,y,s,len); // do the biz
x += len * 10; // update x coord
} else { // Ctrl code OR nonsense;
if(n == '\n') {
x = 0; y+=20; // Newline, down 1, LHS
} else if (n == '\r') {
x = in_x; y +=20; // Newline Special, Down 1, orig x coord
} else if(n == '\b') {
x -= 10; // Backward Space
} else if (n == '\f') {
x += 10; // Forward Space
} else if (n == '\t') {
x+= ((4*10)-(x%(4*10))); // H-Tab (step 4)
}
++se; // skip ctrl code (and unknowns, outer loop detects nul sentinel)
}
}
}

void __stdcall DrawFStrPlanar(PVideoFrame &dst,int x,int y,const char *s)
{ // Formatted Print @ character coords
DrawFStringPlanar(dst,x,y,s,false);
}


The mod just saves a bit of swapping about of pointers.
The above code is for the Planar rendering function only,
amend the other 3 also. :)

EDIT:- shall within minutes of this edit, add (above modified) "InfoF.H"
to the 1st post for those that might want to try the companion header that
allows formatted print at both pixel and character coords via the standard
Info.h, (of course no color control is possible). Just include the
InfoF.h header after Info.h and call the InfoF.h functions when
either character or formatted print is required.

[StainlessS]

Is there any chance that a moderator could at some stage, approve the
2nd attachment in the first post, if there seems to be a problem, I could
always delete it, (or save me the bother and do it yourselves).
About 7 days waiting now. ta. :)

[Wilbert]

About 7 days waiting now. ta.
Done.