On 3/11/2012 5:28 AM, Jakub Piotr Cłapa wrote:
On 28.02.12 06:42, BGB wrote:
but, anyways, here is a link to another article:
http://en.wikipedia.org/wiki/Shannon%27s_source_coding_theorem

Shannon's theory applies to lossless transmission. I doubt anybody here wants to reproduce everything down to the timings and bugs of the original software. Information theory is not thermodynamics.


Shannon's theory also applies some to lossy transmission, as it also sets a lower bound on the size of the data as expressed with a certain degree of loss.

this is why, for example, with JPEGs or MP3s, getting a smaller size tends to result in reduced quality. the higher quality can't be expressed in a smaller size.


I had originally figured that the assumption would have been to try to recreate everything in a reasonably feature-complete way.


this means such things in the OS as:
an OpenGL implementation;
a command-line interface, probably implementing ANSI / VT100 style control-codes (even in my 3D engine, my in-program console currently implements a subset of these codes);
a loader for program binaries (ELF or PE/COFF);
POSIX or some other similar OS APIs;
probably a C compiler, assembler, linker, run-time libraries, ...;
network stack, probably a web-browser, ...;
...

then it would be a question of how small one could get everything while still implementing a reasonably complete (if basic) feature-set, using any DSLs/... one could think up to shave off lines of code.

one could probably shave off OS-specific features which few people use anyways (for example, no need to implement support for things like GDI or the X11 protocol). a "simple" solution being that OpenGL largely is the interface for the GUI subsystem (probably with a widget toolkit built on this, and some calls for things not directly supported by OpenGL, like managing mouse/keyboard/windows/...).

also, potentially, a vast amount of what would be standalone tools, could be reimplemented as library code and merged (say, one has the "shell" as a kernel module, which directly implements nearly all of the basic command-line tools, like ls/cp/sed/grep/...).

the result of such an effort, under my estimates, would likely still end up in the Mloc range, but maybe one could get from say, 200 Mloc (for a Linux-like configuration) down to maybe about 10-15 Mloc, or if one tried really hard, maybe closer to 1 Mloc, and much smaller is fairly unlikely.


apparently this wasn't the plan though, rather the intent was to substitute something entirely different in its place, but this sort of implies that it isn't really feature-complete per-se (and it would be a bit difficult trying to port existing software to it).

someone asks: "hey, how can I build Quake 3 Arena for your OS?", and gets back a response roughly along the lines of "you will need to largely rewrite it from the ground up".

much nicer and simpler would be if it could be reduced to maybe a few patches and modifying some of the OS glue stubs or something.


(tangent time):

but, alas, there seems to be a bit of a philosophical split here.

I tend to be a bit more conservative, even if some of this stuff is put together in dubious ways. one adds features, but often ends up jerry-rigging things, and using bits of functionality in different contexts: like, for example, an in-program command-entry console, is not normally where one expects ANSI codes, but at the time, it seemed a sane enough strategy (adding ANSI codes was a fairly straightforward way to support things like embedding color information in console message strings, ...). so, the basic idea still works, and so was applied in a new context (a console in a 3D engine, vs a terminal window in the OS).

side note: internally, the console is represented as a 2D array of characters, and another 2D array to store color and modifier flags (underline, strikeout, blink, italic, ...).

the console can be used both for program-related commands, accessing "cvars", and for evaluating script fragments (sadly, limited to what can be reasonably typed into a console command, which can be a little limiting for much more than "make that thing over there explode" or similar). functionally, the console is less advanced than something like bash or similar.

I have also considered the possibility of supporting multiple consoles, and maybe a console-integrated text-editor, but have yet to decide on the specifics (I am torn between a specialized text-editor interface, or making the text editor be a console command which hijacks the console and probably does most of its user-interface via ANSI codes or similar...).

but, it is not obvious what is the "best" way to integrate a text-editor into the UI for a 3D engine, hence why I have had this idea floating around for months, but haven't really acted on it (out of humor, it could be given a VIM-like user-interface... ok, probably not, I was imagining more like MS-Edit or QBasic or something, if I went the ANSI-code route).

much simpler though could be something sort of like edlin, where editing is done via typing line numbers, ...:
"*m A"    //edit module A
"*i10"    //edit insert at line 10
"*10 btBecomeExplosion(ent);"    //edit line 10 to be this
"*p"    //print contents of module
"*l somefile"    //load module data from file
"*s [somefile]" //save contents to file
"*e"    //evaluate
...
(yes, this would suck... but would be easy to implement, wouldn't entirely hijack the console, and is maybe sufficient for the task... hmm...).


another recent observed issue: console opacity. as-is, the console is semi-translucent, so stuff going on in the background is hard to see through the console (when it is active), but OTOH, if the console is more translucent, it can be harder to read the text (may need to think up something for this).

did at least recently add a few things to help with interactive scripting, like a feature to optionally overlay all of the entity numbers on the screen, and working on making the script VM less prone to crash in the case of a syntax error (due to mistyping something or similar), and found/fixed a few other parser bugs while I was at it (the parser was a bit lacking with things like error handling).

it is also kind of lame that I don't have some sort of auto-complete feature for script fragments (must remember and type complete function names). currently, auto-complete only works for basic console-commands and cvars.


or such...

_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Reply via email to