[OLPC-Games] Res: Games Digest, Vol 5, Issue 14
Daniel Monteiro
daniel_on_go at yahoo.com.br
Mon Jun 25 14:38:49 EDT 2007
Good to see there's lots of work on this for XO ;-D
My work, actually, works with full 800x480 (on the nokias) and I guess I will shot for the full 1200x900 that I saw on some specs elsewhere.
Im not aiming for Quake-esque graphics and speed, but a more clean (and probably slower) experience. I want the kids (and maybe the teachers) to be able to create myst-like adventures RIGHT ON THE MACHINE. And thats what I got. My rendering system doesnt need pre-prossessing and allows dynamic scenes.
Ok, for good graphics, you need to subdivide the sceneario. but Im not doing this way right now. Im importing a "cloud" of voxels (made with a open source Command & Conquer voxel editor a friend of mine created , that works nicely under wine), so the graphics are blocky and unoptimized, but works and constitute a good "worst case" (no play of words meant).
Im also not putting greats efforts on texture mapping. I will eventually do it, but its not my main concern. Gameplay and easiness of content authoring is.
For my current state of works , think of Driller/Space Station Oblivion (http://en.wikipedia.org/wiki/Driller_(game)).
Eventually, some action games can be made (as Im creating a tron racing game right now) but its not what it is meant for.
And speaking of naive rendering algorithms, I get the "Little Red Riding Hood" trophy for the most naive , silly , crude rendering algorithm of the mailing list. \o/
[]s
Daniel Monteiro
========================================
|_|0|_| Linux Registered User #424188
|_|_|0| http://corporatedrones.wordpress.com
|0|0|0| http://nomadsoul.wordpress.com ========================================
----- Mensagem original ----
De: "games-request at lists.laptop.org" <games-request at lists.laptop.org>
Para: games at lists.laptop.org
Enviadas: Segunda-feira, 25 de Junho de 2007 13:00:02
Assunto: Games Digest, Vol 5, Issue 14
Send Games mailing list submissions to
games at lists.laptop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.laptop.org/listinfo/games
or, via email, send a message with subject or body 'help' to
games-request at lists.laptop.org
You can reach the person managing the list at
games-owner at lists.laptop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Games digest..."
Today's Topics:
1. Re: Res: Games Digest, Vol 5, Issue 12 (NoiseEHC)
2. Re: Res: Games Digest, Vol 5, Issue 12 (Antoine van Gelder)
3. Re: Res: Games Digest, Vol 5, Issue 12 (Daniel Monteiro Basso)
4. Re: Res: Games Digest, Vol 5, Issue 12 (Kent Quirk)
5. Re: Res: Games Digest, Vol 5, Issue 12 (NoiseEHC)
6. Re: Res: Games Digest, Vol 5, Issue 12 (NoiseEHC)
----------------------------------------------------------------------
Message: 1
Date: Mon, 25 Jun 2007 12:50:00 +0200
From: NoiseEHC <NoiseEHC at freemail.hu>
Subject: Re: [OLPC-Games] Res: Games Digest, Vol 5, Issue 12
To: Games for the OLPC <games at lists.laptop.org>
Message-ID: <467F9DD8.5060108 at freemail.hu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi!
I am currently working on a 3d renderer, and once I will get a telnet to
an LX-700 machine I will be able to tell you some numbers what speed
could you expect from my implementation. The problem with the TinyGL
implementation is that it is using a quite naive rendering algorithm so
probably it is not the best match for the XO. (And not only you can do
more with an optimized one but the same thing will consume less power.)
The problem with a BSP tree is that it took 30 min to calculate a Quake
level (when it was released, probably less now on a Core2 Duo), and it
does not support overlapping polygons. So if you want to use a dynamic
scene you are left with an octree and a Z buffer. (You cannot expect
activity writers to correctly preprocess everything so you have to do it
in the renderer.)
So my plan is, if you are interested in:
The minimum target is 400x300x30fps, solid/texture mapped/gouraud shaded
objects, probably lighting will only work with Y (if it is rendered onto
an YUV surface).
The client program (game or activity) creates 3d objects in Python then
call render and that's all. The fact is that we cannot expect activity
writers to implement a good scene manager for OpenGL, and no good scene
managers are optimized for software rendering. My goal is that the
renderer should work without any deeper 3d knowledge from the client
program's developer.
Implementation plan:
The rendering engine uses hand optimized 3dnow/MMX for drawing
trapezoids (a triangle is a special trapezoid). I suspended this
development since I need a real processor to test the cache hierarchy so
there is no point tuning it further without real data. (It is currently
a .NET program with a Geode simulator which can draw texture mapped
triangles.)
The rendering happens in two passes. In the first pass, all triangles
which are potentially visible in a scanline are pushed into a compressed
Z-buffer. Compressed means that if a span (8 or 16 pixels) of the
scanline is inside the appropriate scanline of a triangle then no Z
values will be calculated and the span will be handled as one big pixel.
In the second pass the actual rendering occurs (by pixel or by span) and
it guarantees that every pixel will be set only once (no alpha support
initially). The Z-buffer for a scanline will fit into the L1 cache so
hopefully it will be very fast.
The tricky part is the scene manager which integrates culling,
occlusion, transformation and triangle setup (currently it is just a
plan, I have no working code for it). The objects are stored in a loose
octree and in the first pass every visible cube of the octree is put
into the trapezoid list as maximum 2d bounding boxes (so they are
projected into view as a rectangle). In the first pass of the scanline
rendering, if there is an unprocessed bounding box requiring drawing
then it is further processed (so in an octree the sub cubes are
transformed into the trapezoid list or in case of object bounding boxes
the objects are transformed and skinned). That way we get occluders
without specifying them so if some character is not visible because he
is occluded by a wall then its geometry will not have to be processed at
all.
Advantages:
I cannot imagine anything faster and easier to use.
Disadvantages:
Not finished, will take months to implement. Not compatible with legacy
OpenGL apps.
What do you think about it?
Daniel Monteiro wrote:
> Hi Daniel
> Very tiny indeed.
> We spoke before , about 4 years ago, when I translated (poorly) the
> SDL_Intro document to portuguese.
>
> BZK is not using Z-Buffer as it may be not suitable for slow devices
> with big screens (Nokia 770);
> Neither Im using BSP , but a higly modified painter's algorithm. Its
> not something easy to describe , as Im still working it as my
> gradutation thesis.
> Well..to best sumarize it: its like a portal rendering using a K-d
> Tree. Why not Z-Buffer? some plataforms like Symbian OS dont give me
> acess to a large buffer like the one needed by Z-Buffer , but only to
> cointainers. (well, that changed recently...but BZK is older than that
> and the devices that support this are the high end only)
>
> This TinyGL maybe be a good solution for BZK on the XO indeed.
> although I dont really like much OpenGL and the BZK render is only
> half compatible...maybe we can work on this...
>
> About the floating point. Im about to make it only optional (activated
> on compile time), as the new nokia device (N800) has a good FPU too.
>
> []s
>
> Daniel
>
> -----------------------------------------------------------------
> Wow, that's surely a tiny world! A guy with almost the same name as
> mine, that lives in the same country as me, that codes in C++ and do 3D
> programming!
>
> I only sent a message to the devel list, so I'll take the opportunity to
> announce here too: I'm adapting a software renderer implementation of
> OpenGL (TinyGL, by Fabrice Bellard), suitable to be run on the XO.
> Currently it runs the gears demo in fullscreen (actually rendered to a
> 256x256 framebuffer) at 50 fps.
>
> I hope to be able to execute my robotics simulation framework in the XO,
> but there is still a lot of work to be done. You can take a look at what
> I've already accomplished at:
>
> http://www.basso.inf.br/phi/ (check the gallery, it's old but nice :)
> http://www.lec.ufrgs.br/~dmbasso/phi/doku.php
> <http://www.lec.ufrgs.br/%7Edmbasso/phi/doku.php> (last stable version)
>
> About BZK: does it use BSP for occlusion culling? TinyGL uses a
> z-buffer, but I suspect a BSP-tree would perform better. The Geode's
> floating point is very fast, so BZK's fixed-point is not really an
> advantage on the XO.
>
> []'s
>
> Daniel
>
> ------------------------------------------------------------------------
> Novo Yahoo! Cad?? <http://yahoo.com.br/oqueeuganhocomisso%20> -
> Experimente uma nova busca.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Games mailing list
> Games at lists.laptop.org
> http://lists.laptop.org/listinfo/games
>
------------------------------
Message: 2
Date: Mon, 25 Jun 2007 13:31:44 +0200
From: Antoine van Gelder <hummingbird at hivemind.net>
Subject: Re: [OLPC-Games] Res: Games Digest, Vol 5, Issue 12
To: Games for the OLPC <games at lists.laptop.org>
Message-ID: <467FA7A0.8050901 at hivemind.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
NoiseEHC wrote:
> Disadvantages:
> Not compatible with legacy OpenGL apps.
A long long time ago it meant a lot more for me to be able to render a
untextured, unlit, wireframe cube on my Commodore 64 than the fact that
it wasn't an OpenGL cube with hardware shaders.
Standards and hardware accel are for adults who are trying to
cost-optimize a product development cycle for products that rely on
bling rather than gameplay to remain competitive.
Last time I checked the XO is being developed for kids.
So go ye forth and writest the software renderer thouest wishest thou
had when thee were 12 years old dammit!!
:-D
- antoine
--
"Any organization that designs a system (defined broadly) will produce a
design whose structure is a copy of the organization's communication
structure."
- Melvin Conway
------------------------------
Message: 3
Date: Mon, 25 Jun 2007 10:12:10 -0300
From: Daniel Monteiro Basso <daniel at basso.inf.br>
Subject: Re: [OLPC-Games] Res: Games Digest, Vol 5, Issue 12
To: Games for the OLPC <games at lists.laptop.org>
Message-ID: <1182777131.27714.16.camel at maya>
Content-Type: text/plain; charset=utf-8
Em Seg, 2007-06-25 ?s 12:50 +0200, NoiseEHC escreveu:
> The problem with the TinyGL
> implementation is that it is using a quite naive rendering algorithm so
> probably it is not the best match for the XO.
Probably true, but at least it already exists... ;)
> The problem with a BSP tree is that it took 30 min to calculate a Quake
> level
Yep, that's true. I said that recalling some fuzzy demoscene memories,
where I saw 64k demos doing amazing 3D stuff, and listed in the features
was the "realtime bsp rendering", but it was refering to the static
landscape... stupid me.
> So my plan is, if you are interested in:
...
> What do you think about it?
Great! I hope you succeed coding that, it'll be a lot of work. I'm not
sure how much I'll be able to contribute directly, but at least I'll try
to test it. The same goes to BZK. And while both are not ready, I'll
continue my work on TinyGL.
[]'s
Daniel M. Basso
------------------------------
Message: 4
Date: Mon, 25 Jun 2007 09:32:37 -0400
From: Kent Quirk <kent_quirk at cognitoy.com>
Subject: Re: [OLPC-Games] Res: Games Digest, Vol 5, Issue 12
To: Games for the OLPC <games at lists.laptop.org>
Message-ID: <467FC3F5.6050505 at cognitoy.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Antoine van Gelder wrote:
> NoiseEHC wrote:
>
>> Disadvantages:
>> Not compatible with legacy OpenGL apps.
>>
>
>
> A long long time ago it meant a lot more for me to be able to render a
> untextured, unlit, wireframe cube on my Commodore 64 than the fact that
> it wasn't an OpenGL cube with hardware shaders.
>
> Standards and hardware accel are for adults who are trying to
> cost-optimize a product development cycle for products that rely on
> bling rather than gameplay to remain competitive.
>
> Last time I checked the XO is being developed for kids.
>
> So go ye forth and writest the software renderer thouest wishest thou
> had when thee were 12 years old dammit!!
>
> :-D
>
> - antoine
>
>
On this platform, no application written for hardware accelerated GL is
going to render fast enough to be useful anyway.
Looks like what you're saying is that you're going to write a scene
graph renderer, and let Python app developers define 3D objects and
insert them into the scene graph. Seems like the rendering API is going
to basically include defining objects, moving them around, and moving
the camera around.
That sounds great.
Are you intending for collision detection to be part of the system? How
about physics? (Both would probably require a simplified object model --
spheres or boxes -- on this platform).
Kent
--
------------------------------------------------------------
Kent Quirk I'm making a game about global warming.
Game Architect Track the progress at:
CogniToy http://www.cognitoy.com/meltingpoint
------------------------------
Message: 5
Date: Mon, 25 Jun 2007 16:22:02 +0200
From: NoiseEHC <NoiseEHC at freemail.hu>
Subject: Re: [OLPC-Games] Res: Games Digest, Vol 5, Issue 12
To: Games for the OLPC <games at lists.laptop.org>
Message-ID: <467FCF8A.7040008 at freemail.hu>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
> Great! I hope you succeed coding that, it'll be a lot of work. I'm not
> sure how much I'll be able to contribute directly, but at least I'll try
> to test it. The same goes to BZK. And while both are not ready, I'll
> continue my work on TinyGL.
>
>
>
Thanks, so I will have at least one beta tester... :)
Using TinyGL until you can beta test something however the most sane
thing I can think of so I would advise that too. :)
------------------------------
Message: 6
Date: Mon, 25 Jun 2007 16:36:02 +0200
From: NoiseEHC <NoiseEHC at freemail.hu>
Subject: Re: [OLPC-Games] Res: Games Digest, Vol 5, Issue 12
To: Games for the OLPC <games at lists.laptop.org>
Message-ID: <467FD2D2.8060505 at freemail.hu>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
> Looks like what you're saying is that you're going to write a scene
> graph renderer, and let Python app developers define 3D objects and
> insert them into the scene graph. Seems like the rendering API is going
> to basically include defining objects, moving them around, and moving
> the camera around.
>
What I am doing is a renderer which requires an integrated scene graph
so it can get occlusion culling for free. It is just a side effect that
from python you will only be able to access objects so there will not be
a Vertex class exported to python (only SetVertex, etc). But yes, what
you are saying is basically correct.
> That sounds great.
>
> Are you intending for collision detection to be part of the system? How
> about physics? (Both would probably require a simplified object model --
> spheres or boxes -- on this platform).
>
> Kent
>
>
In the first version I will be happy if I will be able to code this
thing so at least somebody could create animations using it. After all
an animation would take much less space than a video. In that version I
will most likely implement picking since it is one of the nontrivial
things. The next thing will be supporting physics that you at least not
fall through the floor. Then who knows, we are at 2008 now...
If this project takes off then the goal is that the system should
support everything that is needed for a game and can be implemented in
the given hardware constrains because I think that most activity (game)
writers will have less knowledge than John Carmack... :)
------------------------------
_______________________________________________
Games mailing list
Games at lists.laptop.org
http://lists.laptop.org/listinfo/games
End of Games Digest, Vol 5, Issue 14
************************************
____________________________________________________________________________________
Novo Yahoo! Cadê? - Experimente uma nova busca.
http://yahoo.com.br/oqueeuganhocomisso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/games/attachments/20070625/52e60ad4/attachment-0001.htm
More information about the Games
mailing list