Multimedia REBOL... yes or no?
[1/30] from: Carl:rebol at: 10-Jul-2003 10:32
Pekr wrote (in the "Frank's Looper Crash Answer" thread):
>I am curious to know your opinion, because I think if it would be all
>that easy to do games in rebol, there would be plenty of them. Rebol is
>the nicest engine for whatever - even game development imo, but it
>reaches some technical limits (speed, not full keyboard support, other
>functionality as 3D, better sound etc.)
Some history: when I wrote the "grandfather" of REBOL in 1990, it was
for multimedia. Those of you who own old CDTV demo CDs actually have a
copy of a very old REBOL run-time environment that did graphics, motion
video, sync'd sound, etc. In fact, at one of the very first CDROM MM
conferences, we blew Intel out of the water (using a 7MHz CDTV!)
In the mid '90s, the granddaddy REBOL evolved for use in cable TV boxes
(VideoStream, Inc.) and controlled JPEG encoders and decoders, again
with sync'd sound. In fact, back in 1995, we had some of the best
interactive TV demos on the planet. Even the folks at Warner Music in
NY, who were building their own system, asked "how'd you do that?"
But, then, along came shockwave and flash. I knew a lot about the
Macromedia MM products (I had studied every MM system around by
that point :), and I decided not to try and compete with them. There did
not seem to be "room" for more than one, and that fact may still be true
today.
A few months ago, Cyphre convinced me that we should give it a shot.
Being that MM is near to my heart, I agreed. But then unfortunately
Cyphre was hired to go work on other things (and I know that these days,
good jobs are worth keeping).
I've seen Cyphre's 3D demo (based on Cal's prior), and it's cool.
But, if you want to know the big "blocking point" when it comes to MM
and 3D in REBOL, here is the question you need to answer for me:
Can it be made machine independent?
There are two possible answers:
YES: great! Let's do it.
NO: then, should we still do it for just a couple platforms, and say
sorry
to the rest?
I would like to see MM and 3D in REBOL. But, is it time for a split
from one of the main themes of REBOL? Will the result help or hurt
REBOL?
Tell me your thoughts.
-Carl
[2/30] from: rotenca:telvia:it at: 10-Jul-2003 20:18
> I would like to see MM and 3D in REBOL. But, is it time for a split
> from one of the main themes of REBOL? Will the result help or hurt
> REBOL?
My humble opinion is that you should open the "library" and the "call"
interface to everyone FOR NON COMMERCIAL USE.
So we'll see opengl and other free additions to rebol.
If one want to use them in a commercial environment, he must buy Pro/Command.
Rebol core/view remains the same for all platform.
---
Ciao
Romano
[3/30] from: nitsch-lists:netcologne at: 10-Jul-2003 21:25
Am Donnerstag, 10. Juli 2003 19:32 schrieb [Carl--rebol--com]:
> Pekr wrote (in the "Frank's Looper Crash Answer" thread):
> >I am curious to know your opinion, because I think if it would be all
<<quoted lines omitted: 27>>
> There are two possible answers:
> YES: great! Let's do it.
Scripting & 3D:
http://www.jwdt.com/~paysan/bigforth.html#SCREENSHOT
Bigforth has a 3D-Turtle, based on OpenGL,
but IMHO easier to program.
Search for "Dragongraphic"
This Dragon is ugly, i agree.
But in bigforth it flies circles, with flapping wings.
Pure source, no 3D-Modeller needed.
I would like something like this in rebol.
Portability:
http://joi.ito.com/archives/2003/02/04/croquet_the_os_of_the_future.html
Croquet based on squeak-smalltalk.
David is a 3D guru so he has made the interface completely 3D where you can
fly around, see other users as avatars, create 3D objects with scripts and
share them dynamically and in real time in the shared space. He is working on
all of the necessary pieces to deal with identity and security as well.
It is totally cross-platform and is
pure" in its portability."
http://www.libsdl.org/index.php
SDL
Simple DirectMedia Layer is a cross-platform multimedia library designed to
provide level access to audio, keyboard, mouse, joystick, 3D hardware via
OpenGL, and 2D video framebuffer. It is used by MPEG playback software,
emulators, and many popular games, including the award winning Linux port of
Civilization: Call To Power."
Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS
X, FreeBSD, OpenBSD, BSD/OS, Solaris, and IRIX. There is also code, but no
official support, for Windows CE, AmigaOS, Dreamcast, Atari, QNX, NetBSD,
AIX, OSF/Tru64, and SymbianOS."
> NO: then, should we still do it for just a couple platforms, and say
> "sorry" to the rest?
Worlds
and flight-simulators would work.
Worlds (games like settler):
You could implement "settler"-engines in 2D/ISO and true 3D.
(Isometric Tiled Graphics
One could choose based on platform.
Some areas would only work in 3D, but one could meet outside.
Such games could be interesting because each settler could have
behavior-scripts in rebol.
Also the ISO-Graphics could be rendered on a 3D-Machine,
Each Animation-Frame needs 8-16 images from all directions,
motions could be based on physics/math.
Flight-Simulators:
Exists playable for 2D-Machines >= Amiga, so that should work.
All the sugar would need hardware, but nobody would be fully excluded.
And eventually Worlds and Flyers could be combined :)
> I would like to see MM and 3D in REBOL. But, is it time for a split
> from one of the main themes of REBOL? Will the result help or hurt
> REBOL?
>
> Tell me your thoughts.
>
> -Carl
Wreeeowmmm, -Volker
[4/30] from: chris:langreiter at: 10-Jul-2003 21:09
>> I would like to see MM and 3D in REBOL. But, is it time for a split
>> from one of the main themes of REBOL? Will the result help or hurt
>> REBOL?
> My humble opinion is that you should open the "library" and the "call"
> interface to everyone FOR NON COMMERCIAL USE.
I tend to agree ...
It's no question that I'd LOVE to see REBOL to be a competitive player
in the multimedia arena, on the other hand competing with the likes of
Flash MX and Director won't be easy, so the main question for me is
wether RT has the resources to pull it off ... as REBOL development
seems to have almost halted (at least from the outside, if there's
a lot of stuff going on I/we don't know anything about - sorry!). If
the answer is not a definite yes, then I'd rather welcome more work on
the extension interfaces, so that the users can extend REBOL to be
whatever they think it should be themselves.
As for platforms, the only ones _I_ care about are Windows, OS X and
Linux.
Best regards,
-- Chris
[5/30] from: andreas:bolka:gmx at: 10-Jul-2003 21:37
Thursday, July 10, 2003, 8:18:32 PM, Romano wrote:
>> I would like to see MM and 3D in REBOL. But, is it time for a split
>> from one of the main themes of REBOL? Will the result help or hurt
>> REBOL?
> My humble opinion is that you should open the "library" and the
> "call" interface to everyone FOR NON COMMERCIAL USE.
+1 - this matches my humble opinion.
--
Best regards,
Andreas mailto:[andreas--bolka--gmx--net]
[6/30] from: petr:krenzelok:trz:cz at: 10-Jul-2003 22:13
>But, if you want to know the big "blocking point" when it comes to MM
>and 3D in REBOL, here is the question you need to answer for me:
<<quoted lines omitted: 7>>
>REBOL?
>Tell me your thoughts.
OK, I am sorry that my ideas will be more general than you will probably
like :-)
Carl - I remember one of your interviews after you were asked by GW to
lead AmigaOS development. You said one nice thing - something like - In
the first place there is technical innovation, which makes your product
popular. Then you forget about why your product became popular, and you
start only repackaging the product. You were talking about Amiga and
what should be done in respective years in regards to OS and hw. To be
honest, your own words remind me of rebol situation too. We simply have
to ask ourselves - what major technical advancement was made to Rebol in
last two years? (unless sitting on your hd). As far as we can see -
there were mainly only cosmetic changes. I know some ppl will object,
that Rebol itself is a technical advancement :-) But how long we will be
able to stay alive with such arguments?
I know very well that sometimes it is difficult to stay in business. But
let's state the obvious - from the outside pov rebol
development/advancement is pure stagnation. Technical limits still
persist. Isolation from external environment still persist - no free
shell, no free library. There is no point in keeping them out of
non-commercial usage at least - rebol syntax and philosophy is in our
brains/hearts - it can't become perl, basic, c anymore imo. Ppl would
applaud you if that situation would change. I even don't think it would
have any finnancil impact on RT - I think quite opposite -
blocking/isolating rebol in certain areas of usage kills many potential
projects. I saw some ppl refusing to use rebol because of that.
Now to be more concrete - if you decide to go MM way - who's there at RT
to actually code it? I think that if RT's man-power is limited, you
should go and ask those community skilled folks to help you. I can bet
they would do it for free (e.g. under NDA), just to help rebol proceed.
There should be coordinators in certain areas, which would help you to
gather info/requests/questions etc. and filter it for you. While it can
be true that open-VID project failed, it was not mostly of my bad
coordination, but because there was no-one left to coordinate. There
were certain decision points, but you were not available to answer. So
my opinion is, that maybe you could use some skilled folks here to help you?
As for the cross-platform compatibility - I already stated it in
previous email, but now I will make it even more clear - what platforms
are you talking about ;-) There is Windows and Linux version, MacOSx
View non-existant, maybe one or two other platforms, - but are those
really compatible and all have the same versions of View available? As
from my perspective - I would prefer rebol being more
componentised/modularised (at least internally) to be able to use on
PDAs. My personal priority list is - Windows, Linux, MacOSx, PDA oses
(WinCE, XPEmbedded?, Symbian, QNX), AmigaOS/MorphOS ... then nothing
really important .... and then maybe others ...
Now shortly technological aspects - 3D is not multimedia - smooth
scrolling, movement, sound sync, effects, transitions is, .... media
format replay is ... then there is 3D :-) And what is more - I think
that all significant platforms support certains apis (OpenGL, Messa),
use hw where possible, if not, emulate thru sw ... but - I will stop
here, as I am not skilled in OS internals but I really think it should
be possible - how do others do it? ...
-pekr-
[7/30] from: maximo:meteorstudios at: 10-Jul-2003 16:26
here goes,
MM in itself IS well covered by other languages... but that's the problem ... its not
rebol code ... that's why most (if not all) of us have changed to rebol for.. its the
syntax and grammar OF THE LANGUAGE we like.
I have built many tools for which rebol wasn't specifically the best platform as a programming
language... things like a (video) editing timeline, production pipeline tool, a distributed
rendering manager, a scsi-ddr (ddr: digital disk recorder) transfer and remote video
deck tool. All of these used many different aspects of rebol and the only one I had
to stop as a project was the timeline editing tool. That's because rebol does not have
any syncronization methods which can garantee a certain level of frames per second refresh
in view, even less if there is image manipulation, even less on windows.
also, as cyphre has illustrated last week, there are still limitations to the external
library access which means we cannot truly use outside tools which potentially could
solve that problem. MM depends on many things and the true problem is in syncro.. how
could we synchronise a 30fps animation to sound and also have some real-time vid/fx rendering
or draw dialect style gfx overlays in rebol ... currently its not possible....
And let me assure everyone that its not easy. I'm not saying Carl isn't up to the task,
who knows, he might already have a rebol|RT (real-time ;-) version on his desk...
Carl, You specifically asked If I was ready to loose some portability in exchange for
performance and added integration to the os... tough call... I'm pretty sure there are
two specific types of users in rebol, the utilities/applets/web/cgi/script types for
which rebol/core and view are PERFECT and then there are some of us which try to use
rebol as a general purpose language. The later group have more problems I think.
I also think that the later type would be more willing to accept a break in the program-once
use Everywhere philosophy. Open gl is the way to go, if you want to keep the maximum
portability... it is available in all flavors of UNIX and Linux, windows, apple (not
sure about amiga). People always think of OpenGL as a 3D language... its also a very
nice 2d language, with nice anti-aliased vector support.
maybe REBOL|OpenGL version could be integrated which has a face built with opengl (and
its various platform adaptations). IT would be compatible with view but would have open
gl library calls available too.
and anyways, what IS rebol using for ITS gfx engine.. wouldn't it be worth it to support
OpenGL when its present in the os anyways, in the current view?
BTW, has anyone looked at image magik... (www.imagemagick.org) I am planning on building
myself a rebol front end to it... thats a uber powerfull image manipulation api which
is used by many high-end tools and production facilities. Plus its free, even commercially,
and its not even bound by a gpl type license.
--
as far as being able to get the os calls and lib access free, I guess Carl will give
the software when he's finished the REBOL|END-HUNGER|PAY-MORTAGE module ... ;-)
Then, will I then get refunded... I have a pro license. I'd feel a little pinched
if they got free (but I won't cause its already paid itself ;) ... But I do agree that
its a pain you have to pay for something as basic as os-calls. I can understand for oracle
DB, Lib-access, etc, etc...
As far as I'm concerned, an easier library integration would be welcomed. that's the
main edge python has over rebol (a part that its free).
-max
-----------
meteor Studios, T.D.
-----------
Strong enough for a man, but made for a woman
[8/30] from: nitsch-lists:netcologne at: 10-Jul-2003 22:56
Am Donnerstag, 10. Juli 2003 22:13 schrieb Petr Krenzelok:
[snip]
> Now shortly technological aspects - 3D is not multimedia - smooth
> scrolling, movement, sound sync, effects, transitions is, .... media
<<quoted lines omitted: 3>>
> here, as I am not skilled in OS internals but I really think it should
> be possible - how do others do it? ...
Agree to multimedia-definitions.
But 3D -> OpenGL -> hardware-acceleration -> smooth..
> -pekr-
>
> >-Carl
-Volker
[9/30] from: Carl:rebol at: 10-Jul-2003 14:58
After reading your messages, I think what we've got are "growing pains".
The kid, REBOL, needs to adapt and grow.
As you know, REBOL was not created for general purpose programming, it
was created for distributed computing... with dialecting and networking.
But now what has happened is that many of us (including me) have become
addicted to the REBOL mindset and use it for everything (maybe too
much). Am I right?
Hey, that's ok. Let's figure out what we need to do and get focused.
Actually, getting focused is the hardest part, isn't it? Remember Amiga,
the computer that could do almost anything? It was pulled in so many
directions, it was hard for the world to recognize what it was best at.
We don't want to do that again.
Another thing, it's important to understand that some people decide to
not use REBOL for reasons other than lack of 3D, MP3, streaming video,
etc. The need for quality docs, examples, how-tos, articles, script
archives, and evangelizing are just as important when you're starting a
rebolution. How do we solve that problem?
So, this is probably a good time to move this topic off of this slowly
updating email list and to something a bit more dynamic. Let's meet up
in the AltME REBOL World and take it up from there...
-Carl
[10/30] from: tomc:darkwing:uoregon at: 10-Jul-2003 15:48
NO PLEASE! and please do not move the discussion to a platform that blocks
out all but Windows & Linux users.
Too many things not compleated.
OSX port,
core consistant across view pro command ...
deep recursion crash
documentation
Carl wrote.
After reading your messages, I think what we've got are "growing pains".
The kid, REBOL, needs to adapt and grow.
As you know, REBOL was not created for general purpose programming, it
was created for distributed computing... with dialecting and networking.
But now what has happened is that many of us (including me) have become
addicted to the REBOL mindset and use it for everything (maybe too
much). Am I right?
Hey, that's ok. Let's figure out what we need to do and get focused.
Actually, getting focused is the hardest part, isn't it? Remember Amiga,
the computer that could do almost anything? It was pulled in so many
directions, it was hard for the world to recognize what it was best at.
We don't want to do that again.
Another thing, it's important to understand that some people decide to
not use REBOL for reasons other than lack of 3D, MP3, streaming video,
etc. The need for quality docs, examples, how-tos, articles, script
archives, and evangelizing are just as important when you're starting a
rebolution. How do we solve that problem?
So, this is probably a good time to move this topic off of this slowly
updating email list and to something a bit more dynamic. Let's meet up
in the AltME REBOL World and take it up from there...
-Carl
On Tue, 8 Jul 2003, Carl at REBOL wrote:
[11/30] from: petr:krenzelok:trz:cz at: 11-Jul-2003 0:53
Maxim Olivier-Adlhoch wrote:
> BTW, has anyone looked at image magik... (www.imagemagick.org) I am planning on building
myself a rebol front end to it... thats a uber powerfull image manipulation api which
is used by many high-end tools and production facilities. Plus its free, even commercially,
and its not even bound by a gpl type license.
>
no, but with Cyphre we did library wrapper for XnView
(http://www.xnview.com ) 300+ image formats. The problem we reached was
that described of inability to have pointer for binary data of certain
size for xnview buffer direct display ...
-pekr-
[12/30] from: maximo:meteorstudios at: 10-Jul-2003 20:31
> (http://www.xnview.com ) 300+ image formats. The problem we
> reached was
> that described of inability to have pointer for binary data
> of certain
> size for xnview buffer direct display ...
Yes it would be nice if view/pro had a raw-image! datatype which is a static pointer
to a raw chunky mode image block of data. on amiga this would be a planar mode image,
I guess.
the only problem I see with rebol is the alpha channel... is it standard to store the
alpha at the end of the datablock, or do other dev tools usually store alpha channel
data as the fourth byte of every pixel?
Xnview is a nice library... if only it had alias wavefront maya (iff) format... its always
missing, although it might only be because of a licensing issue... are you successfully
using knview.dll to read/save out images in other formats, even if slow as hell?
Image magic is a complete 16 bit per channel compositing api. its built from people
in/around the film industry. If my memory serves me well its a spin off of an old sgi
project.
-Max
[13/30] from: g:santilli:tiscalinet:it at: 11-Jul-2003 10:31
Hi Maxim,
On Friday, July 11, 2003, 2:31:53 AM, you wrote:
MOA> the only problem I see with rebol is the alpha channel... is
MOA> it standard to store the alpha at the end of the datablock,
MOA> or do other dev tools usually store alpha channel data as the
MOA> fourth byte of every pixel?
Actually, REBOL stores the image data as 32 bit BGRA or ARGB
depending on platform endianess.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[14/30] from: robert:muench:robertmuench at: 11-Jul-2003 11:16
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: Multimedia REBOL... yes or no?
> Actually, getting focused is the hardest part, isn't it?
Hi, exactly! This isn't a question of "what do I like most" it's the
question of "how to make Rebol a commercial success" because than you
can focus on "what I do like most".
> The need for quality docs,
> examples, how-tos, articles, script archives, and
> evangelizing are just as important when you're starting a
> rebolution. How do we solve that problem?
1. Hire someone to coordinate the community to help writing the docs.
I'm sure most of the experts here are willing to help. The disadvantage
with this approach is speed and quality.
2. Hire someone to do the docs fulltime with you. Spend 4 weeks only on
this topic, don't do anything else. Than let the guy write the docs, and
make a 14 day review.
The main problem I see for RT is: Don't work on to many topics the same
time. Better finish/close some gaps fast. Everyone here isn't helped by
having all nice things done 50%... It's better to have some things done
100%.
But it has to professional! The people I know all say: "This tool is
very cool, but without docs, I can't bring it into companies!".
> So, this is probably a good time to move this topic off of
> this slowly updating email list and to something a bit more
> dynamic. Let's meet up in the AltME REBOL World and take it
> up from there...
I'm not that happy with this. I can better track the mailing list. And
by it's asynchron nature, people tend to better think before writing and
it' much more time effective to use the mailinglist. Robert
[15/30] from: robert:muench:robertmuench at: 11-Jul-2003 11:16
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 7>>
> NO: then, should we still do it for just a couple platforms,
> and say "sorry" to the rest?
Hi, let's face reality: Windows has 90 + someting % market. How much
effort is it to support the rest < 10% of the market? Will it cost RT to
invest 50+% to support< 10% additional market? I strongly suggest to let
those decision be driven by business thoughts only.
I know, that's not what technology addicted people like. I'm one of
those too but anyway, RT needs to make a living from all this!
Start with Windows, than Linux and than Mac. This decision has to be a
totaly emotionless and business driven. Carl, don't spend your time on
things that won't add to the commercial success of Rebol.
> I would like to see MM and 3D in REBOL. But, is it time for a
> split from one of the main themes of REBOL? Will the result
> help or hurt REBOL?
It will help. Let the market demand drive the development. And while we
are talking about it, I would even follow a different strategy:
Add the 3D and MM stuff for the SymbianOS platform FIRST and enter the
mobil entertainment market. ASAP, the window of opportunity is closing
for this and I see RT has a very good chance. Robert
[16/30] from: cyphre:seznam:cz at: 11-Jul-2003 12:08
Hi Carl and all folks on the list,
I completely agree with Robert's thoughts, ideas and recommendations. Maybe
a few more ideas...
Maybe we should see the MM version of Rebol as some extension to standard
Rebol products (core, view) - at least for the beginning.
1.The stadard View and core would be still "platform independent"(though it
is discutable in those days when latest official version of View(1.2) is
2years old and the latest experimental builds are for 2-3 platforms
available).
2. The group of "classic" users who wants to use Core and View for cgi,
neworking, simple reblets with simple GUI and not high-performace graphics
will be satisfied and their scripts will be working on all supportet
platforms as for today.
3. the second group of users who needs real MM support could download
special MM versions for few specific platforms (Win, Mac, Linux). BTW those
users don't usually need to have so wide area of multiplatfomness because
99% of commercially succesful MM aplications are developed on the above
mentioned platforms in the PC industry IMO.
4. Another idea how to decrase the "code differences" between those two
versions could be to add into classic View (almost)same set of grphical
functions like in the MM versions but use only HW independent rendering
engine for it so MM scripts could work also on classic View but with poorer
performance. Though I'm not sure if this "compatibility effort" could be
worth to do it...
5.Another question is to support different consoles and mobile devices. IMO
the best bussiness driven choice would be:
-PlaystationII in the gaming consoles area
-SybianOS in the mobile market(it beats all currently used systems ans all
big Mobile vendors(eg. Siemens..) who don't yet already have it on their
devices are switching to it)
Carl: "Will the result help or hurt REBOL?"
I think there is really no other way how to help Rebol. You made a great
language which can easily handle informations over the net...now we need to
SHOW the world this informations in a really atrractive and human intuitive
form.
What do you think about that?
regards,
Cyphre
[17/30] from: Al:Bri:xtra at: 11-Jul-2003 22:58
Carl wrote:
> Another thing, it's important to understand that some people decide to not
use REBOL for reasons other than lack of 3D, MP3, streaming video, etc. The
need for quality docs, examples, how-tos, articles, script archives, and
evangelizing are just as important when you're starting a rebolution. How do
we solve that problem?
By fixing all the Rebol versions and "equalising" the various versions. Have
a Rebol/Core or Rebol/Base that is the same for all platforms that Rebol HQ
intends to support. Fix all the bugs and put the Beta versions as standard
versions.
Have beta versions of Rebol that have regular bug fixes, and then cycle
those betas into the standard versions.
Have regular updates of Rebol, say, every week a bug is fixed and new
versions of Rebol are created. Just like Linux was apparently done in the
early days.
Once all versions of Rebol are the same across all platforms, then
documentation could be reasonably addressed. I think the equivalent of a
Wiki would be the best choice. That would allow users of Rebol to pose
questions, and for users of Rebol (like us) to suggest answers, and Rebol HQ
staff could leap in and write some thing different. :) Then we could all
progressively refine the wiki documentation as we come across spelling
errors, grammar errors, and clear up vague descriptions.
And if we could put the Rebol script library into a similar system, that
would be great as well. Though probably would be better to run this through
a Rebol application, like IOS but easier to use, as this could cause a lot
of trouble.
Andrew J Martin
Distributing the work...
ICQ: 26227169 http://www.rebol.it/Valley/ http://Valley.150m.com/
[18/30] from: petr:krenzelok:trz:cz at: 11-Jul-2003 13:04
Cyphre wrote:
>5.Another question is to support different consoles and mobile devices. IMO
>the best bussiness driven choice would be:
>-PlaystationII in the gaming consoles area
>-SybianOS in the mobile market(it beats all currently used systems ans all
>big Mobile vendors(eg. Siemens..) who don't yet already have it on their
>devices are switching to it)
>
OK, but I am not sure RT can do it without rethinking the strategy. I
remember someone stating that it was said by RT that current non-modular
architecture is partially a marketing decision. I don't know what can be
actually done in that situation - there is no simple conclusion. E.g.
IIRC Gabriele does not like the idea of one single rebolcore.exe and
e.g. view.dll, but the question is - can we affort core differences thru
all product lines? Does not it hurt rebol more than we think? Can we see
View running on Symbian powered devices? Eg. if I want to develop small
game, I don't care about VID - well - you can say - use SDK /Face then
... but I don't care about face effects either - I may want just basic
and fast blitting + having some few handy bitmap manipulation general
functions available. Of course I don't know how View internally works,
what is loaded into memory and what is not, but it has imo high memory
consumption to allow it to work on some nowadays mobile devices. Then we
have to ask ourselves - why do other technologies can do it, but we can't?
I think that we can't live with the idea of all-in-one-exe forever.
Because - it just means - compromises. And as Robert said - I etiher
need fully working feature X, or if not fully implemented, it is useless
to me anyway. But then others will cry, that my requested feature bloats
rebol, because other don't need it. But we all come from different
fields and we all would like to see rebol succeed in different areas -
so who decides what goes in and what does not? Plug-ins - they don't
necessarily mean .dll hell - we have script rebol header, it contain
'needs field, we can have automatically downloaded versions. As for me I
would prefer that situation instead of - "uh, you need View x.y.z,",
Uh, Command contains old core and that function is not available
etc.
What is more - each single change in Veiw means you download whole exe.
That is not necessary - we know better.
Look at following white-paper - new Tao Intent2 - those sound
capabilities - clean design - plug-ins - it is capable to be running in
120KB of ROM and 32KB of RAM! Judge for yourself ...
http://tao-group.com/news_events/resources/logos/images/intent 2
Overview_2.pdf
It is not flaming nor critique - I just try to fight my position - you
know I was always after more granular aproach to rebol - if you don't
like it, you can over-vote me :-)
Anyway -it will be interesting to see, what Carl thinks is the right
technological future for REBOL!
Cheers & friendly,
-pekr-
[19/30] from: Al:Bri:xtra at: 11-Jul-2003 23:30
Petr wrote:
> Look at following white-paper - new Tao Intent2 - those sound
capabilities - clean design - plug-ins - it is capable to be running in
120KB of ROM and 32KB of RAM! Judge for yourself ...
pekr's link was a little bit broken. Here's a better one:
http://tao-group.com/news_events/resources/logos/images/intent 2 Overview_2.pdf
Andrew J Martin
ICQ: 26227169 http://www.rebol.it/Valley/ http://Valley.150m.com/
[20/30] from: robert:muench:robertmuench at: 11-Jul-2003 13:37
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 10>>
> progressively refine the wiki documentation as we come across
> spelling errors, grammar errors, and clear up vague descriptions.
Hi, the Wiki might be OK to collect information but it's not an option
for the offical documentation. This needs to be release by RT in a
professional form. Robert
[21/30] from: robert:muench:robertmuench at: 11-Jul-2003 13:37
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: Multimedia REBOL... yes or no?
> so who decides what goes in and what does not?
RT does, and hopefully by a market (and than demand) driven decision.
> What is more - each single change in Veiw means you download
> whole exe. That is not necessary - we know better.
No problem with the current EXE size.
> It is not flaming nor critique - I just try to fight my position - you
> know I was always after more granular aproach to rebol - if you don't
> like it, you can over-vote me :-)
Petr, we know this ;-)) That's why I always try to go down to real life
first. Robert
[22/30] from: Al:Bri:xtra at: 11-Jul-2003 23:55
Petr wrote:
> remember someone stating that it was said by RT that current non-modular
architecture is partially a marketing decision. I don't know what can be
actually done in that situation - there is no simple conclusion.
I think I suggested something like this some time ago.
What about componentising Rebol, and offering prepacked "lumps" of Rebol?
For example:
Base
Networking(Core)
Image stuff (as in Rebol/View and IOS)
VID script
IOS script
Then:
Rebol/Base = Base
Rebol/Core = Base + Networking
Rebol/View = Base + Networking + Image + VID
Rebol/IOS = Base + Networking + Image + VID + IOS.
Then when I need to manipulate images as part of a CGI and web browser
project (for example making a graphic logo in .png format), I could assemble
Base + Core + Image together.
This would also make it easier to expand Rebol in the future; just add
another module.
Andrew J Martin
Just my thoughts...
ICQ: 26227169 http://www.rebol.it/Valley/ http://Valley.150m.com/
[23/30] from: Al:Bri:xtra at: 12-Jul-2003 0:00
Robert wrote:
> the Wiki might be OK to collect information but it's not an option for the
offical documentation. This needs to be release by RT in a professional
form.
I agree. A Wiki is an excellent tool to capture information from the
designer of Rebol, through the gurus, masters and novices of Rebol. Then
this information on the wiki can be "poured" into a printed page by a
technical writer, and lots of trees can be cut done and we can make books
with this information in it. :) :D
Andrew J Martin
ICQ: 26227169 http://www.rebol.it/Valley/ http://Valley.150m.com/
[24/30] from: g:santilli:tiscalinet:it at: 11-Jul-2003 14:11
Hi Petr,
On Friday, July 11, 2003, 1:04:50 PM, you wrote:
PK> IIRC Gabriele does not like the idea of one single rebolcore.exe and
PK> e.g. view.dll,
It's not that I don't like the idea, it's that it can cause more
problems than it solves. Anyway, I don't think this is the real
problem right now.
As I said on AltME, what we really need to understand is what the
final goal should be. If we know the goal, we can then choose the
path to reach it.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[25/30] from: petr:krenzelok:trz:cz at: 11-Jul-2003 15:05
Gabriele Santilli wrote:
>Hi Petr,
>
>On Friday, July 11, 2003, 1:04:50 PM, you wrote:
>
>PK> IIRC Gabriele does not like the idea of one single rebolcore.exe and
>PK> e.g. view.dll,
>
>It's not that I don't like the idea, it's that it can cause more
>problems than it solves.
>
Then you would have to elaborate a bit (well, not here, sometimes,
somewhere, on AltME e.g.), but it contradict the current state of
industry - everybody uses plug-ins ...
> Anyway, I don't think this is the real
>problem right now.
>
>As I said on AltME, what we really need to understand is what the
>final goal should be. If we know the goal, we can then choose the
>path to reach it.
>
I didn't say otherwise. Carl wanted to collect ideas and opinions, so I
took my right to say what I think would benefit rebol. I also said that
it will be interesting to see Carl's conclusion of all this, because
he's the driving force ...
Cheeers,
-pekr-
[26/30] from: robert:muench:robertmuench at: 11-Jul-2003 16:52
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 13>>
> Rebol/View = Base + Networking + Image + VID
> Rebol/IOS = Base + Networking + Image + VID + IOS.
Try explaining this in an elevator test to a customer that wants to use
Rebol technology. I bet you won't be able. If the possible customer
isn't able to understand it in less than a minute I'm sure you won't
make a deal. Robert
[27/30] from: pwoodward:cncdsl at: 11-Jul-2003 11:05
Hrm -
Multimedia in Rebol, with "rich" media? What about the following idea?
View/Pro allows access to libraries on the host system. Under Windows there
are a bunch of SDKs/APIs for media: MCI, DirectShow/DirectPlay, and even
the Windows Media Player. I suspect that other platforms may have similar
approaches (Amiga - Multiview for instance). What about creating an
Abstract interface within REBOL that describes a core, common set of media
functions that can be supported by interfacing with these libraries?
You want to play an MP3, or Audio from a CD-ROM? Stuff like that should be
possible on just about any system. Of course, you'll face the same problem
Java does once you start to link it with native code - you begin to lose
portability, or at least increase requirements on the underlying system to
have certain things installed.
But, assuming a core set of "REBOL/Media" API calls that could be back-ended
by native code, there's no reason that couldn't be an interim solution,
eventually replacing the function call-outs with native (REBOL)
functionality.
- Porter
[28/30] from: maximo:meteorstudios at: 11-Jul-2003 12:00
If modularization is complex, then why is python getting more and more support ... python
is a module nightmare. I think rebol contains about 90% of python's more generic modules
... but in one file ... I like that.
Python does have HIGH-CLASS docs and docs searching. Which makes it easier to use by
newbies.
leave view for faces, but don't build someghing on top of it ... go under it. insert
a layer in between which we could tap and get performance.
I'd rather have a new REBOL|GFX which has better raw capabilities, like someone suggested,
removing most of the face facets like text, and adding many low-level stuff like a high
speed draw dialect (direct OpenGL calls?) and garanteed 60fps refresh rate of computed
faces.
In a way, I feel Carl's pain. I also want steel to benefit the community, but rebol
is used for such a wide array of coding styles that its quite hard to appeal to the majority.
I am trying to build steel as a modularised system. I am also trying to keep the modules
rather focused and all-encompassing. The tradeoff in end programs is memory consumption,
but There is more appeal, because its simpler to start coding when you only have 5 or
less libs to load. If I start separating each object, each style and each little utility
as a small library, its going to be harder for others to approach. In the end they'll
probably load them anyways... so its no point...
I remember the joy of using the amigas librairies, because it was clean and clear. most
librairies did one thing and did ALL of it. so you'd never really load more than, say
10, librairies.
-max
[29/30] from: antonr:iinet:au at: 12-Jul-2003 1:49
I think the trick is to try to "hide"
Rebol/Base /Core behind Rebol/View and /IOS.
The distributions with everything in them are
for non-tech newbies who want everything to work
first time. Rebol/Base and /Core are more for programmers.
So I think the RT website (and our websites)
should stress more the bigger "all in one"
distributions - that is, on first glance, "rebol"
appears to be at least rebol/view. On further inspection,
the interested developer will find out that there are
other distributions that can meet special needs.
Anton.
[30/30] from: robert:muench:robertmuench at: 12-Jul-2003 15:01
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 7>>
> for non-tech newbies who want everything to work
> first time. Rebol/Base and /Core are more for programmers.
Hi, that's a good approach. Start with making everyone live easy. If
people get used to it, they will understand the other options. But don't
throw everything at them in the first move. Maybe the site should be
split into: Normal Users, Expert Users, Programmers. The approach to get
convidence of each group is very different. Robert
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted