World: r3wp

I see no reason, why you can't make 3d games using OpenGL together 
with REBOL.  Eve Online is made with Python: http://www.eve-online.com/

Cyphre does even parallax scrolling (beast demo)

the trouble was definitely with keyboard not supporting keyup events 
...

and not sure we are able to detect multiple keys pressed?

humm. well how much of REBOL would we really be using in an OGL game 
with proper key support... none of view... so basically core with 
a huge stub over OpenGL and native event handling.

I've always assumed that Rebol just wasn't good enough which is why 
we only had demos and no games.

exactly what I am trying to demystify properly.

I've assumed a lot of that too... but with the current next wave 
of computers and their min 1GB ram...  it seems to me that REBOL's 
RAM hungry-ness is becoming less and less of an issue.

I've been thinking about a game dialect in REBOL for a few years 
now. An abstraction layer, that is perfect for the programming problems, 
you're faced with in game development. Maybe it could even output 
C++ source, if more speed is needed.

(demystify in the sense that I am trying to find the proper causes... 
not that I am trying to tell anyone anything)

A dialect could also produce rebcode, and that would be fast enough 
in most cases.

yes... I think we all need to scream loud enough for rebcode to be 
included in 2.7 (in all distros)

really... I think the community should stand as one and demand this 
feature.

whatever is buggy can be left out... whatever is stable will already 
be enough.  IIRC brian was part of the whole process and was confident 
that very little needs to be done to make the current cut a viable 
part of REBOL.

and what a power feature that would be... I am almost certain that 
a fair amount of mezz code will be ported to rebcode by a few of 
us.

and the implications for gaming ARE quite obvious.

WE WANT REBCODE !!!   ;-)

:)

darn Cyphre's arcadia breaks under 2.7

you will got your rebcode, as well as new object model = faces more 
resource savy ... and new gobs (graphics objects), resource savvy 
too ... what you will also get is - faster blitting and access to 
buffers (not sure i understand it correctly), but surely plug-ins 
for View ...

not in R3  in 2.7 we can play with this NOW... no need to wait a 
year.

Pekr, I already got my own Grapihcs objects which have classes are 
are resource savy... did you check out regraph?

Maxim - play with what you want, some things you just can't fix ....

I did an engine to play NIM:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=nim-engine.r
It plays the game at the console prompt.

But I never got around to adding a View front end --- feel free any 
one.

rebview http://88.198.15.226/istaba/game.r

If you run out of  bandwith while downloading or memory, somewhat 
 impressive

Lots of games on the ML:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-topic-index.r?i=games

if you dont, of course

exactly, I can't fix 2.7 myself, but since RT is making updates and 
rebcode was part of the 2.X code branch... it obviously can be compiled 
back in.

would still prefer dlls free

Maxim - and my opinion is that we have to decide - either stop bothering 
Carl with old stuff, or getting R3 sooner. Carl is full-time on R3 
.... so ...

Carl is affraid of a few bugs and seems stressed about stability... 
 a part from closing any security issues rebcode might be an evening's 
work (maybe two ?)

wishlist: laarge images seem to break gc, betterkey-supportwould 
 be nice, async"chat".

Not many games in the Library

I don't know where I put it, but I once built a detailed checklist 
of functions we would build for each game platform we worked on. 
 I designed the game interface for WebTV, which also did not have 
Key Up.

The basics are:


Input: Key up, and at least 3 simultaneous key overlap.  This is 
needed because during actual game place, people will press directional 
and fire buttons at the same time.


Video: Double buffer - triple buffer is better.  Without this, one 
needs to know where the beam is (called beam tracing) so that rendering 
happens on the sync.


Threading:  It is very difficult to write a game in a single thread. 
 At the very least it needs to be able to trigger functions.


Sound: Sounds need to be started, stopped, and volume changed on 
the fly.  Multiple channels (4 minimum) for a full experience.

large images like what size?  I had a 10000x800 image a while back 
which scrolled nicely and seemed to behave... but maybe I didn't 
check the RAM.

3kx3k IIRC

thanks Reichart... exactly the kind of data I wanted... obviously 
some of this is currently impossible.  :-(

just looking at my kid... playing a scrolling plane game... in 2 
minutes he figured out the random generator... so banked his plane 
at the far top of the screen and multiplied his high-score by 10 
 :-)  hehe

he's 4 years old :-)

This is why Rebol is not a possible game platform for us.  It is 
fine for games roughly like those written for the Apple II.

directional+fire: ctrl, shift

Rebol is however a GREAT scripting system for games.

using timers we can analyse the input events and trigger our own 
filtered events... but that is not very nice

(nice as in fun to do)

although it would work.

Probably, the best thing is to write a C library to provide the bse, 
then write the game in Rebol.

bse = base

yeah, just using a vast amount of stubs.

hmm, we could also wrap SDL, no?

that is the whole platform for multimedia - surely not the best one, 
but universal ... but then - is it rebol? :-) There would be Core 
underneath and no View ...