OpenGL glPrint library

[Empyrion Martyr]

I found the method that returns the WindowHeight. You need to access the OpenGLWindow instance. Very soon I'll uptade a version of the dll that runs correctly, with no constant speed loss.

UPDATE: As promised, the uploaded version of the dll is here: basic4gl.wikispaces.com/file/detail/glPrint.zip

On my computer the example program now runs at 50 FPS instead of 9.

[DJLinux]

god job works here.

Joshy

[Nicky Peter Hollyoake]

Nice looks like the perfect glFont library is complete?

- Nicky

EDIT:

Can you show the source? The one thats there ain't the correct one.

- Nicky

By the way heres a few things you can change if you haven't already.

Here ...

/// My vars ///
int ascii; // get the ascii number of the chracter
int LengthOfString; // For the length of the string

/// My own functions
/// Asc
int asc (char Text) {

int ascii = Text;

return ascii;
}

Change that to ...

/// My vars ///
int LengthOfString; // For the length of the string

We don't need all that code because here ...

   LengthOfString = std::strlen(__string); // Get length of string
   for (int __glfont_i = 0; __glfont_i <= (LengthOfString-1); __glfont_i++)
   {

       // Get the ascii number of each character
       __glfont_charArray [__glfont_i] = asc(__string[__glfont_i]);
   }

Change that too ...

   LengthOfString = std::strlen(__string); // Get length of string
   for (int __glfont_i = 0; __glfont_i <= (LengthOfString-1); __glfont_i++)
   {

       // Get the ascii number of each character
       __glfont_charArray [__glfont_i] = int(__string[__glfont_i]);
   }

Putting "int" around the string in brackets will give the ascii numbers (I found on a site for an easy way round that .

Anywhere you see this ...

std::strlen (__string)

Change it too ...

__string.length()

Should be in these locations ...

   glCallLists (std::strlen (__string), GL_INT, __glfont_charArray);      // Call lists

And ...

   LengthOfString = std::strlen(__string); // Get length of string

Thats all,

- Nicky

[Empyrion Martyr]

basic4gl.wikispaces.com/file/detail/glPrint.zip

Uploaded source-code.

Nicky, good suggestions, but the "__string.length()" requires the declaration of string as "std::string". Doing this doubled the size of the final .dll, to 113.4 Kb on my Code::Blocks, compared to 57 Kb, the current size. The gain is minimal, mostly in syntax, so I decided it would be better if the __string remained a "const char*". If you want to change it again, you can do so, just I didn't see anything good in doing that.

The WindowHeight function remained in place (mostly for syntax purposes) even though it could have been eliminated. It looks like this:


int WindowHeight() { return gls->Height(); }


where "gls" is declared as the following:


IB4GLOpenGLWindow *gls = NULL;


and initialized in "Plugin::Load" as:


   gls = (IB4GLOpenGLWindow *) registry.FetchInterface("IB4GLOpenGLWindow", 1, 0);
   if (gls == NULL) {
       pluginError = "Could not get IB4GLOpenGLWindow interface to OpenGL screen. Is this the right Basic4GL version?";
       return false;
   }


This meant I had to change the Plugin::GetError to:


void DLLFUNC Plugin::GetError(char *error) {
if (pluginError != NULL)
for (int i = 0; pluginError[i] != 0; i++)
error[i] = pluginError[i];
}


Another thing I changed, to avoid confusion, is the name of the font loading function. It is now "LoadGLFont" to avoid confusion with the "Font" function that is built into b4gel. This correctly implies that at any given time, there can be 2 different fonts loaded. One for the text engine, one directly for glPrint use.

In fact, I dare say, Tom, it would be extremely useful if the font system that is built into b4gel, could handle the things that this plugin does (placement anywhere on screen, rotation of text, spacing between chars).


PS: plugin doesn't look complete though. There is still a significant performance drop on my laptop on the example source ".gb". Plus, I want to see If I can curl text around certain shapes, or see if I can rotate individual characters.

[Nicky Peter Hollyoake]

Thanks for the updated source code.

I got a question though, as you said you'll prefer to keep it as "const char" the only problem there though is the fact its not proper C++. I don't know what exectly using C over C++ can cause though - So I got nothing further in this subject.

So I guess now its just knowing how much further you wanna take this now? Will thier be anything else you adding? I only know so much C++, but I can try and help in any way possible.

I got a few suggestions though:

* backwards writing
* Roman numeral (Maybe something like "RomanNumeral(2432)")

- Nicky

[Empyrion Martyr]

The c over c++ discussion is a heated debate with no real finality.

yosefk.com/c++fqa/picture.html#fqa-6.11
yosefk.com/c++fqa/picture.html#fqa-6.15
and especially
yosefk.com/c++fqa/exceptions.html#fqa-17.5
www.gamedev.net/community/forums/topic.asp?topic_id=154661
yosefk.com/c++fqa/defective.html#defect-11

The above imply that string is better than char* for reasons of error and memory management. I don't think any of the arguments used there apply to the structure of a plugin DLL.

The above explain a few things, but not merely enough. My opinion is based on the assumption that C++ was created to ease the writing of more complicated code. In doing this, programs might end up bloated sometimes, so I think whenever we CAN use c code without impacting anything, we should. In my opinion, this is one case, also because Tom's plugin framework mostly uses "const char*" and generally using "string" ourselves would mean we should constantly "string.c_str()" to do things properly (like the error code i presented in the prior post).

As far as i can tell, using a const char * <<there>> instead of string does not negatively impact the code/performace, on the contrary.
However, in any other case, including all application that I write from the ground up, I allways use the string container.

As for plans for the future, they really depend on the time I have to invest. But your suggestionns (backward writing and roman numerals) are very good. You can try to implement them yourself independent of me, maybe you can come up with better solutions.

Another thing that eats my time is the Pathfinding plugin, which I finally finished, and only requires code cleanup. Now, RTS, RPG and FPS specific pathfinding will be made easier.

[Empyrion Martyr]

HMM.. on second thought a Roman Numeral Function doesn't really have anything to do with printing to the screen, but more to do with string manipulation. This would be useful next to conversion from a base to the other (decimal to hex for example) or some other string funcs.

I think backwards writing, curved path text and individual character rotation are the next things that could fit inside a glPrint plugin. Nobody stops us however, from adding the Roman Numeral thingie, but I think it's not that closely related to the object of this dll.

[Nicky Peter Hollyoake]

I was thinking we could have anything to do with text. We can be the master of text! ;p

- Nicky

glPrintRN(1132) - (RN: Roman Numeral)
glPrintBackwards

I was also thinking where we have "glPrintCol, glPrintExCol, glPrintEx2Col" I could *maybe* got a solution of putting them in "glPrint, glPrintEx, and glPrintEx2". So it will be

glPrint (x, y, text)
glPrint (Col, x, y, text)
glPrintEx (x, y, text)
glPrintEx (Col, x, y, text)

(or however the parameters go)

I could do this? Just be 3 less commands then.

- Nicky

EDIT:

And it works!! I will upload in the morning, goodnight.

[Empyrion Martyr]

Yeah the suggestions are well-thought (since function overloading didn't work in an include library I couldn't do the same in b4gel, but now that limitation is gone).

However I have a better suggestion as to why a Roman numeral function should be separate from a glprint, also why a backwards writing function should be separate. Think of it we have 3 different glprints, handling diff parameters. This means, to achieve the same functionality we need glPrintRN, glPrintRNEx, glPrintRNEx2 and glPrintBackw, glPrintBackwEx, glPrintBackwEx2 which means we add 6 more functions. Wouldn't it be easier if it were:

RN$(123...) and Backwards$("asf123...")

so that we may be able to:

glPrint(RN$(123...) and glPrintEx(Backwards$("agdsg") etc...

This would make more sense i think.
Anyway, I'm waitin' on you to upload.
Cheerz...

[Nicky Peter Hollyoake]

Mhm I'm having abit of trouble uploading, until I fix it you might want to do it, if you want to do it just delete the "Col" where you name the function.

- Nicky

[Empyrion Martyr]

I don't think it's worth the upload until I do some more work on it so (add a few more features), we'll see what happens

[Nicky Peter Hollyoake]

In a seperate plugin I'll make all sort of text effects.

Should be easy. I can be lazy sometimes and my mind sometimes goes wondering off to something else so be patients

- Nicky