Recent Posts

Pages: [1] 2 3 ... 10
Beginner's Help / Re: help with READ and DATA statements
« Last post by Petr on March 29, 2017, 01:49:00 pm »
Hello. Just a small addition. If you want to block DATA used more than once, you need to adjust the reading block data from the beginning to use the RESTORE command.
Beginner's Help / Re: keyboard key with ^ sign doesn't work in Windows version
« Last post by Petr on March 29, 2017, 01:47:01 pm »
First install English keyboard in Windows (keyboard english / united kingdom) and then press left Shift + left Alt. This switch to the English keyboard. This allows write notes starting at ' in IDE. Germany and US keyboards have others scancodes. With this keyboard is no more problem.
Beginner's Help / Re: unsharp text in fullscreen mode
« Last post by Petr on March 29, 2017, 01:40:11 pm »
Try several simultaneously press ALT + Enter.
Beginner's Help / Re: unsharp text in fullscreen mode
« Last post by SMcNeill on March 29, 2017, 12:05:02 pm »
Can I ask which version of Windows?

This sounds like an issue which Galleon had to correct in the past with certain older Windows versions and GL not wanting to work correctly with NPOT Textures (Non Power of Two).  From what I recall, VISTA and WINDOWS 95 had issues with GL not working at all with the 16-bit OSes.   32-bit OS's seemed to work fine.

The glitch was in hardware rendering, so the patch was to use software rendering of graphics for those OSes affected, which allowed QB64 to run but displayed the fonts blurrier.

IF the issue is your NPOT graphic card and OS, there's only a few things to try to fix the problem:
1) Upgrade to a higher OS (or the 32 bit version of your current OS)
2) Try to set your monitor to a POT resolution
3) Check for latest graphic drivers

R400-based cards (Radeon 9500+ and X500+) are incapable of generic NPOT usage, despite allegedly supporting OpenGL 2.0 (which requires full support). These cards only allow you to use NPOTs if the texture has no mipmaps.

NV30-based cards (GeForce FX of any kind) are incapable of NPOTs at all, despite allegedly OpenGL 2.0 (which again requires NPOTs). It will do software rendering if you try to use it.

Any hardware beyond that can handle NPOTs of any kind perfectly.

If that's not the issue, I don't know what is.  ;)
Beginner's Help / Re: unsharp text in fullscreen mode
« Last post by waltersmind on March 29, 2017, 11:25:41 am »

Could you provide screenshots of how the text looks in Windows versus Linux in full screen, so we can see how you are viewing them?

The standard fonts used in QB64 are BITMAP fonts and do not contain smooth edges (anti-aliasing), unlike the vector fonts used in the operating systems (i.e. *.TTF). So, if you were to do a full screen in SCREEN 0, the text will look pixelated. However, if you load a font with _LOADFONT, that font will be drawn with anti-aliasing and will look smoother. But please note, when the fonts are loaded into QB64, they are converted to a BITMAP image as well, and if you use a small screen size like "SCREEN _NEWIMAGE (400, 300, 32)" and do a full screen, you will be able to see the anti-aliasing effect around the characters.

Walter Whitman
The Joyful Programmer
Beginner's Help / unsharp text in fullscreen mode
« Last post by BSpinoza on March 29, 2017, 11:03:51 am »
I have a problem only with  Windows (Linux no problem): when I use the fullscreen mode or  a greater window of the QB64 IDE all the text looks unsharp.
What can help?
QB64 Discussion / Re: just why can't I do this?(array in type)
« Last post by waltersmind on March 29, 2017, 11:02:02 am »

After a little more testing, it appears that QB64 does allow non-type variables to contain the dot character. However, I personally believe that this shouldn't be allowed due to the conflict of interest with user type variables.

Here is what I have learned when looking at the C++ code that QB64 creates:

If you do "DIM T.a(40) AS INTEGER" before "DIM T AS test", QB64 converts "T.a(40) AS INTEGER" into "__ARRAY_INTEGER_T__ASCII_CHR_046__A", and "T AS test" into "__UDT_T". Since these two converted variable names are different, they should be accessible without conflict. However, when you define both variable names as you did ("T.a() AS INTEGER" and "T AS test"), QB64 automatically assumes you are attempting to access the property "a" of the user define type "T" when it sees "T.a()", not the "T.a" variable.

I meant no disrespect on the "DIM T(40) AS test" part. What I was trying to say was, you can not do "DIM T.a(40) AS test" since this is attempting to turn the test TYPE property into an array, which you can not do.

Ok, I understand now what you are trying to do, but as I mentioned above, it is not possible QB64 (as you already well know). If array's in TYPE's were allowed, they would need to be a static size and could not be changed. User TYPE's are supposed to have a fixed length (size) and resizable arrays defined in the TYPE wouldn't allow that.

C++ has a data structure (a TYPE) as well. It does allow for static size arrays in the in the structure.

I hope this helps a little bit more.

Walter Whitman
The Joyful Programmer
Beginner's Help / keyboard key with ^ sign doesn't work in Windows version
« Last post by BSpinoza on March 29, 2017, 10:57:28 am »
The keyboard key with the ^ sign doesn't work in Windows version. I'm using QB64 version 1.1 Revision 20170120/51 with german keybord (dead grave acute QWERTZ). At the moment my only solution is to  use only the ASCII chart or CHR$(94).
In the Linux version the key with ^ works fine.
Has somebody heard about this problem?
QB64 Discussion / Re: just why can't I do this?
« Last post by Kobolt on March 29, 2017, 09:23:21 am »
So why can I even Dim both in the second example?
the first example fails to allow me to DIM T.a  after  T as test  but, the second lets me Dim T as test after T.a. Should it not fail on both variants due to T already being defined; Error: "Name already in use"? I guess I'm wondering why it just wont treat it as its own entity.
now if I didn't use TYPE i could DIM t.n as byte  and then DIM t.a(40) as _byte. Which makes me wonder whats different about the TYPE setup that doesn't allow it.

I was really trying to get array added to user types back in 2013 and there was talk, I won't say a promise, of getting it in there some time in the future at the time. But that's old history now and less and less likely with developments late last year.

as for just DIMing T(40) as test. Yes I know that, you know I've been around long enough for that much.  ;)
and in this testing it would not an issue but, say if the type consist of thousands or hundreds of thousands variables(attributes if you like), absurd I know but not impossible , and say 2 or 3% needed 10000 count arrays DIMing the whole type as an array with 10000 elements would waste a monstrous amount of memory.  :o

Ways around it? Yeah sure there is, but being a lazy minimalist programmer I'd rather just have the simplicity and ease of using arrays straight in the TYPE definition.

I know array in type is probably just whipping a dead dog at this point but I want to keep the desire for it alive and known so just maybe, just possibly if somebody has the ability to add it to QB64 it could get in there. Not just for me(though in my greedy little mind yeah just me) but for several others around here that have been wanting it for years.
QB64 Discussion / Re: just why can't I do this?
« Last post by waltersmind on March 29, 2017, 06:45:00 am »

The reason why it is giving you an error on line 6 is that T.a() is the same variable as T. That is the easy answer.

Periods are not valid in QB64 variable names as they are used in what is called, "Dot Notation". Basically, T.a() is read as "T:Variable.a:Property" or "T" is the variable name and "a" is the property of T. However, since T is defined as a "test" type (a developer defined variable type instead of on of the built in defined types like INTEGER), and only contains the "n" property, the T.a(40) = 100 would fail since the "a" property does not exist. It will also fail because QB64 does not allow arrays inside of TYPE definitions and in your sample, you are attempting to convert the "a" property into an array.

You can, however, create an array out of "T" with the type of "test" be simply do this:

Code: [Select]
TYPE test

DIM T(40) AS test

Then to access the 40th element of the new array of type test, you could do this:

Code: [Select]
T(40).n = 100

So, as I had mentioned, the "." (DOT) in a variable name is used as "Dot Notation" which simply allows us to organize and group our data into a single variable name by providing an unlimited amount of properties to such variable.

Walter Whitman
The Joyful Programmer
Pages: [1] 2 3 ... 10