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