Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #1044 > unrolled thread

misc: multi-line editing/evaluation...

Back to article view | Back to comp.lang.misc

Contents

  misc: multi-line editing/evaluation... BGB <cr88192@hotmail.com> - 2012-03-12 14:38 -0700
    Re: misc: multi-line editing/evaluation... Mike Austin <mike.austin.1024@gmail.com> - 2012-03-12 16:24 -0700
      Re: misc: multi-line editing/evaluation... BGB <cr88192@hotmail.com> - 2012-03-12 17:30 -0700
    Re: misc: multi-line editing/evaluation... Rui Maciel <rui.maciel@gmail.com> - 2012-03-12 23:42 +0000
    Re: misc: multi-line editing/evaluation... "BartC" <bc@freeuk.com> - 2012-03-12 23:51 +0000
      Re: misc: multi-line editing/evaluation... BGB <cr88192@hotmail.com> - 2012-03-12 18:29 -0700
        Re: misc: multi-line editing/evaluation... Mike Austin <mike.austin.1024@gmail.com> - 2012-03-12 22:04 -0700
        Re: misc: multi-line editing/evaluation... "BartC" <bc@freeuk.com> - 2012-03-13 12:31 +0000
          Re: misc: multi-line editing/evaluation... BGB <cr88192@hotmail.com> - 2012-03-13 10:03 -0700
    Re: multi-line editing/evaluation... "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-13 02:43 -0400
      Re: multi-line editing/evaluation... BGB <cr88192@hotmail.com> - 2012-03-13 11:12 -0700
    Re: misc: multi-line editing/evaluation... Jacko <jackokring@gmail.com> - 2012-03-13 20:10 -0700
    Re: misc: multi-line editing/evaluation... Paul N <gw7rib@aol.com> - 2012-03-14 15:08 -0700
      Re: misc: multi-line editing/evaluation... BGB <cr88192@hotmail.com> - 2012-03-14 19:11 -0700
        Re: misc: multi-line editing/evaluation... "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-15 04:10 -0400
          Re: misc: multi-line editing/evaluation... BGB <cr88192@hotmail.com> - 2012-03-15 13:09 -0700
    Re: multi-line editing/evaluation... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-03-16 08:54 +0000
      Re: multi-line editing/evaluation... BGB <cr88192@hotmail.com> - 2012-03-16 09:45 -0700

#1044 — misc: multi-line editing/evaluation...

here is the scenario:
I have a 3D engine;
it has a console;
I can evaluated code fragments at said console.


basically, sort of like the Quake-family engines, except that the 
console is a full-screen translucent overlay, and presently accessed via 
"ALT-~" (both CTRL-~ and ~ by itself had drawbacks).


I was generally limited (WRT evaluating script expressions) to whatever 
I could reasonably type at a command-prompt.

so, then I was left thinking, "what if I had a text editor"?

the idea would be to have something sort of like QBasic or the "SQL 
Server Management Studio", where one can type/edit scripts, in program, 
and then evaluate them. or, likewise, highlight chunks of text, hit an 
"evaluate" key, and have it do something.


a partial reason would be to reduce the current annoyance of the prior 
process:
ALT-TAB (get into Notepad2 or similar);
edit script;
ALT-TAB (get back into 3D engine);
UP-Arrow, Enter (say, to execute a prior ";load(...);" command).
(possibly mixed with ALT-~ to enter/exit console).


problem:
I was having a hard-time thinking up a good way to interface a text 
editor with the 3D Engine's UI.

I was left considering more complex options, roughly things like 
allowing multiple consoles (and/or "tabs"), and basically allowing 
implementing something roughly along the lines of QBasic or MS-Edit 
inside the console (switch to a secondary console, pull up "edit", go 
into something sort of like QBasic, type code, have it do stuff, 
presumably in the 3D scene, ...).

current thinking:
ALT-~ enters/exits console (as before);
SHIFT + F1-F9 select the active console/tab (when console is active, 
these execute commands if console is not active).


I was tempted, but as-is, this would be kind of a pain to implement 
(would have to both code up the editor, and make some changes to how the 
console is handled, ...). note that the console buffer is basically a 
grid of characters and color/effect values, and so is "essentially 
similar" to text-mode (most obvious difference being that the buffer is 
the Unicode-BMP, vs "IBM Extended ASCII" / "CodePage 437").

some of the needed changes were already made though (adding 
"ConsoleInfo" structures and similar).


as a much faster/cheaper/initial option, I ended up doing something 
different:
I added console commands that basically work vaguely similar to 
something like "edlin", where one basically edits by typing in 
line-numbers and lines of text, or can invoke commands for things like 
adding/deleting lines, printing lines to the console, ...

so, for example (preexisting syntax):
;printf("Hello\n");	//evaluate expression directly

the ';' prefix mostly tells the console that it is a script expression, 
rather than, say, a console generic command (or getting/setting a cvar).

and, new syntax:
*1 printf("Hello\n");
*2 printf("Hello again\n");
*eval

which executes both lines, oddly not nearly as horrid/awkward as one 
might think (though using * for this is slightly annoying, there are not 
many other better options available).


I could (or may) still consider investing effort in throwing together 
something vaguely more QBasic-like (being much more better suited for 
things like editing script files, and limited to consoles 2-9 for 
technical reasons, ...).


any thoughts?

[toc] | [next] | [standalone]

#1045

On Monday, March 12, 2012 2:38:51 PM UTC-7, BGB wrote:
> here is the scenario:
> I have a 3D engine;
> it has a console;
> I can evaluated code fragments at said console.
> 
> 
> basically, sort of like the Quake-family engines, except that the 
> console is a full-screen translucent overlay, and presently accessed via 
> "ALT-~" (both CTRL-~ and ~ by itself had drawbacks).
> 
> 
> I was generally limited (WRT evaluating script expressions) to whatever 
> I could reasonably type at a command-prompt.
> 
> so, then I was left thinking, "what if I had a text editor"?
> 
> the idea would be to have something sort of like QBasic or the "SQL 
> Server Management Studio", where one can type/edit scripts, in program, 
> and then evaluate them. or, likewise, highlight chunks of text, hit an 
> "evaluate" key, and have it do something.
> 
> 
> a partial reason would be to reduce the current annoyance of the prior 
> process:
> ALT-TAB (get into Notepad2 or similar);
> edit script;
> ALT-TAB (get back into 3D engine);
> UP-Arrow, Enter (say, to execute a prior ";load(...);" command).
> (possibly mixed with ALT-~ to enter/exit console).
> 
> 
> problem:
> I was having a hard-time thinking up a good way to interface a text 
> editor with the 3D Engine's UI.
> 
> I was left considering more complex options, roughly things like 
> allowing multiple consoles (and/or "tabs"), and basically allowing 
> implementing something roughly along the lines of QBasic or MS-Edit 
> inside the console (switch to a secondary console, pull up "edit", go 
> into something sort of like QBasic, type code, have it do stuff, 
> presumably in the 3D scene, ...).
> 
> current thinking:
> ALT-~ enters/exits console (as before);
> SHIFT + F1-F9 select the active console/tab (when console is active, 
> these execute commands if console is not active).
> 
> 
> I was tempted, but as-is, this would be kind of a pain to implement 
> (would have to both code up the editor, and make some changes to how the 
> console is handled, ...). note that the console buffer is basically a 
> grid of characters and color/effect values, and so is "essentially 
> similar" to text-mode (most obvious difference being that the buffer is 
> the Unicode-BMP, vs "IBM Extended ASCII" / "CodePage 437").
> 
> some of the needed changes were already made though (adding 
> "ConsoleInfo" structures and similar).
> 
> 
> as a much faster/cheaper/initial option, I ended up doing something 
> different:
> I added console commands that basically work vaguely similar to 
> something like "edlin", where one basically edits by typing in 
> line-numbers and lines of text, or can invoke commands for things like 
> adding/deleting lines, printing lines to the console, ...
> 
> so, for example (preexisting syntax):
> ;printf("Hello\n");	//evaluate expression directly
> 
> the ';' prefix mostly tells the console that it is a script expression, 
> rather than, say, a console generic command (or getting/setting a cvar).
> 
> and, new syntax:
> *1 printf("Hello\n");
> *2 printf("Hello again\n");
> *eval
> 
> which executes both lines, oddly not nearly as horrid/awkward as one 
> might think (though using * for this is slightly annoying, there are not 
> many other better options available).
> 
> 
> I could (or may) still consider investing effort in throwing together 
> something vaguely more QBasic-like (being much more better suited for 
> things like editing script files, and limited to consoles 2-9 for 
> technical reasons, ...).
> 
> 
> any thoughts?

In JavaScript debuggers in edit mode (vs 1 command at a time), Enter adds newlines, while alt-enter executes them.  You could try a hybrid where you select a chunk of text and call that the "editor".  Outside that area enter executes the line.  Or something along those lines, because I think both ways useful like you are doing.

Mike

[toc] | [prev] | [next] | [standalone]

#1048

On 3/12/2012 4:24 PM, Mike Austin wrote:
> On Monday, March 12, 2012 2:38:51 PM UTC-7, BGB wrote:
>> here is the scenario:
>> I have a 3D engine;
>> it has a console;
>> I can evaluated code fragments at said console.
>>
>>
>> basically, sort of like the Quake-family engines, except that the
>> console is a full-screen translucent overlay, and presently accessed via
>> "ALT-~" (both CTRL-~ and ~ by itself had drawbacks).
>>
>>
>> I was generally limited (WRT evaluating script expressions) to whatever
>> I could reasonably type at a command-prompt.
>>
>> so, then I was left thinking, "what if I had a text editor"?
>>
>> the idea would be to have something sort of like QBasic or the "SQL
>> Server Management Studio", where one can type/edit scripts, in program,
>> and then evaluate them. or, likewise, highlight chunks of text, hit an
>> "evaluate" key, and have it do something.
>>
>>
>> a partial reason would be to reduce the current annoyance of the prior
>> process:
>> ALT-TAB (get into Notepad2 or similar);
>> edit script;
>> ALT-TAB (get back into 3D engine);
>> UP-Arrow, Enter (say, to execute a prior ";load(...);" command).
>> (possibly mixed with ALT-~ to enter/exit console).
>>
>>
>> problem:
>> I was having a hard-time thinking up a good way to interface a text
>> editor with the 3D Engine's UI.
>>
>> I was left considering more complex options, roughly things like
>> allowing multiple consoles (and/or "tabs"), and basically allowing
>> implementing something roughly along the lines of QBasic or MS-Edit
>> inside the console (switch to a secondary console, pull up "edit", go
>> into something sort of like QBasic, type code, have it do stuff,
>> presumably in the 3D scene, ...).
>>
>> current thinking:
>> ALT-~ enters/exits console (as before);
>> SHIFT + F1-F9 select the active console/tab (when console is active,
>> these execute commands if console is not active).
>>
>>
>> I was tempted, but as-is, this would be kind of a pain to implement
>> (would have to both code up the editor, and make some changes to how the
>> console is handled, ...). note that the console buffer is basically a
>> grid of characters and color/effect values, and so is "essentially
>> similar" to text-mode (most obvious difference being that the buffer is
>> the Unicode-BMP, vs "IBM Extended ASCII" / "CodePage 437").
>>
>> some of the needed changes were already made though (adding
>> "ConsoleInfo" structures and similar).
>>
>>
>> as a much faster/cheaper/initial option, I ended up doing something
>> different:
>> I added console commands that basically work vaguely similar to
>> something like "edlin", where one basically edits by typing in
>> line-numbers and lines of text, or can invoke commands for things like
>> adding/deleting lines, printing lines to the console, ...
>>
>> so, for example (preexisting syntax):
>> ;printf("Hello\n");	//evaluate expression directly
>>
>> the ';' prefix mostly tells the console that it is a script expression,
>> rather than, say, a console generic command (or getting/setting a cvar).
>>
>> and, new syntax:
>> *1 printf("Hello\n");
>> *2 printf("Hello again\n");
>> *eval
>>
>> which executes both lines, oddly not nearly as horrid/awkward as one
>> might think (though using * for this is slightly annoying, there are not
>> many other better options available).
>>
>>
>> I could (or may) still consider investing effort in throwing together
>> something vaguely more QBasic-like (being much more better suited for
>> things like editing script files, and limited to consoles 2-9 for
>> technical reasons, ...).
>>
>>
>> any thoughts?
>
> In JavaScript debuggers in edit mode (vs 1 command at a time), Enter adds
 > newlines, while alt-enter executes them.  You could try a hybrid 
where you
 > select a chunk of text and call that the "editor".  Outside that area 
enter
 > executes the line.  Or something along those lines, because I think both
 > ways useful like you are doing.
>

as-is, I don't have any text-selection feature in the console (sadly).

actually, as-is, the console behaves sort of like a typical IRC client:
the prompt is at a fixed position at the bottom of the window;
enter always submits a command for execution;
it is not currently possible to enter more than 1 line of text, or more 
than the console width (100 characters).


but, yes, line at a time works fairly well, just it severely limits the 
complexity of commands one can type.

an edlin-like strategy was a compromise, and could maybe be streamlined 
some.

one idea:
* text...
puts the new line following the last line (also does an insert).

*2 D
*1 A
* B
* C
results in the lines:
  1: A
  2: B
  3: C
  4: D

was also considering a possible "evaluate and clear" option:
say, "**", both evaluates the expression and clears the editor/module 
contents (allowing using the editor more like a multi-line command-entry 
prompt).


otherwise, I was working on adding support for multiple consoles 
(basically works), and was considering potentially modifying things so 
that the cursor could be at an arbitrary location. this could get funky 
though unless I redesign how the prompt works (command-entry would still 
always be at the bottom of the screen, unless I wrote code to allow the 
prompt to be at an arbitrary location).

a lot of basic operations have also been migrated into methods though, 
potentially allowing that secondary consoles need not necessarily be 
text-based (the actual drawing code uses OpenGL, so vector graphics and 
images and similar are also possible).

also ended up switching to using ALT + 1-9, due mostly to the prior idea 
turning out to be physically uncomfortable.


a full text editor is likely to be a bit more of a "heavyweight" option 
though (in this case, it would likely have a more common editing 
interface, more like the MS-Edit/Notepad/... editing interface).

I am also considering using a scheme where editing has "modules", likely 
identified via letters. then, a key combination like ALT-SHIFT + A-Z 
could allow switching between modules. functionally, these could serve a 
similar role to tabs in tabbed editors, and may or may not map to 
currently open files (will probably have generic load/save/... options, 
and probably clipboard and undo/redo if I get around to it).

if I wanted to be extra fancy, I could probably support syntax 
highlighting or similar as well...


as-is, I haven't yet decided on supporting any pointy-clicky stuff:
pointy clicky is more of a pain to implement, and isn't really necessary 
in a text editor (if a person doesn't know how to edit text with just 
the keyboard, they don't really truly know how to type...).


or such...

[toc] | [prev] | [next] | [standalone]

#1046

BGB wrote:

> any thoughts?

Is it out of the question to open script files with an external text editor?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1047

"BGB" <cr88192@hotmail.com> wrote in message
news:jjlqg2$vbf$1@news.albasani.net...
> here is the scenario:
> I have a 3D engine;
> it has a console;
> I can evaluated code fragments at said console.
>
>
> basically, sort of like the Quake-family engines, except that the console
> is a full-screen translucent overlay, and presently accessed via "ALT-~"
> (both CTRL-~ and ~ by itself had drawbacks).
>
>
> I was generally limited (WRT evaluating script expressions) to whatever I
> could reasonably type at a command-prompt.
>
> so, then I was left thinking, "what if I had a text editor"?
>
> the idea would be to have something sort of like QBasic or the "SQL Server
> Management Studio", where one can type/edit scripts, in program, and then
> evaluate them. or, likewise, highlight chunks of text, hit an "evaluate"
> key, and have it do something.

You want a quick development cycle for trying out multi-line scripts on your
graphics app?

I wouldn't have thought that too difficult; you just need to set up macros
on function keys so that you can instantly switch from one mode to another.
Even with Notepad that might be possible.

For years, when I was working CAD applications, I mostly developed from
within the application itself. It had a command line, but any multiple-line
scripts were handled in an editor popup. With function keys set up, one
press would bring up the script (with the cursor positioned where it had
been before). You did the changes, then another press would save, compile,
and run, doing something to the app.

I did use my own editors (so they could communicate an exit code more
easily), but with ordinary editors, it might just mean an extra key press to
evaluate the result.

Going back even further, I had a compiler/editor where the source stayed
displayed on the screen. Any graphics I was working with was often on a
separate board with it's own display. The source wasn't saved because the
floppy disks were too slow for the turn-around I wanted.

Maybe your hardware can support a dual display, one showing the script,
however you still have a bit of a headache in switching the keyboard/mouse
from the editor window to the app window.

I don't know about using the 3D UI to do editing, if you're thinking about
maybe displaying the script via some texture bitmap in the scene (or perhaps 
one of the scene objects is itself a computer screen!). I think they should 
be kept distinct.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#1049

On 3/12/2012 4:51 PM, BartC wrote:
>
> "BGB" <cr88192@hotmail.com> wrote in message
> news:jjlqg2$vbf$1@news.albasani.net...
>> here is the scenario:
>> I have a 3D engine;
>> it has a console;
>> I can evaluated code fragments at said console.
>>
>>
>> basically, sort of like the Quake-family engines, except that the console
>> is a full-screen translucent overlay, and presently accessed via "ALT-~"
>> (both CTRL-~ and ~ by itself had drawbacks).
>>
>>
>> I was generally limited (WRT evaluating script expressions) to whatever I
>> could reasonably type at a command-prompt.
>>
>> so, then I was left thinking, "what if I had a text editor"?
>>
>> the idea would be to have something sort of like QBasic or the "SQL
>> Server
>> Management Studio", where one can type/edit scripts, in program, and then
>> evaluate them. or, likewise, highlight chunks of text, hit an "evaluate"
>> key, and have it do something.
>
> You want a quick development cycle for trying out multi-line scripts on
> your
> graphics app?
>

it is a 3D engine (basically, a 3D Game-engine, also FPS / "First Person 
Shooter" style), either way.


> I wouldn't have thought that too difficult; you just need to set up macros
> on function keys so that you can instantly switch from one mode to another.
> Even with Notepad that might be possible.
>

hmm, key-binding in Windows?...

I hadn't actually thought of looking into it.
ALT-TAB sort of works, since one can ALT-TAB between several open apps.

as-is though, it is sort of a pain to do this though, because the number 
of steps involved gets tedious.

generally, I am using Notepad2 as an external editor (for editing most 
source code, including scripts).


> For years, when I was working CAD applications, I mostly developed from
> within the application itself. It had a command line, but any multiple-line
> scripts were handled in an editor popup. With function keys set up, one
> press would bring up the script (with the cursor positioned where it had
> been before). You did the changes, then another press would save, compile,
> and run, doing something to the app.
>

yes, this would also be for an in-app editor, mostly accessed via the 
console interface. I am mostly deciding on UI specifics (things like how 
it should look and how the keyboard should be handled).


> I did use my own editors (so they could communicate an exit code more
> easily), but with ordinary editors, it might just mean an extra key
> press to
> evaluate the result.
>
> Going back even further, I had a compiler/editor where the source stayed
> displayed on the screen. Any graphics I was working with was often on a
> separate board with it's own display. The source wasn't saved because the
> floppy disks were too slow for the turn-around I wanted.
>
> Maybe your hardware can support a dual display, one showing the script,
> however you still have a bit of a headache in switching the keyboard/mouse
> from the editor window to the app window.
>

my PC could do dual display, but I don't currently have money to invest 
in another monitor, nor would this likely be particularly useful.


> I don't know about using the 3D UI to do editing, if you're thinking about
> maybe displaying the script via some texture bitmap in the scene (or
> perhaps one of the scene objects is itself a computer screen!). I think
> they should be kept distinct.


this is theoretically possible, but not actually what I was currently 
planning.

basically, the 3D engine does its thing, and when the console is active 
("down"), then UI is taken over by the console (things like camera 
controls, ... ignore user-input when the console or menus are active).

functionally, the console is like if one had the 3D game in the 
background, and then summoned up a DOS-Prompt style environment on top 
of it (partly translucent, so one can essentially see the 3D scene 
"behind" the DOS-Prompt), and then proceeded to type commands which may 
or may not effect the 3D world.

one can repeat the keyboard magic, and the console goes away, and one is 
back to interacting with the 3D world.


but, the issue is that it is sort of a hassle to switch back and forth 
between the 3D engine and an external text editor, so the idea is to 
allow putting a text editor in the console (so that one can edit the 
scripts for the game directly inside the game engine, and more quickly 
see the results of doing so).

this way, the console-key magic also allows switching between the 3D 
world and a text editor, and one can edit things, and hit a key to 
evaluate whatever is currently in the editor.

say: F5=Go, or similar.


say, for example, a person wants to make all the lights in the immediate 
vicinity of the player explode, they could go in the editor and quickly 
type something like:
<--
var cur, nxt;
cur=btFindRadius(btGetCurrentPlayer().origin, 512);
while(cur)
{
	nxt=cur.chain;
	if(cur.light)btBecomeExplosion(cur);
	cur=nxt;
}
-->

then hit F5, and watch as all the lights in their immediate vicinity 
explode and the area around them goes dark.

(yes, I was actually fiddling around with manually exploding the 
light-sources recently... kind of a LOLZ effect).


or such...

[toc] | [prev] | [next] | [standalone]

#1050

I've never used it first hand, but CLIM is something I've admired and an idea ahead of its time, even now:
http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html

Having something like multiple inline editors might be cool, but possibly overkill :)

Mike

[toc] | [prev] | [next] | [standalone]

#1052

"BGB" <cr88192@hotmail.com> wrote in message 
news:jjm7vs$47f$1@news.albasani.net...
> On 3/12/2012 4:51 PM, BartC wrote:

>> You want a quick development cycle for trying out multi-line scripts on
>> your
>> graphics app?
>>

> say, for example, a person wants to make all the lights in the immediate 
> vicinity of the player explode, they could go in the editor and quickly 
> type something like:
> <--
> var cur, nxt;
> cur=btFindRadius(btGetCurrentPlayer().origin, 512);
> while(cur)
> {
> nxt=cur.chain;
> if(cur.light)btBecomeExplosion(cur);
> cur=nxt;
> }
> -->
>
> then hit F5, and watch as all the lights in their immediate vicinity 
> explode and the area around them goes dark.

So you want these scripts to be created and evaluated by the user of the 3D 
application?

Well, for a start, you might want a niftier scripting language! That example 
looks like hard work for a user (and dealing with syntax errors from all the 
punctuation will likely dominate things more than the inconvenience of 
switching an external editor in and out).

(With my CAD apps, I had two levels of scripting: one level was what someone 
might key in on the command line, all interactive and user friendly, and 
those same commands could also be put into a script, with a very few 
additions for programmability.

The second level was a proper language, like your example, but this wasn't 
intended for end-users and wasn't designed for 'real-time' use.)

But for your proposed use of what might be very simple scripts (ignoring the 
syntax for a minute), I think you will need to integrate the display and 
editing of them into your application. Putting together a minimalist text 
editor isn't hard (I think I did something once with just 256 bytes of RAM 
to play with -- not including the screen memory). (And if you're under 
Windows, then a multi-line edit control is basically a mini text-editor.)

The script is really just a single string, and pressing some key causes the 
string to be evaluated/executed. It's just a question of displaying and 
editing that string. Maybe you can drive the display and editing from the 
command line, but those are line-editing techniques from the 70s that people 
were glad to see the back of once proper interactive editing came in.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#1053

On 3/13/2012 5:31 AM, BartC wrote:
> "BGB" <cr88192@hotmail.com> wrote in message
> news:jjm7vs$47f$1@news.albasani.net...
>> On 3/12/2012 4:51 PM, BartC wrote:
>
>>> You want a quick development cycle for trying out multi-line scripts on
>>> your
>>> graphics app?
>>>
>
>> say, for example, a person wants to make all the lights in the
>> immediate vicinity of the player explode, they could go in the editor
>> and quickly type something like:
>> <--
>> var cur, nxt;
>> cur=btFindRadius(btGetCurrentPlayer().origin, 512);
>> while(cur)
>> {
>> nxt=cur.chain;
>> if(cur.light)btBecomeExplosion(cur);
>> cur=nxt;
>> }
>> -->
>>
>> then hit F5, and watch as all the lights in their immediate vicinity
>> explode and the area around them goes dark.
>
> So you want these scripts to be created and evaluated by the user of the
> 3D application?
>

no, it is mostly for sake of game developers.

it is much like, one might use a scripting language to avoid endlessly 
recompiling the engine.

one might also want to be able to more rapidly script and test things, 
in engine, rather than going through another cycle:
exit game;
fiddle with scripts;
start game again;
get back to a place where one can test the new feature.

so, it is mostly about making things faster and less annoying.


> Well, for a start, you might want a niftier scripting language! That
> example looks like hard work for a user (and dealing with syntax errors
> from all the punctuation will likely dominate things more than the
> inconvenience of switching an external editor in and out).

probably the bulk of editing will still be in external text files.
also, the syntax generally works fairly well.

the language is basically ECMAScript based.


> (With my CAD apps, I had two levels of scripting: one level was what
> someone might key in on the command line, all interactive and user
> friendly, and those same commands could also be put into a script, with
> a very few additions for programmability.
>
> The second level was a proper language, like your example, but this
> wasn't intended for end-users and wasn't designed for 'real-time' use.)
>

I did recently deal with an issue (regarding real-time use):
previously, typing errors were liable to crash the parser.

more recently, I put in a lot more error-handling logic, and now the 
parser will generally return "UNDEFINED" in case of a syntax error, as 
well as printing an error message.

a minor uncertainty is how to best deal with the possibility that a 
script might just as easily crash the engine, since given dynamic 
editing is inline, crashing the engine will also crash the editor.


granted, this isn't too much like trying to write code on Win9x though, 
"you don't crash app, app crashes you" (or, at least, your OS).


> But for your proposed use of what might be very simple scripts (ignoring
> the syntax for a minute), I think you will need to integrate the display
> and editing of them into your application. Putting together a minimalist
> text editor isn't hard (I think I did something once with just 256 bytes
> of RAM to play with -- not including the screen memory). (And if you're
> under Windows, then a multi-line edit control is basically a mini
> text-editor.)
>
> The script is really just a single string, and pressing some key causes
> the string to be evaluated/executed. It's just a question of displaying
> and editing that string. Maybe you can drive the display and editing
> from the command line, but those are line-editing techniques from the
> 70s that people were glad to see the back of once proper interactive
> editing came in.
>

there is a system for key-binding.
currently it is done with console commands, mostly like:
alias A "do_something"

but, anyways, a lot is driven by the console, but the console isn't 
intended as an end-user interface, rather, as a developer interface (or, 
maybe, as a modding interface).


most end-users are likely to mostly just play the game, or maybe use the 
console for entering cheat codes or something (rather than be like, 
"wow, I can edit the game scripts" or "wow, I can go into mapper mode" 
or whatever else).

there is a lot of other funkiness that can be done to the engine, if one 
knows the right keyboard dance, since basically most of the same code 
(including for user-input handling) is also shared with many of my DCC 
tools, ...

yes, I could, very easily, more directly integrate 3D modeling and 
animation modes into the 3D engine as well (currently these are separate 
tools though, but generally differ only in a single source-file 
representing the "front end", with most of the actual logic being 
handled by the 3D engine DLLs).


or such...

[toc] | [prev] | [next] | [standalone]

#1051 — Re: multi-line editing/evaluation...

"BGB" <cr88192@hotmail.com> wrote in message
news:jjlqg2$vbf$1@news.albasani.net...
> [...]
> problem:
> I was having a hard-time thinking up a good way to
> interface a text editor with the 3D Engine's UI.
>

1) line editor
2) use the GUI to point and click program
3) zero display text entry
4) remote terminal

For 1), line editors are old concept which is largely forgotten.  See:
http://en.wikipedia.org/wiki/Line_editor

For 2), your alt key combination transports you from your current room to a
special room.  The room has a wall.  The wall has many pictures.  Each image
represents one of your macros or code piece.  Point.  Click.  Converts to
text.

For 3), your alt key combination just redirects text input from 3D game to
text entry.  No visual display of what you're typing at all.  Type what you
want.  Be careful.  BTDT (but not with a 3D game...).

For 4), you'll need another computer and display, a communication line
(serial, USB, ethernet, modem, etc), and software to connect the two or
transfer files (ssh, ftp, rz/sz, zmodem, kermit, rlogin, etc).  The main PC
displays the 3D game, and the remote displays text.  The remote doesn't have
to be remotely located, of course.  It'll be next to you, e.g., old laptop.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1054 — Re: multi-line editing/evaluation...

On 3/12/2012 11:43 PM, Rod Pemberton wrote:
> "BGB"<cr88192@hotmail.com>  wrote in message
> news:jjlqg2$vbf$1@news.albasani.net...
>> [...]
>> problem:
>> I was having a hard-time thinking up a good way to
>> interface a text editor with the 3D Engine's UI.
>>
>
> 1) line editor
> 2) use the GUI to point and click program
> 3) zero display text entry
> 4) remote terminal
>
> For 1), line editors are old concept which is largely forgotten.  See:
> http://en.wikipedia.org/wiki/Line_editor
>

a line editor is what I currently have.

previously, there was nothing: all interactively-entered script 
fragments had to fit on a single line.


I added the line editor initially, because this was a lot faster and 
easier to implement than a "proper" text editor would be.

that done, I am considering "moving up" to a more advanced text editor, 
namely something where the usual keys do their usual things (arrow keys 
move the cursor, enter adds a line-break, ...).


> For 2), your alt key combination transports you from your current room to a
> special room.  The room has a wall.  The wall has many pictures.  Each image
> represents one of your macros or code piece.  Point.  Click.  Converts to
> text.
>

?...
totally bizarre idea.

not likely all that practical though, since presumably if a person is 
bringing up an in-program editor, they are wanting to mess around with 
something right in front of them (where they already are).


> For 3), your alt key combination just redirects text input from 3D game to
> text entry.  No visual display of what you're typing at all.  Type what you
> want.  Be careful.  BTDT (but not with a 3D game...).
>

why?

there is a console for typing commands.
I am not doing this Doom style, it is more like Quake and later style.
the console differs some cosmetically from the one in Quake 1/2/3/4 and 
Doom3, and also from the one in Source games (Valve had the amazing idea 
of making their console be some sort of in-game detached window, like it 
were an xterm window or something...).


note, IIRC:
Quake 1/2/3 had the console accessed via '~';

Doom 3 / Quake 4 used CTRL-ALT-~

both Half-Life (GoldSrc) and Source require a "developer" cvar to be set 
(either via the command-line or editing the config file), at which point 
it was accessed via '~'.

in my case, it is ALT-~, mostly because ~ is a valid operator in 
BGBScript (and using it as the console key would make it unusable in 
interactive entry). for a long time I was using CTRL-~, but in the game 
project, CTRL is by default bound to "+fire" (fire weapon), which had 
the annoying side effect of firing the gun whenever entering the console 
(and, worse, sometimes getting stuck, with the gun firing the whole time 
one is in the console...). so, I changed it to ALT.

I don't personally trust CTRL-ALT, since this is used for a number of OS 
command-keys (CTRL_ALT-PGDN and suddenly PC goes into sleep mode, ...), 
or CTRL-ALT-F2 and Linux will dump the user at a text-mode console 
(sorry, your X11 is in another console), ...


I just made it a full-screen (full-window) overlay.
at the current default (errm, hard-coded) window resolution, this works 
out to a 100x75 character console (of which, 80x25 or 80x50 or 80x55 or 
so would probably be used for the editor region).

I was considering the right-hand margin would likely hold an open-file 
list or similar. out of nostalgia... one could also design the UI using 
CP437 characters and a similar style to QBasic, and maybe even a similar 
color scheme as well... "you ready for some white text on a blue 
background?!... (yelled cheers) YEAH!"



granted, when one is in the console, it is currently not possible to 
move or interact with the scene, and (like in Doom3, unlike most other 
Quake-family engines) the console being active doesn't automatically 
pause the game, leading to a potential "monsters own you as you try to 
type your cheat-codes" style events.

ironically, Doom3 did several things to make this annoying (for cheats 
users):
every map change would tend to forget any active cheat codes;
Doom3 tended to have a lot of maps where the player spawns with monsters 
"all up in their grill" as soon as they spawn (rarely done in other 
games, generally the player spawn location is a safe spot, where 
monsters are either not spawned nearby, or are generally spawned facing 
away from the spawn-point).

this could have all been deliberate though, such as to hinder people 
easily playing through the whole game with cheats on.


> For 4), you'll need another computer and display, a communication line
> (serial, USB, ethernet, modem, etc), and software to connect the two or
> transfer files (ssh, ftp, rz/sz, zmodem, kermit, rlogin, etc).  The main PC
> displays the 3D game, and the remote displays text.  The remote doesn't have
> to be remotely located, of course.  It'll be next to you, e.g., old laptop.

errm, why?

this would be considerably more awkward and annoying than, say, typing 
stuff in the console, or even alt-tabbing into an editor (which is what 
I was previously doing).

ALT-TAB is annoying, but much less so than having to alternate between a 
PC and a laptop would be.


the goal is to minimize effort, which in this case, is mostly a matter 
of key-presses.

[toc] | [prev] | [next] | [standalone]

#1055

maybe in the long run, editing the dll used by you favorite editor, so as to render the text control to an openGL surface set up by you would be best. GUI poo and stool kits will limit many, but why is the GUI not doubly abstracted via  a handle to a windowing environment, not a pointer to one?

[toc] | [prev] | [next] | [standalone]

#1056

On Mar 12, 9:38 pm, BGB <cr88...@hotmail.com> wrote:
> here is the scenario:
> I have a 3D engine;
> it has a console;
> I can evaluated code fragments at said console.
>
> basically, sort of like the Quake-family engines, except that the
> console is a full-screen translucent overlay, and presently accessed via
> "ALT-~" (both CTRL-~ and ~ by itself had drawbacks).
>
> I was generally limited (WRT evaluating script expressions) to whatever
> I could reasonably type at a command-prompt.
>
> so, then I was left thinking, "what if I had a text editor"?
>
> the idea would be to have something sort of like QBasic or the "SQL
> Server Management Studio", where one can type/edit scripts, in program,
> and then evaluate them. or, likewise, highlight chunks of text, hit an
> "evaluate" key, and have it do something.
>
> a partial reason would be to reduce the current annoyance of the prior
> process:
> ALT-TAB (get into Notepad2 or similar);
> edit script;
> ALT-TAB (get back into 3D engine);
> UP-Arrow, Enter (say, to execute a prior ";load(...);" command).
> (possibly mixed with ALT-~ to enter/exit console).
>
> problem:
> I was having a hard-time thinking up a good way to interface a text
> editor with the 3D Engine's UI.
>
> I was left considering more complex options, roughly things like
> allowing multiple consoles (and/or "tabs"), and basically allowing
> implementing something roughly along the lines of QBasic or MS-Edit
> inside the console (switch to a secondary console, pull up "edit", go
> into something sort of like QBasic, type code, have it do stuff,
> presumably in the 3D scene, ...).
>
> current thinking:
> ALT-~ enters/exits console (as before);
> SHIFT + F1-F9 select the active console/tab (when console is active,
> these execute commands if console is not active).
>
> I was tempted, but as-is, this would be kind of a pain to implement
> (would have to both code up the editor, and make some changes to how the
> console is handled, ...). note that the console buffer is basically a
> grid of characters and color/effect values, and so is "essentially
> similar" to text-mode (most obvious difference being that the buffer is
> the Unicode-BMP, vs "IBM Extended ASCII" / "CodePage 437").
>
> some of the needed changes were already made though (adding
> "ConsoleInfo" structures and similar).
>
> as a much faster/cheaper/initial option, I ended up doing something
> different:
> I added console commands that basically work vaguely similar to
> something like "edlin", where one basically edits by typing in
> line-numbers and lines of text, or can invoke commands for things like
> adding/deleting lines, printing lines to the console, ...
>
> so, for example (preexisting syntax):
> ;printf("Hello\n");   //evaluate expression directly
>
> the ';' prefix mostly tells the console that it is a script expression,
> rather than, say, a console generic command (or getting/setting a cvar).
>
> and, new syntax:
> *1 printf("Hello\n");
> *2 printf("Hello again\n");
> *eval
>
> which executes both lines, oddly not nearly as horrid/awkward as one
> might think (though using * for this is slightly annoying, there are not
> many other better options available).
>
> I could (or may) still consider investing effort in throwing together
> something vaguely more QBasic-like (being much more better suited for
> things like editing script files, and limited to consoles 2-9 for
> technical reasons, ...).
>
> any thoughts?

If you're using Windows, would it be possible to put up a multiline
edit box, and subclass it so that, say, F5 causes your progran to read
what's in the box and act on it? That way you get a reasonable set of
editing functions done for you.

Or am I barking up completely the wrong tree here?

[toc] | [prev] | [next] | [standalone]

#1057

On 3/14/2012 3:08 PM, Paul N wrote:
> On Mar 12, 9:38 pm, BGB<cr88...@hotmail.com>  wrote:

<snip>

>>
>> I could (or may) still consider investing effort in throwing together
>> something vaguely more QBasic-like (being much more better suited for
>> things like editing script files, and limited to consoles 2-9 for
>> technical reasons, ...).
>>
>> any thoughts?
>
> If you're using Windows, would it be possible to put up a multiline
> edit box, and subclass it so that, say, F5 causes your progran to read
> what's in the box and act on it? That way you get a reasonable set of
> editing functions done for you.
>
> Or am I barking up completely the wrong tree here?

I am on Windows, but can't really use GDI widgets or similar because:
the app is cross-platform (also runs on Linux);
the app is OpenGL based;
...


I did later end up going and writing a custom in-console text editor (in 
a vaguely similar style to MS-Edit or QBasic).

it mostly supports basic text-editing tasks, but still needs the ability 
to select things and use copy/paste and similar (not yet implemented).


and, yes, hitting F5 does cause the contents of the editor box to be 
executed/evaluated.

ALT-SHIFT + A-Z also allow switching between open files (displayed in a 
list to the right of the editor window), but there is an issue in that 
the keyboard shortcut is kind of uncomfortable.



as-is, it uses kind of a lame/hack interface for loading/saving though:
"ALT-;" toggles between text-entry mode and console mode (sort of, one 
first has to type "*start_edit" to bring up the text editor initially). 
could also consider "CTRL-SHIFT-:" or "CTRL-;" here.

currently, loading and saving files in the editor is still handled via 
console commands.


I have a load/save dialog-box in the engine, but there are currently 
technical issues regarding using it, and I would almost be better off 
implementing a load/save box from within the console itself...

otherwise, I would need to pass around some function-pointers (due to 
code-visibility issues), which would also need to disable/enable the 
console (the load/save dialog can't be used when the console is down, 
...), and/or devise some other hacks to handle all this.

dealing with drawing stuff directly into a character-grid console buffer 
(and doing ASCII art), and assigning bunches of function-pointers to 
make it all work (including saving a some backup function-pointers which 
are called as well, ...), does sort of almost make one feel like they 
are coding for DOS again though...

one can almost feel the memories of "MKFP(0xB800, 0x0000)" and similar 
coming back to them... (only, sadly, my current font lacks most of the 
CP437 extended characters...).

some of the funkiness is due to the code for drawing the console and 
handling the real user-input, and the code for the text editor 
interface, being in different DLLs without direct visibility of 
each-other. likewise, I ended up using function-pointers in a vaguely 
similar manner to the old-style interrupt handlers, so a 
function-pointer is set to trap console redraw events, and another to 
trap keyboard input, ... (many were added simply so that the editor 
could trap them and override the default behavior).

but, alas, it works, and it is better than what I had originally 
imagined: doing all of this stuff via ANSI codes.


or such...

[toc] | [prev] | [next] | [standalone]

#1058

"BGB" <cr88192@hotmail.com> wrote in message
news:jjrj81$7vi$1@news.albasani.net...
> [...]
> as-is, it uses kind of a lame/hack interface for loading/saving though:
> "ALT-;" toggles between text-entry mode and console mode (sort of, one
> first has to type "*start_edit" to bring up the text editor initially).
> could also consider "CTRL-SHIFT-:" or "CTRL-;" here.
>

Up for another "bizarre" idea?

It sounds like you're actually using a video-card text mode for the
text-entry mode ...  Are you?  Can't you create your own "sprites" for an
ASCII font and use them for "text" in your graphics console mode?  You can
make them see-through that way.  Didn't you say your text was see-through
... ?  If you've done it this way, I don't understand what the problem is.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1059

On 3/15/2012 1:10 AM, Rod Pemberton wrote:
> "BGB"<cr88192@hotmail.com>  wrote in message
> news:jjrj81$7vi$1@news.albasani.net...
>> [...]
>> as-is, it uses kind of a lame/hack interface for loading/saving though:
>> "ALT-;" toggles between text-entry mode and console mode (sort of, one
>> first has to type "*start_edit" to bring up the text editor initially).
>> could also consider "CTRL-SHIFT-:" or "CTRL-;" here.
>>
>
> Up for another "bizarre" idea?
>
> It sounds like you're actually using a video-card text mode for the
> text-entry mode ...  Are you?  Can't you create your own "sprites" for an
> ASCII font and use them for "text" in your graphics console mode?  You can
> make them see-through that way.  Didn't you say your text was see-through
> ... ?  If you've done it this way, I don't understand what the problem is.
>


actually, it is all done in-program already.

the console is itself rendered using OpenGL, hence why it is translucent.


a lot of the console code is fairly old, and I haven't messed with it 
much in years (until recently).

however, the "style" of the console is similar to that of the HW 
textmode, with the most obvious difference being that both the 
characters and color/flags-codes are 16 bits.


so, main console:
conbuf: big 2D grid of 16-bit characters (theoretically, Unicode BMP).

conclr: big 2D grid of 16-bit color/status values.
the low 8 bits are used for the foreground and background colors, and 
use the same basic layout and color palette as in text-mode;
the other bits currently give flags: blink, underline, strike-out, bold, 
italic.


how fonts are done:
externally, they are represented as bitmapped fonts in a custom format. 
the Unicode characters came from an old version of "Unifont".

most of the ASCII-range characters use a custom font, which mostly has 
the merit of improved readability (by having the same character-cell 
size as most of the on-screen characters).

internally, the fonts are handled by generating banks of textures, each 
texture holding a grid of character cells (these textures are generated 
on-demand, by rendering all of the relevant character cells into the 
texture).

when the characters are drawn on-screen, the appropriate textures are 
bound, and the character cells are drawn as quads (with some internal 
added hackishness).


now, as for the UI issues:
this is mostly due to code organization.

my 3D engine isn't built as a single large binary, but rather as a 
collection of DLLs.

as-is, the code for rendering the console (and also the normal load/save 
dialog) is located in one DLL, but the text-editor is in another DLL, 
which can't directly call into the first DLL.


currently, interfacing is done via a shared struct with a bunch of 
function pointers and similar in it, as well as arrays for the console 
buffer and similar.

setting up the editor involves setting function pointers and drawing 
directly into the console buffers.


the contents of the DLL holding the editor in-fact have no access to 
either OpenGL or the 3D renderer (as it is generally code shared between 
the "client" and "server" parts of the 3D engine).


natural result: it can't access the (graphical) load/save dialog. or, at 
least, not without resorting to hacks or code reorganization (such as 
moving the text editor into the 3D renderer).

a possible option could be to write some code for implementing an 
in-console text-based load/save dialog.


so, general DLL dependency graph:
Engine (Main Engine)
-> BTGESV (Server End, "game-logic", ...)
   -> BTGECM, VECMATH, ...
-> LBXGL (Renderer/Client, Higher-level, models/world/etc)
   -> PDGL (Renderer, Lower-level)
     Manages:
       Basic OpenGL stuff
       Textures / Fonts / ...
       Console(drawing)
       Camera, GUIs, Sound, ...
     -> BTGECM
     -> BGBMID (MIDI playback)
     -> Tremor (Xiph.org, alternative Ogg/Vorbis codec)
     -> VECMATH (Vector Math stuff)
     -> ...

BTGECM (Common)
Manages:
   Shared MAP / BSP stuff
   Voxels, Perlin Noise, ...
   Client/Server Network stuff
   Shared Console Stuff:
     Cvars
     Command Evaluation (partly)
     Console Scripts (partly)
     Text Editing UI
-> VECMATH
-> BGBSVM (BGBScript VM Core)
   -> BGBDY, BGBGC, BGBASM, ...
-> BGBNET (Lower-level Network Code: Sockets, ...)
   -> BGBDY (VM Support Code, Dynamic Type-System, ...)
     -> BGBGC (Garbage Collector)
     -> BGBASM (Assembler/Linker)
     -> ...
...

[toc] | [prev] | [next] | [standalone]

#1060 — Re: multi-line editing/evaluation...

BGB wrote:

> I was generally limited (WRT evaluating script expressions) to whatever
> I could reasonably type at a command-prompt.
>
> so, then I was left thinking, "what if I had a text editor"?
>
> the idea would be to have something sort of like QBasic or the "SQL
> Server Management Studio", where one can type/edit scripts, in program,
> and then evaluate them. or, likewise, highlight chunks of text, hit an
> "evaluate" key, and have it do something.

Try looking at the way that most Smalltalks do this (Dolphin is the best to 
look at for this issue):

+ Any code editor supports code execution.

+ If you highlight some code then press <some key> then that code is executed. 
It's your responsibility to ensure that it makes sense.

+ If your code assigns to a variable that doesn't yet exist then that variable 
is "declared" and becomes part of the state of that edit window (note: 
Smalltalk doesn't have implicit variable declaration in general, this is a 
special feature just for interactive use.)

+ If your press the evaluation key (it's actually F5 in Dolphin, as with the MS 
dev tools) when nothing is selected then it uses the current line as the 
"selection".

+ A "workspace" (the Smalltalk term for an interactive "console") is just an 
initially empty edit window, /not/ a REPL.

It all works very well, and because there only one thing which is both the 
"console" and the "editor", it actually simplifies the implementation.

HTH

    -- chris 

[toc] | [prev] | [next] | [standalone]

#1061 — Re: multi-line editing/evaluation...

On 3/16/2012 1:54 AM, Chris Uppal wrote:
> BGB wrote:
>
>> I was generally limited (WRT evaluating script expressions) to whatever
>> I could reasonably type at a command-prompt.
>>
>> so, then I was left thinking, "what if I had a text editor"?
>>
>> the idea would be to have something sort of like QBasic or the "SQL
>> Server Management Studio", where one can type/edit scripts, in program,
>> and then evaluate them. or, likewise, highlight chunks of text, hit an
>> "evaluate" key, and have it do something.
>
> Try looking at the way that most Smalltalks do this (Dolphin is the best to
> look at for this issue):
>
> + Any code editor supports code execution.
>
> + If you highlight some code then press<some key>  then that code is executed.
> It's your responsibility to ensure that it makes sense.

yep.

> + If your code assigns to a variable that doesn't yet exist then that variable
> is "declared" and becomes part of the state of that edit window (note:
> Smalltalk doesn't have implicit variable declaration in general, this is a
> special feature just for interactive use.)

I don't generally have implicit declaration either, but as-is, it is 
sort of possible to implicitly declare variables by assignment at the 
toplevel.


> + If your press the evaluation key (it's actually F5 in Dolphin, as with the MS
> dev tools) when nothing is selected then it uses the current line as the
> "selection".

I am also using F5. no need to make the keyboard shortcuts entirely 
inconsistent.

however the current behavior is to assume, like the MS tools, that if 
nothing is selected then this means to execute everything in the editor 
window.


> + A "workspace" (the Smalltalk term for an interactive "console") is just an
> initially empty edit window, /not/ a REPL.
>
> It all works very well, and because there only one thing which is both the
> "console" and the "editor", it actually simplifies the implementation.

in my case, I have both styles.

the console/repl/shell style came first (and its present form was 
initially motivated by both Quake and the Scheme REPLs). IIRC, 
originally I did like Quake and had it come down from the bottom, but 
later switched to using a full-screen overlay instead, since this 
allowed a lot more text reading/writing to go on.

an editor interface was added more recently.
as-is, it requires a console command to start the editor though 
("*start_edit", may change though, like say "edit" or similar).


then I went and was off working on trying to optimize my 3D renderer a 
little more.

idle thought regarding what a programming language would look like if 
the entire design could be (somehow) done based almost entirely on 
popular opinion (rather than, say, the personal biases of the 
initial/main developers).

or such...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.misc

csiph-web