A couple of OBDS changes...

[Nekrophidius]

The only thing I had to change was the lookup table, the assembly library didn't have to change at all. It's still got a long way to go but it's progressing nicely regardless. I've coded several assembly libraries so far, each containing a different procedure. Right now, you can set screenmodes, set screen fonts, write text to the screen regardless of what mode you're in, and perform some basic math (the expression evaluator is still pretty primitive). I'm spending most of the development time right now working on the documentation and getting that cohesive...after all, it'd suck to not have good documentation when this thing's released.

-nekrophidius :evil:

[Fling-master]

Good to hear Glad things are progressing nicely.

[Plasma]

1. The same people who remembered 13 screenmodes, and those smart enough to look at the user manual
2. Doing that would break SCREEN's function, which I will not do

1. 13 << 91
2. You can always support old-style screen mode numbers up to 13...

[Nekrophidius]

It makes no sense to break the current formula, first of all. SCREEN takes an integer value as its first argument, and OBDS doesn't support the Variant type (and never will), so you cannot pass strings to it. Second of all, like I said, OBDS is modelled after QB, so having to remake the SCREEN function to support a different method is just going to detract from the original style, which I'm trying to maintain. Thirdly, like I said, there's an automation dialog for SRCEEN, so you can select the screenmode from a list. OBDS's IDE is being carefully designed to enhance how you code in BASIC, and by keeping things familiar, less confusion takes place and you can code more effectively since very little transition is needed. And making a new system for setting the screen mode will do nothing but confuse people anyways...if I went that route, I might as well just put in functions for setting up a window and everything...something which is currently handled by the assembler and the coder doesn't even have to worry about. It is far easier for the programmer to just use the SCREEN Automation dialog than it is to have a whole new function to set screen parameters.

-nekrophidius :evil:

[Plasma]

How do you plan on implementing statements with optional parameters like LINE, CIRCLE, and OPEN then? (Some of which are characters like BF and APPEND...)

You can obviously do whatever you want, but people shouldn't have to use the IDE as a crutch imo.

[Nekrophidius]

You missed the point completely. What I am saying is that there is little sense in breaking a function that is already universally accepted, I am not saying anything about optional parameters. Where you got that from, I have no clue. And it's not like you knew all the standard screenmodes from your very first day in QB, you had to look them up on multiple occasions before you remembered them. Additionally, they are all listed in the help file, and there will also be built-in constants so you do not have to memorize each mode if you don't want to.

So instead of having to go:

SCREEN 15

you can do

SCREEN S320x200x16bpp

Very effective compromise, don't you think? It works like you're both asking, and it doesn't break the procedure as it already exists.

-nekrophidius :evil:

[Plasma]

All I was saying was you could make the resolution and color depth optional parameters of the SCREEN statement. So you could do both

SCREEN 56
and
SCREEN 640, 480, 16

Then you said something about not supporting variant types, and by that I assumed you were talking about optional parameters, because that's all I was using.

Constants are fine, but I think you're missing a point too...don't you want this to be *easy* to use as well as compatible? If your compiler is successful, hopefully it will attract new programmers who have never used QBasic. Do you want to force these people to look up screenmodes just because we had to?

[Nekrophidius]

You're forgetting something important about how SCREEN works...the problem is that you CAN'T make it do something like

SCREEN 640, 480, 16

because that would break its function. Don't forget that in most of QB's supported modes, SCREEN can take additional parameters! Only in 13 do we never use additional parameters. And by Variant type, I mean a data type that is just that...a Variant, as in Visual BASIC. IMO, it is sloth coding to use, and there exists a difference between coding well and coding sloppily. Although it's true that OBDS will be easy to code in, especially for newbies, encouraging lazy techniques from the start is NOT the answer. Therefore, I'm not going to allow the Variant data type unless someone can come up with a VERY legitimate reason to support it.

-nekrophidius :evil:

[Sterling Christensen]

If you don't like the way SCREEN is going to work you don't have to use it - people are probably going to write and/or port gfx libraries for this anyway (that's possible/supported, right Nekrophidius?)

[Plasma]

You're right, I had forgotten about the active/visual page parameters.