Steve64 Repo

[SMcNeill]

Marked a post “best answer”, to highlight the differences in my person repo, and the standard QB64 version.

[SMcNeill]

Just pushed a start of changes to enhance console functionality for Windows users.

CSRLIN support added.
POS(0) support added.
LOCATE support added.
tab() glitch fixed.


Altered _PUTIMAGE so _DEST and _SOURCE handles can now be the same without any error messages.


As time allows, I plan to continue to expand console functionality, so unless you just have unlimited bandwidth and like to stay 100% current on changes, you might want to wait a few days to get another copy of the repo.  More changes are coming soon(tm).

[SMcNeill]

Console support extended:

LOCATE now works, as it should, with optional parameters. 
COLOR has now been implemented into the console.

(Again, for Windows-only.  I don't know if Linux/Mac even have the same console as on windows, but I know for certain these commands won't work for them, as they rely on Windows API calls and such.)

[SMcNeill]

Personal Rant:  The &#!@%!! SCREEN command is a BLEEEEPING BLEEP BLEEP!!!  It can bite my little BLEEPING BLLEEEP BLERP!!  I HOPE TO NEVER HAVE TO TAKE ANOTHER LOOK INSIDE THE BLEEPING BLEEPING BLORKING BLAAARF THAT IT IS, EVER AGAIN!!!

And, with that informative rant said, I now have SCREEN support enabled for the CONSOLE.

_SCREEN (x,y,0) returns the ASCII character value of point (x,y) on the console. 
_SCREEN (x,y,1) returns the COLOR character value of point(x,y) on the console.

NOTE: This requires that you set your source to the console, so SCREEN knows where to look for information.  For example:

$CONSOLE
_CONSOLE ON
_ECHO "Hello World"
PRINT "Screen can bite my hiney!"
PRINT SCREEN(1,1,0)

With the above, what is the screen command going to print for us?  The information for the screen, or the information for the console??

With no _SOURCE set, it's going to print the ASCII value for "S" -- the character on the screen.

If you want to get the value for the console, simply set the source to console first, as so:

$CONSOLE
_CONSOLE ON
_ECHO "Hello World"
PRINT "Screen can bite my hiney!"
_SOURCE _CONSOLE
PRINT SCREEN(1,1,0)

Note 2:  Most of these commands require _DEST or _SOURCE to be set to _CONSOLE before calling them, so you can differentiate between the console and screen with them.


Upcoming next is the _NAME_TO_BE_DETERMINED command to allow us to get single keystrokes from the console, without having to depend on ENTER being an input terminator.  This one isn't one that fits nicely into any of the existing commands, as it behaves much differently than INKEY$ or _KEYHIT.  For one thing, it's STILL a function which pauses program execution when it's called -- it doesn't return a "" or 0 as a NULL return.  As a second point, it returns a different set of scan codes than INKEY or _KEYHIT uses...

For the codepage which the  _NAME_TO_BE_DETERMINED command uses, take a look at the page here: https://www.qb64.org/wiki/Keyboard_scancodes and scroll down to the INP Scan Codes heading and view them. 

As for the name of this command, I'm thinking _CONSOLESCANCODE seems rather longish to me, and _CONSOLEINP seems a little goofy, as if somebody forgot to add an UT to the end of the INP..  I'd like a command name that is both descriptive and not so long to type over and over...

_CINP may be the name I go with, as this is very similar to a _CONSOLE version of the INP command, but I'm open to any suggestions.  As long as I'm still developing and pushing things into my personal repo, nothing is set in stone, so a name change can happen at any time, if anybody has a nice suggestion for me.  Just give me a good idea for what to call the command, before I end up pushing all these changes into QB64's development repo.  ;)

[SMcNeill]

Took a quick moment to add support to _WIDTH and _HEIGHT so we can now know the size of our console. 

Oddly enough, a default console has a height of 300, with only 25 lines actually visible at a line.  The other 275 lines are stored in a buffer so we can scroll back and take a look at them...

Who knew?!!

I'm not one to do too much work with the console, but looking into it, it's not really that hard to change the parameters on both that buffer amount, and the visible amount both...

The issue is...

We can't get that many parameters into our existing WIDTH command!

Currently I've got it set up so we can use WIDTH to set a width/height, but it makes the buffer size the exact same size as the view size.  Take the command WIDTH 120,50 for example -- it'll give us a console 120 characters wide (instead of the standard 80) and 50 lines high (instead of the normal 25), but it'll also currently make our console buffer that same 120x50 in size.  No scrolling up to see what ran off the screen, if you use my current implementation of WIDTH for the console!

And I'm not certain if I like that too much, but there's not much I can do if I stick with the current WIDTH command for things.  The options as I see them are:

1) Use WIDTH, as it currently exists, and make the buffer the same size as the view screen. (My current implementation.)

2) Change WIDTH so that it has two new parameters for the buffer width/height.

3) Create a brand new command with 4 parameters (width, height, buffer_width, buffer_height) so we can pass all the relevant information back and forth to the console. 

EDIT: Option 4) Leave the new window with a 300 line buffer that we can use to scroll up and down, the same as always, with no means to disable it, or increase/decrease it.

So my first question is:  How would you guys like to see me deal with the console width and height, and the separate console buffer width/height?

Second question:  Do I need a _CONSOLEBUFFERWIDTH and _CONSOLEBUFFERHEIGHT command as well, or are we good without one?

[FellippeHeitor]

If 300 lines of buffer is default, I say keep it.

I vote for maintaining it all under WIDTH too.

[SMcNeill]

If 300 lines of buffer is default, I say keep it.

I vote for maintaining it all under WIDTH too.

I think I've settled on the way I'm going to work things; I've just added 2 new optional parameters to the existing WIDTH command so we can pass the buffer width and height via it.  It won't affect any existing code one bit, but it expands the functionality so we can customize the size of our console however much we want it.

Changes have been pushed into my repo which support _WIDTH and _HEIGHT with _SOURCE _CONSOLE set (which I kept forgetting to do when testing things, making myself think over and over that I'd broken code which was working just fine -- except for the idiot behind the keyboard!)

WIDTH now has two more optional parameters which we can use to set the buffer width and buffer height of the console and it works with _DEST _CONSOLE (which is part of the problem with my own testing, as I will sometimes set one and forget the other...).

Anyone have any decent suggestions for the name of the input routine?  I was kinda playing around with WIDTH/HEIGHT while seeing if anybody had any suggestions, but noone has spoken up yet with one...  If nobody has any better names, there'll be a new keyword coming to the language called _CINP, which we can use to get single character input from the console. 


The more I work with upgrading the console functionality, the more I wonder why anybody ever bothered to use it in the past.  Everything seems glitchy or non-implemented, and I don't know how anybody ever managed to code in $CONSOLE:ONLY mode.  Heck, even SLEEP doesn't work properly!  (And I'll work on fixing it for us, after I get _CINP implemented sometime soon(tm).)

[bplus]

_CKEY ? because similar to INKEY$

[SMcNeill]

Added lots of new functionality to my repo for Windows users. (Sorry Linux/Mac folks, these rely on windows API calls, and I don't do enough {read any} programming in Linux or Mac, to know the equivalent versions to implement this functionality for your systems.   Maybe Luke and Fellippe will add the Linux/Mac versions for you folks later.)

For starters, we now have _CINP(optional toggle) to get single key presses from the console for us.  I've explained the routine several times in the past, and folks can test its behavior with the DECLARE LIBRARY version of this command here: https://www.qb64.org/forum/index.php?topic=1540.msg107963#msg107963

The toggle is optional and changes from what I think is a simplified code value set (negative values for up events, positive values for down events), to the standard version (+128 to keypress code for up event, standard keypress code for down event). 


Added several new commands which I feel could be quite useful with this command:

_CAPSLOCK, _NUMLOCK, _SCROLLOCK -- to get the value of these keyboard states for us.  Returns 0 if they're off, 1 if they're on.

_TOGGLE_CAPSLOCK, _TOGGLE_NUMLOCK, _TOGGLE_SCROLLOCK -- to change the keyboard state for these keys, if we choose to.  NOTE: This is a global keyboard change, and *WILL* affect typing in other programs as well.  If CAPSLOCK goes on or off on your keyboard, it changes the input for everything we type with our keyboard; not just what we type into one program.

_CKEY ? because similar to INKEY$

I just stuck with _CINP as it's (almost) a console version of INP.  It's good enough for me, and can always be changed later, if folks have a better name for it, before I push any of these changes into the official repo.


And what's left to do at this point??

I still know that SLEEP needs to be altered to work with the console, and now that we have func__CInp built in for windows, that shouldn't be any issue to fix.  Also END needs the same overhaul so we get back to "Press <ANY KEY> to close", rather than "Press <ENTER> to close".

Otherwise, I think I'm nearing the end of this series of changes (after all, I'm not a console user normally anyway), so unless you guys know some console functionality that doesn't work, or some functionality which needs to be added, I'll probably be wrapping up this series of changes/enhancements later today or tomorrow for us.  :)

[SMcNeill]

Added support for SLEEP, CLS, END to all work properly with the console.

And, I think I'm done with adding console support to QB64.  I don't use it enough to know what I'm missing, so if you guys see functionality missing that you think the console needs, post and let me know.  I'll see what I can do to add it to the language for us.

[Petr]

Hi. I have one question about the console, I don't know if that is the intention or why it is, it is about the sound phrase when using sound commands with _CONSOLE. Why is it there?

 

[SMcNeill]

Hi. I have one question about the console, I don't know if that is the intention or why it is, it is about the sound phrase when using sound commands with _CONSOLE. Why is it there?

No idea.  I don't get it when I run the test code that you are.  For some reason, it appears the sound library is tossing an error message of some sort out for you, but I have no idea why or what it is.  I haven't tried to dig into anything at all sound related yet.

[SMcNeill]

Pushed a fix to the repo, where I'm basically an idiot...

When testing the new features, I inserted some breakpoints into the code, to rule out problem areas from consideration...  Like a dummy, I left one of those in there, completely breaking comma delimited text while in graphics modes.  That issue should be corrected now.  (It was all of removing on "return;" from the code...)  /sigh

It's always something!

[SMcNeill]

Forgot a big part of the console changes which I wanted to bring -- the ability to change the font itself inside the console!

Added a new command to allow us to do this:  _CONSOLEFONT (fontname$, size)

Usage is rather simple, as: 

Code: QB64: [Select]

1. $CONSOLE:ONLY
2. _DEST _CONSOLE: _SOURCE _CONSOLE
3. _CONSOLEFONT "Courier New", 16 'change default size to 16, with Courier New font
4. PRINT "Hello World"
5. SLEEP
6. _CONSOLEFONT "", 24 'change default size to 24, without changing the font itself.
7. PRINT "Hello World"
8. SLEEP
9. _CONSOLEFONT "Consolas", 24 'change default size to 16, with weirdo Consolas font.
10. PRINT "Hello World"
11. SLEEP

Note, this doesn't return any sort of error code for us in case it fails, and I have no idea how the BLEEP you can actually determine what the actual fonts are which work with the console.  The way I got these names was to open up a console window of my own, right click on the title bar, select PROPERTIES, and then FONT, which at that point I just chose two which were easy enough to spell, and different enough to tell apart with my console.  These fonts may, or may not, be on your PC -- I dunno!!  As I've said before, I'm not a regular user of the console for many things, so I'm sort of stumbling around in the dark trying to piece all these parts together to get them to work for us...

Apparently though, there doesn't appear to be much need for an error message, as the console basically just seems to ignore an unrecognized parameter (such as the blank font name I tested above).  All I can say at this point is test it out, beat it around, and if it does crash or do something completely insane, let me know and I'll try and dig further into the documentation and see if I can sort out what went wrong and how to correct it in the future.

[SMcNeill]

I told you guys that you might want to hold off for a few days while I was working on adding all the little changes to the repo, but I think I'm finally finished with pushing things into the repo for a bit.  I think I'm going to take a break for several days and give folks time to test everything out and see if anything appears broken, or not to work for them, and use the opportunity to catch up with my deadline for my newest novel. 

Post any thoughts, questions, feedback, and concerns below, and I'll see what I can do about addressing it ASAP, but don't expect to see anything  new added to the repo for a bit.  I'm (semi) on coding vacation now, for the next few weeks, as I catch up with other stuff in life!  ;D