[colorforth] Ideas - was RE: [colorforth] Low res or low color ColorForth

[<howerd.oakford@xxxxxxxxxxxx>]

Hi Adam,

> I can't seem to get started,
> i got lot of great ideas,
> but I'm missing pieces somehow.
Are you having problems with getting colorForth to run?
We need ideas, I suspect that we are all missing pieces, and you have
already started ;)

> What we should truly do is a colorforth each one of us,
> to discuss new ideas, and then make it mutate into
> something better than what was already achieved.
Yes!

I use colorForth to explore new ideas. One of those ideas is the best
relationship between individual creativity and community-based standards. As
an experiment, I have released CFDOS2.blk, a modified colorForth system
(V2.0) which has some of the kernel names changed to make them more
compatible with ANS Forth.
What this means, of course, is that now when someone publishes some
colorForth V1.0 code it will not work without some changes being made to it
to match the V2.0 kernel names.

Some questions arise :

1. Is this incompatibility acceptable?
2. If not, how can changes to the kernel be made "universal" ?

A similar example :

I have created two new font patterns for a simple game ( slime ), in font
positions 100 and 101.
Therefore my game will not work with a font that does not have these extra
patterns.
How can we make it easy to run the game on another system, without
hand-editing the source or font?

Some obvious answers :
1. "Windows" - specify a font by name in the program, and insist that the
user installs this font.
2. "make" - provide a source file dependency tree, so that a "loader" finds
the font and loads it.
3. "indirect font blocks" - fonts are accessed through a start block number.
Remote blocks are mapped to certain blocks. Make the font start block be on
a remote computer with the correct font.
4. "UNICODE" - define universal fonts using a variable length token.
5. "VNC" - provide a graphics API and run the program on a remote computer
that has the required font.
6. "no-fonts" - don't use the standard font, define your own as part of the
program.
7. "OOP" - make the program work out what fonts it needs when it starts up,
and go find them.
8. "whole system" - supply the kernel along with the program.

If you look at the problem from the point of view of information flow, the
font patterns must somehow get from where they are stored on one computer,
to the screen of another. The choice is when the data is moved, where it is
stored and for how long.
"Windows" - happens at compile time ( sort of ).
"make" happens at compile time - loading the game causes other "files" to be
loaded. I think this needs files, or named counted strings.
"UNICODE" happens at edit time - the data is moved as part of the kernel (
or font extensions to the kernel ).
This is the most static of the solutions, and does not allow new patterns to
be added easily.
"VNC" happens at run-time, - the font patterns are moved as pixels. This
limits the number of people who can run the game at the same time.
"indirect font blocks" happens at run startup time ( provided there is a
large enough remote-block cache ).
"no-fonts" - may be the best way. There is no problem ;)
"OOP" - I have yet to be convinced of the usefulness the "dependency
inversion" style of OO programming.
"whole system" has problems when the hardware is different - my kernel might
not run on your PC...

Comments?

Howerd  8^)


-----Original Message-----
From: Adam Marquis [mailto:adam.marquis@xxxxxxxxxxxx]
Sent: 28 February 2004 01:13
To: colorforth@xxxxxxxxxxxxxxxxxx
Subject: Re: [colorforth] Low res or low color ColorForth


What we shoudl truly do is a colorofrth each one of us,
to discuss new ideas, and then make it mutate into
something better than what was already achieved.

I can,t seem to get started, i got lot of great ideas,
but I'm missing pieces somehow. I tried to motivate
myself a moment ago by sending CVs to companies
and proposing them scenarios of guerilla programming.

They all looked strange, all market-droids lol

Adam

John Drake wrote:

>Hello all,
>
>Looking at the latest on c.l.f. of people who "just
>can't get ColorForth to run" got me to thinking.
>What about a version of ColorForth that didn't
>require SuperVGA?  So far the only ColorForth programs
>that I've seen that really push the resolution/color
>envelope are the JPEG decoder and the Mandelblot
>viewer.  I'm thinking VGA Mode X (320x240x256) or
>one of the high res EGA modes if resolution is
>more important than color (800x600x16 for example).
>Would making ColorForth run under either of these
>modes be an extreme undertaking?
>
>Regards,
>
>John M. Drake
>
>__________________________________
>Do you Yahoo!?
>Get better spam protection with Yahoo! Mail.
>http://antispam.yahoo.com/tools
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
>For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
>Main web page - http://www.colorforth.com
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com