Wgl Tests

[RoboNes]

just thought i'd say i've been doing some tests with rewritting the graphics parts of WGL, from scratch, some functions having been renamed, a few taken out, some drawing routines added
little pic

shows the
dprintf
string with variable width
string with fixed width
a sprite
a gfxsurface with horizontal, vertical, diagonal lines plus a triangle
triangle
and two lines

part of my motivation in doing this was the fact fonts were't working in gba in last devkitpro and the fact that the fonts took up 16bit*chars number in size, i did a 1bit font method for replacement, a 8x8 256 char file taking 3k in size

[[Papero]]

Cool!
Indeed the font system was a bit too expensive in resources...

Well, when you think it is stable enough, we can try to merge it in svn, so I can try to replace it in WinDS too

[RoboNes]

i may see if i can do something about gfxsurface, gfxsurface32k, screen32k (i left screen out, did't seem to be of any use) functions, as they basically the same functions used across all 3 classes and though screen32k is used once the gfx ones are duplicated each time a class instanced is used which is a bit wasteful in resource, and though the varaiables are needed a new, the functions are't, if i can get it without performance hinderance - i suspect this might make a difference in size even if just small one

i just wish i could figure out fast triangle fills, lol

[Francesco]

Nice job.

The Screen class was meant for the original 256 colors version of WinS and it's actually of no use. I left it in thinking about a mode-switching option, but probably there's no need to implement it.

Pay attention in renaming/removing functions cause this could cause your wgl to not compile with wins. But you know it, don't you?

[RoboNes]

no it would probably be slower using 256 col mode and things would need translating to 256 colours further slow down, probably would't be worth it for the gained memory

[RoboNes]

ok i've done changes, probably could do with proper testing, but it has a lot more functions than the current wgl, enhanced font support using compressed font (like 8bit computers used) a line command instead of just horizontal and verticle, circle and triangle support, its not optimised, but size wise there is a saving.
speed can suffer between 0.7 times slower to 3.2 times slower and in the case of pixel plotting - nearly twice as fast! even with culling to boundary box
much of the functions have a functionally to plot on backbuffer or screen directly.
software sprites, fonts, gfxsurfaces32 and screen have been updated, the others remain as they were.
there is a super graphics class in place that screen and gfxsurface32 use, and adjustments can be made to this class that will affect those two in terms or functionality and speed.

also there is at least double the number of functions for 7k less in library size (based on both compiled with same devkitpro and settings - also the version that has a problem with wgl fonts )

[[Papero]]

Well done!
Let me know if you need sone help in testing and if you want to put it in the svn repository

[RoboNes]

i'll post it soon, just hit a problem when i realised it only did 8x8 fonts, when i have some time i'll fix it up for 16x16 ones too

[RoboNes]

ok, here's the full thing, the library is 146k now because i added 6 16x16 full fonts and the 8x8 i was using, this is a good trade off(uncompressed this amount of font space alone is 400k) i think as it gives some fonts always available beyond the basic one (which i did't have so i substituted)
WGL test library link

here's all the fonts being used

there's seems to be some artifacts on the top two which i'm not sure if they are in the converted binary files or some other reason

it could do with testing of the library if anyone wants to

[[Papero]]

Great! Let me test it a little bit and I'll upload it on SVN. Btw, is this the WGL for gba only?

[RoboNes]

well i guess it should work for the ds if the screen size defines are changed for that size and a second screen setup...
but i thought it best to see about it being tested first... a conditional define could be setup in theory so it compiles with no changes for gba/ds/gp2x.. though i only have the first one myself

[[Papero]]

I have tested a litle bit your work and it seems fine, excepted for those artifacts.
Have you found where is the problem?

[RoboNes]

no, its possible its my font convertor, it was't as nice as your pic convertor, though i'm wondering if the size saving vs less speed is a issue, i'm a bit busy currently but will look into it when i've time (physically check the data of those effected fonts so see if the artifacts are present in them... or theres some other issue at play)

p.s. i did actually get it compiled with wins, but with no font displayed still but window dragging did't seem slower so at least thats one thing...

[[Papero]]

I haven't looked deeper in your code, so maybe I'm saying something you already did: have you read the TONC's text system tutorial? A 96 glyphs font is stored in less that 1 kb

In the meantime, I think I have found where is the bug in WinDS' WGL: it is something related to clipping handling. Now I need some further investigations (and a big cup of coffee) to try to solve it

[RoboNes]

yeah there is a clipping issue in my code when it comes to clipping the window against the side of the screen, in wins

the fonts, yeah i'm using the same font way (1bpp) my 8x8 font is only 2k for all 256 chars (useful for real font usage) plus 1k for font data (the existing wgl used a method of generating this on the fly (in ram) which is what i believe was failing when things changed in the devkitpro... i'm unsure what the font issue is with wins itself!!)

p.s. the tonc example, makes use of sprites (certainly simplifies code) but runs into the sprite limit for serious use plus uncompresses the font into ram(16k in the case of a 8x8) for the gba a font cache may be to much (16x16 needs 64k, 32x32 needs 256k) but for the ds would be to much issue, but a compromise could possibly be reached