Difficulty building the project with expanded color features for SDL

[JoyBunny]

I'm not 100% sure this is how to use the issue tracker, and maybe this is more a symptom of my lack of experience than a problem with the project. I've struggled with understanding wmcbrine/PDCurses too.

I had MinGW on my Windows 7 machine when I managed to build the SDL version of the library, but newtest.c is not set up to compile in the makefile. So I took a stab and added it there myself. After compiling, I was able to successfully run the .exe, but somehow or another I can't replicate the same effect on Windows as seen in this screenshot on your page: www.projectpluto.com/win32a.gif

Blinking never worked properly. But more annoyingly, the text meant to demonstrate full RGB was a mess and seems to have something to do with the program not having 64-bit chtypes or something? I literally have no idea, and this is probably where my newbish inclinations are showing.

So if I'm not being too annoying, can you explain to me like I'm five just how to build the library properly and set up the compiler/code to use these features correctly? I studied the syntax closely in newtest.c so I sort of understand it, but without being to replicate that behavior I'm just at a loss.

[Bill-Gray]

My apologies;  I think I led you astray here.

The different "flavors" of PDCurses support things to different

levels. Win32a supports just about everything: blinking text,
combining and full-width characters, RGB text, etc., etc. X11
supports almost everything (no Unicode past 64K, nor combining
characters or full-width, but pretty much everything else.)

SDL is the poor stepchild here.  For a long time,  I wasn't very

interested in it, because it didn't support Unicode. An 8-bit
solution in 2016 wasn't at all appealing. Fortunately, Laura
Michaels stepped up to the plate and added Unicode output, so I
do see some hope for SDL as a useful option.

However,  this is relatively recent,  and the SDL flavor of

PDCurses lacks RGB or blinking text. The blinking may not be all
that easy. I knew how to set up timer events through the Win32
API for the Win32a flavor, and Mark Hessling had already done the
heavy lifting in that department for X11. In both cases, some
code can be triggered every half second to reverse blinking text
(and to blink the cursor). But I don't know how to set up anything
similar in SDL, or even if it's possible.

'newtest',  if run with the SDL flavor,  should show the 'Text

in a box' actually in a box, and the 'Underlined' text should
be underlined. If you compiled with 'make WIDE=Y', then if you
expand the window a few lines, you should see some text in Spanish,
Russian, Greek, and Georgian. (Plus some garbage text where
the fullwidth and combined characters are incorrectly displayed.)
The 'Red on green to white on black', etc. text will be shown in
a variety of colors, but not the gradual changes shown in the GIF
you mentioned. Come to think of it, I should provide a PNG :

http://www.projectpluto.com/sdl_newtest.png

Note that this was a result on Linux.  Yours should look almost

exactly like this, and you may need to resize the window a little.

About the only modest crumb of support I can offer here is that

I hadn't noticed that 'Makefile.mng' didn't build the 'newtest' demo;
I've just fixed that.

-- Bill

On 2016-05-26 20:20, JoyBunny wrote:

I'm not 100% sure this is how to use the issue tracker, and maybe this is more a symptom
of my lack of experience than a problem with the project. I've struggled with
understanding wmcbrine/PDCurses too.

I had MinGW on my Windows 7 machine when I managed to build the SDL version of the
library, but newtest.c is not set up to compile in the makefile. So I took a stab and
added it there myself. After compiling, I was able to successfully run the .exe, but
somehow or another I can't replicate the same effect on Windows as seen in this
screenshot on your page: www.projectpluto.com/win32a.gif
http://www.projectpluto.com/win32a.gif

Blinking never worked properly. But more annoyingly, the text meant to demonstrate full
RGB was a mess and seems to have something to do with the program not having 64-bit
chtypes or something? I literally have no idea, and this is probably where my newbish
inclinations are showing.

So if I'm not being too annoying, can you explain to me like I'm five just how to build
the library properly and set up the compiler/code to use these features correctly? I
studied the syntax closely in newtest.c so I sort of understand it, but without being to
replicate that behavior I'm just at a loss.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Bill-Gray/PDCurses/issues/6, or mute the thread
https://github.com/notifications/unsubscribe/AP6BrtfIP1u4O9hP2w_-D5QiE7FeGf3Dks5qFjjVgaJpZM4IoEcm.

[JoyBunny]

Gotcha, I think I understand a little better. I will try to better understand the differences between the different versions to use the one best suited to my needs.

On an unrelated side note, do you understand how to use sdlfonts with pdcurses? McBrine gave me a link to https://sourceforge.net/projects/pdcurses/files/sdlfonts/1.0/ but I'm a bit confused how to build with it.

[JoyBunny]

Hello? Was that a stupid question?

[Bill-Gray]

On 2016-05-27 21:40, JoyBunny wrote:

Hello? Was that a stupid question?

Nope.  (Partially witnessed to by the fact that I didn't know the

answer, and am not completely certain that I do now. I think I did
some things with those fonts years ago, but long enough that I'm
not even sure that's true, and definitely long enough that I've
forgotten exactly what it was I did.)

But if I'm reading the code correctly,  it's about like this :

If you compile _without_ WIDE=Y,  i.e.,  you want legacy-style

8-bit code, it defaults to using the font defined in 'deffont.h'.
As that file will tell you, this is a simple font defined in memory,
and has the advantage that it will Just Work without needing to load
some .bmp file into memory.

However,  you can supply one of the .bmp files given in sdlfonts

and have that used instead. Look at line 162 and following in
'pdcscrn.c'. If you've set the environment variable 'PDC_FONT'
equal to a font file name, it'll get loaded and that font will
be used. If not, it'll look for 'pdcfont.bmp'. Only if both of
those fail does it give up and use the deffont.h font.

OK,  that's the non-wide,  legacy version.  If you _do_ have

WIDE=Y, the code in the preceding thirty or so lines is used
(between #ifdef PDC_WIDE and #else). Here, a TrueType font is
loaded, also specified via PDC_FONT, and you can specify a size
via PDC_FONT_SIZE.

With WIDE=Y,  only TrueType fonts can be used,  and the

'sdlfonts' .bmp files can be used, and you get Unicode up to
64K. Without it, TrueType cannot be used, only the sdlfonts
can be used, and you only get the 8-bit font.

That,  I _think_,  is what's going on here.

-- Bill

[JoyBunny]

Ok, so let's say I'm opting for the "pdcfont.bmp" method because it seems like the easiest one to do.

If I make a program that uses this library, where exactly does the font need to go? In the same place as the executable? The executable that directly calls initscrn().

That's what I've been opting to do, but no matter what I try, it uses the font in deffont.h instead.

[Bill-Gray]

On 2016-05-28 18:09, JoyBunny wrote:

Ok, so let's say I'm opting for the "pdcfont.bmp" method because it seems like the
easiest one to do.

If I make a program that uses this library, where exactly does the font need to go? In
the same place as the executable? The executable that directly calls initscrn().

That's what I've been opting to do, but no matter what I try, it uses the font in
deffont.h instead.

Looks to me as if 'pdcfont.bmp' has to be in the current working directory.

Just to test things out,  you might try using PDC_FONT set to a fully described

path, such as

PDC_FONT=c:\foldername1\whatever\pdcfont.bmp

Then try

PDC_FONT=pdcfont.bmp

Or,  look for this line in 'pdcscrn.c' :

     pdc_font = SDL_LoadBMP(fname ? fname : "pdcfont.bmp");

And modify it to have a fully specified path :

     pdc_font = SDL_LoadBMP(fname ? fname :
                 "c:\\foldername1\\whatever\\pdcfont.bmp");

One way or the other,  you should be in business.

Oh,  yes:  also,  make sure that 'pdcfont.bmp' != the font specified in

'deffont.h'!

-- Bill

[JoyBunny]

I will definitely try in a moment, though if you change your mind and decide to test it, please please please let me know.

[JoyBunny]

Success! You will rarely find a greater idiot than I. Perhaps if my file wasn't named "pdc_font.bmp.bmp" I might have found better luck days ago.

One final question that is more specific to your fork, about the available 256 colors, before I close this issue. I want to know what sort of rhyme or reason dictates the order they are sorted in. I was trying to think of ways to line them up by hue so I could more carefully consider which ones to use and where.

In any case, all that this has convinced me to do is seriously reconsider relying on SDL if I'm not intending to extensively use its features. In that case, I would most definitely opt for your Win32a build over anything else, unless there's reasons not to?

[JoyBunny]

One more struggle before bed, I've been experimenting with many of the SDL fonts provided at the link above, and all seemed to work with colors.

I tried to make my own with the same format, but colors do not seem to work properly on them. The backgrounds will change color normally, but the fonts stay white. What am I missing here? I have my font file attached.
pdcfont.zip

[Bill-Gray]

On 2016-05-29 00:25, JoyBunny wrote:

Success! You will rarely find a greater idiot than I. Perhaps if my file wasn't named
"pdc_font.bmp.bmp" I might have found better luck days ago.

Ah,  yes... that sort of problem does seem to be the most difficult

to puzzle out.

One final question that is more specific to your fork, about the available 256 colors,
before I close this issue. I want to know what sort of rhyme or reason dictates the
order they are sorted in.

Almost none whatsoever.

The first sixteen colors,  I think,  go back to terminals where they may

have been fixed in hardware, so that you could get eight colors and then
brighter versions of those eight colors. Beyond that, there were no
standards. So when I implemented 256 colors, I just wanted something so
you could tell them apart, even if you hadn't gone to the trouble of
setting them yourself. Hence the following lines in pdcscrn.c (starting,
in the SDL flavor, at line 398; similar lines appear in the X11 and Win32a
code) :

 for( i = 16; i < 256; i++)
 {
     pdc_color[i].r = (i * 71) & 0xff;     /* semi-random palette,  just */
     pdc_color[i].g = (i * 171) & 0xff;    /* to fill colors 16-255 with */
     pdc_color[i].b = (i * 47) & 0xff;     /* visible (non-black) defaults */
 }

But you can call init_color( ) to set a more sensible color table.

I was trying to think of ways to line them up by hue so I

could more carefully consider which ones to use and where.

In any case, all that this has convinced me to do is seriously
reconsider relying on SDL if I'm not intending to extensively
use its features. In that case, I would most definitely opt
for your Win32a build over anything else, unless there's
reasons not to?

It would probably be just as well.  If you use that,  you'll get

the RGB text and "real blinking". If you decide to go cross-platform
at some point, the code should recompile with X11 and those things
would also work. As best I can tell, SDL doesn't gain anything
(at least for PDCurses), and does introduce additional dependencies.
Maybe it allows one to write code for non-X11 or Win32 situations,
such as on Android or Apple products?

Though this may be an area you might want to ask about on the PDCurses

mailing list. Quite a bit of effort went into the SDL flavor, and there
are still folks working on it (Laura Michaels, for example, got the
"wide" (Unicode) display working in the past few months). So there must
be something useful about SDL in this context. I don't know what it
is. But then again, I don't know everything.

-- Bill

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Bill-Gray/PDCurses/issues/6#issuecomment-222342050, or mute the
thread
https://github.com/notifications/unsubscribe/AP6BrmrdWp5au3h7j5w7o9J4J4T0c3koks5qGRUmgaJpZM4IoEcm.

[Bill-Gray]

Um.  Dunno what's going on there.  I suspect it's something funky

about the Windows .BMP format, which has a variety of odd extensions.
However, both your .bmp file and those in the sdlfonts.zip appear to
be relatively simple binary files.

The only difference I see (after taking a quick look at both your

file and an sdlfonts.zip one, and reading Wackypedia's description of
the .BMP format) is that you've explicitly declared two colors in your
font file. The 'sdlfonts' one goes with the default, which is two to
the power of the number of bits per pixel, i.e., also two colors. I
don't see how this would make a difference. But maybe it does. At this
point, your guess is as good as mine.

-- Bill

On 2016-05-29 02:07, JoyBunny wrote:

One more struggle before bed, I've been experimenting with many of the SDL fonts
provided at the link above, and all seemed to work with colors.

I tried to make my own with the same format, but colors do not seem to work properly on
them. The backgrounds will change color normally, but the fonts stay white. What am I
missing here? I have my font file attached.
pdcfont.zip https://github.com/Bill-Gray/PDCurses/files/288207/pdcfont.zip

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Bill-Gray/PDCurses/issues/6#issuecomment-222344667, or mute the
thread
https://github.com/notifications/unsubscribe/AP6BrnIXHYb9kNH33mxc6erYVQQEJp_Sks5qGS05gaJpZM4IoEcm.

[Bill-Gray]

We moved through really a variety of issues in this thread; I think the only thing extant is that the bitmaps for SDL1 have to be "real" binary bitmaps, not color ones that happen to have only two colors. I don't see a fix for this, nor do I see it as much of a problem, and I'm sort of hoping that SDL1 is dropped anyway in favor of SDL2 (which actually supports Unicode). So I'm closing this.