Recent Posts

Finally got back to looking at this.  The problems is caused by the new UTF-8 string.  Basically, 200 hex = 128 decimal, which is an invalid UTF-8 code point.  The solution is to add the glyphs to the GlyphFont instead.  Woopsi bitmap fonts can only have a maximum of 127 characters in them.

I've added the getCharTop() method to the entire tree of font classes, from FontBase upwards.  I've also amended the .NET tools that generate the fonts to include the correct char top values.

Have you considered splitting the truetype font code into a separate add-on library?  That'd be very handy - I can remove the freetype classes and library from the Woopsi distribution so that it compiles with fewer dependencies for people who don't need it (especially handy for the SDL build).  It would also mean that you can release the add-on library at your own pace; you won't be forced to follow the Woopsi release schedule.

Thank you ! ^^
I have forked woopsi (I need the hashmap and a few other containers, so I might clone/contribute to that too).
I'll begin porting my stuff and start commiting to it as soon as I can.

OK, these repositories contain Woopsi and its associated projects:

• http://bitbucket.org/ant512/woopsi - Main Woopsi repository (only one you need).
• http://bitbucket.org/ant512/woopsitools - C# font/bitmap tools.
• http://bitbucket.org/ant512/woopsisdlxcode - XCode/SDL version of Woopsi.
• http://bitbucket.org/ant512/woopsiextras - Odds and ends, like the HashMap class.
  

Have fun with it!

I've closed the old SourceForge site.  No further activity will take place there.

Mercurial and bitbucket are fine by me. This is going to be fun... and much easier to contribute to woopsi. ^^
Looking forward to it !

I recently learned the benefits of :
- continuous build (with hudson)
- unit testing (with google test for the nintendo ds)
- documenting code (with doxygen)
- static analysis (with the google style C++ checker)

So, I'll aim at writing good/well documented code...
(I have revisited the freetype class lately, now that I'm much better at C++, and I have some bug fixing/betterment to do there too)

On a last side note, is there a chance I could convince you to host woopsi on github and giving me commit rights for an XmlBox branch ? (I have been using git for a moment now, I think that I could learn to do with mercurial...but I won't lower to subversion)

The XmlBox is looking fantastic!  Very nice work.

I've been considering moving Woopsi to BitBucket and Mercurial from SourceForge and SVN.  I much prefer the speed and simplicity of BitBucket to the monolithic sloth of SourceForge.  If you're interested in forking Woopsi, that'll finally give me a good reason to switch.  I've already got a local mirror of the SVN repository ready to be imported into Mercurial.

There, I just uploaded a new build with a more convincing demonstration (I took the opportunity to implement class and id support) :
The top displays the text without extern css and the bottom with inline and extern css.
It is not optimised for speed at all, (I made 1 wrong design decision for the Css parser that is quite quick anyway) that I''l soon fix and I have implemented a very very bad css algorithm (a better one should be coming) I wanted to make it work first.
 

I'm displaying this xml string :

Code:

<?xml version="1.0"?><xml>
XmlBox 1.4 is a new Woopsi gadget,
with XML and CSS rendering capabilities.
<br/>
A<test border-width="1 4 2 5"  border-color="red blue green silver">border-</test>
B<test border-top-width="1" border-right-width="4" border-bottom-width="2" border-left-width="5" border-top-color="red" border-right-color="blue" border-bottom-color="green" border-left-color="silver">border</test>
C<br/>
D<test class="border">Css border</test>
E<test class="border-">Css border-</test>
F<br/>
G<test padding="1 4 2 5"  background-color="yellow" color="black">padding</test>
H<test padding-top="1" padding-right="4" padding-bottom="2" padding-left="5" background-color="yellow" color="black">padding-</test>
I<br/>
J<test class="padding">Css padding</test>
K<test class="padding-">Css padding-*</test>
L<br/>
M<test margin="1 4 2 5" border="1">margin</test>
N<test margin-top="1" margin-right="4" margin-bottom="2" margin-left="5">margin-</test>
O<br/>
P<test class="margin">Css margin</test>
Q<test class="margin-">Css margin-</test>
R<br/>
S<test font-family="truetype" font-size="13" color="red">font</test>
T<test class="font">Css font</test>U<br/>
V<test font-family="truetype" font-size="13" color="blue">some <test padding-bottom="1" border-bottom-width="1">heritance</test>, some <test>selectors <test>things</test></test> and <test  id="hehe">some id</test> in here</test>
W</xml>

with this css :

Code:

test.font {
    font-family:truetype;
    font-size:13;
    color:red;
}
test.margin {
    margin:1 4 2 5;
    border:1;
}
test.margin-{
    margin-top:1;
    margin-right:4;
    margin-bottom:2;
    margin-left:5;
}
test.padding {
    padding:1 4 2 5;
    background-color:yellow;
    color:black
}
test.padding-{
    padding-top:1;
    padding-right:4;
    padding-bottom:2;
    padding-left:5;
    background-color:yellow;
    color:black
}
test.border-{
    border-top-width:1;
    border-right-width:4;
    border-bottom-width:2;
    border-left-width:5;
    border-top-color:red;
    border-right-color:blue;
    border-bottom-color:green;
    border-left-color:silver;
}
test.border{
    border-width:1 4 2 5;
    border-color:red blue green silver;
}
test test test{
        background-color:black;
        color:white;
}
test#hehe{
    backgroud-color:blue;
    color:red;
}

I'll either try to find the bug and suggest a fix or make a simple test case.

On a side note, I have spent the last 2 weeks developping XmlBox and development has taken a new direction :
I coded a Css 1.0 parser and added basic css capabilities to the XmlBox with support for
border*-width (with *=-top,-left,-right,-bottom or empty)
border*-color
padding*
margin*
background-color
font-family
font-size
color

And it is able to render the special tags <br/>, <img/>. A build working in desmume here I'll post a better one later. This one was used to find bugs

At the present it is able to work with packed fonts and true typefonts
(either on disk...or in memory i.e converted to .o) but till some scaling routine (usefull for image rendering too) is implemented and minor modifications are made to add top (and maybee left too), packedfonts will have limited functionnalities and will present artifacts

On another side note, I ported googletest to the nintendo ds, I modified the desmume emulator to make it work with googletest and have been using unit testings for a few days to test routines/find bugs and it really rocks (and works). You interested ?

on my todo list : class, id, compile the freetype library to support chinese font (apparently the current .a doesn't), learn to use sqlite on the ds,code an app to help handle my students(marks and who is there) for work on the nds,
implement the Block formating algorithm (for the moment, everything is inline), improve the cascading algorithm (it's a simpler implementation of the specification), rewrite the css parser to just make 1 call to malloc (malloc is sooooooo slow...dicovered it by using the benchmarking routines     

Code:

cpuStartTiming(0);
some code   
u32 time = cpuEndTiming();

 

using this I'll be able to benchmark and clean the freetype code

On a last side note, is there a chance I could convince you to host woopsi on github and giving me commit rights for an XmlBox branch ? (I have been using git for a moment now, I think that I could learn to do with mercurial...but I won't lower to subversion)

Looks like there are a few bugs appearing in woopsi 0.99.2 on the nintendo ds (but not in desmume, try it in there).
I see 2 bugs, which are both probably clipping related

Bug n°1 appears when you scroll : there are elements that are disappearing too soon (probably related to the tests in woopsi that try to save computations)
It's especially obviouss with the vertical borders and the pictures...they are still  in the screen, but they aren't rendered !

The new Rect class should solve that once the woopsi internals start using it.

Bug n°2 : it looks like some text from the bottom screen is displayed on the top screen and  the opposite too.

Do you have some simple test cases for these two bugs?

I forgot to tell :
Usefull additions to the woopsi libraries are :

1)  loadPng and loadJpg methods (would be a breeze to doxygen document them)
in imageio.hpp and imageio.cpp

I have a writePng method too but I haven't put it there yet

2) a new FaceDispatcher class (fully doxygen documented)
facedispatcher.hpp and facedispatcher.cpp

3) a new XmlBox class (fully doxygen documented)
xmlbox.cpp and xmlbox.hpp

Their implementation are dependent on the files
containers.hpp and containers.cpp
my hashmap.h

that aren't fully documented yet, buit as they are subject to change...and they aren't exposed to users,
it's not that important

At some point, I'll have to clean the freetypeFont.h and .cpp files
(After I benchmark it)