| # | User | Message | Date |
| 102 | Gerard | Nevertheless I'm very optimistic fo your goal reach. Keep up the good work ! | 18-Dec-09 1:10 |
| 101 | Gerard | http://lambda-the-ultimate.org/node/3070 | 18-Dec-09 1:08 |
| 100 | Gerard | http://ai.uwaterloo.ca/~vanbeek/Constraints/Papers/LutterothSW08.pdf | 18-Dec-09 1:08 |
| 99 | Gerard | HiMaxim. Seems very promising. If never you can't put it to tis intended speed and you have to reconsider some tuning, here are 2 links to some recent material about new GUI Layouts models : | 18-Dec-09 1:08 |
| 98 | Maxim | fyi, scream will be the basis for some commercial work which I will be doing in the next few months, so it will evolve quickly and be ported to R3 when interactive OpenGL becomes possible. | 22-Nov-09 5:46 |
| 97 | Maxim | for the record.... I haven't touched scream for weeks! ... I just decided to have a little fun with it today, and managed to finish the basic framework. | 22-Nov-09 5:34 |
| 96 | Maxim | can't wait to be playing around with texture mapping and shading :-) | 22-Nov-09 5:32 |
| 95 | Maxim | quick update... I'm finally able to render a 3D cube using AGG within scream with the whole scene framework in place :-)
right now I'm working on adding a few capabilities to the AGG renderer itself, like point and facet depth sorting. this is all built using a scene graph and derived generic components which are either liquid nodes or basic rebol objects. viewport -> rendering-engine -> scenes -> manipulators -> objects -> deformers -> primitives -> shapes -> points The inputs which generate or interact with primitives, manipuators, deformers or shapes are external to the rendering engine, so the same application can basically render in any rendering extension which is linked to scream. and I'm doing above 20 frames a second right now :-) | 22-Nov-09 5:29 |
| 94 | Maxim | above all, I want this project to be fun, and I think the naming convention of the modules helps in promoting that. | 3-Nov-09 1:57 |
| 93 | BrianH | Eye of the beholder and all that :) | 3-Nov-09 1:51 |
| 92 | BrianH | This is exactly the kind of naming convention that would appeal to game designers, the target market for this project. | 3-Nov-09 1:50 |
| 91 | Maxim | as I said earlier, the names are only for the modules, the code inside is actually as close to academia as possible. I have been looking up wikipedia a lot to be sure I use the best names... even for simple things like comments. | 2-Nov-09 23:00 |
| 90 | AdrianS | I kind of agree with Robert - just keep it "boring", Maxim | 2-Nov-09 17:48 |
| 89 | Pekr | Robert - life-insurance called R.I.P. is kind of cool idea :-) | 2-Nov-09 15:49 |
| 88 | Robert | It's like naming a life-insurance: RIP | 2-Nov-09 15:48 |
| 87 | Robert | This is a good showcase for "how to torpedo your good product with awkward naming"... keep going Max. | 2-Nov-09 15:47 |
| 86 | Maxim | a lot of new intersting code for REBOL is coming out of scream. I just finished a bitmask management object. it allows you to enumerate, define, and store bitwise flags. you can then set/clear/toggle bits and do bit-wise comparisons using flags your added to the object. a nifty aspect of the object is that it calls a user defined action whenever a bit set/clear/toggle is attempted, and you actually control what happens to the bits, so you can do stuff like pair up a few bits on clear but leave them as-is on set. the value is an integer, so the manipulations are (relatively) fast. because you can define bitmask flags as you wish, a flag might compare several bits at one. bitmask comparisons include: any? all? none? missing? | 1-Nov-09 14:50 |
| 85 | Pekr | what is so funny here? Just throwing some words to the game :-) | 1-Nov-09 8:25 |
| 84 | shadwolf | told you Pakr was a God level in jokes ... | 1-Nov-09 8:11 |
| 83 | Maxim | but DEVIANT ... hahha such a nice play on ... DEV I AIN'T ;-) | 1-Nov-09 8:11 |
| 82 | shadwolf | Pekr is the strongest joke kung fu master i ever seen ... | 1-Nov-09 8:10 |
| 81 | Maxim | was thinking of ANGER ;-) | 1-Nov-09 8:10 |
| 80 | shadwolf | Pekr killed me laught to tears .... | 1-Nov-09 8:10 |
| 79 | Pekr | Bug testing tool - DEVIANT :-) | 1-Nov-09 8:09 |
| 78 | Maxim | it also make error message really funny :-) providing a bit of comic relief to programming ;-) ex: >> enum-flags [one two three] ** User Error: %CURSE/enum(): .one Is already defined | 1-Nov-09 8:08 |
| 77 | Maxim | (there was some logic to this ;-) | 1-Nov-09 8:05 |
| 76 | Maxim | you instantly know if you are using a module or data. | 1-Nov-09 8:04 |
| 75 | Maxim | we see that the actual game data is properly named... but the modules are VERY easy to make out from the code, which is the main reason for this. | 1-Nov-09 8:04 |
| 74 | Maxim | wrt code using scream.. this is code take from Malice: current-map: make terror/!map [ init] current-map/set-playfield context [start: -100x-100 end: 100x100] | 1-Nov-09 8:03 |
| 73 | Maxim | (Ogre is a game oriented 3D HAL which uses OpenGL or DirectX) | 1-Nov-09 8:01 |
| 72 | Pekr | ogre, gore - sounds good :-) | 1-Nov-09 8:01 |
| 71 | Maxim | or any implementation to OGRE | 1-Nov-09 8:00 |
| 70 | Maxim | GORE could be a really nice name for the OpenGL !HORROR module | 1-Nov-09 8:00 |
| 69 | shadwolf | well at least i will enjoy ready the first laugh to tears documentation ever done for a programming tool ... | 1-Nov-09 8:00 |
| 68 | Maxim | one thing to note is that the ACTUAL DATA SETS HAVE NONE OF THESE COLORFUL NAMES. this is just for the module names themselves | 1-Nov-09 7:59 |
| 67 | shadwolf | sorry ... | 1-Nov-09 7:59 |
| 66 | shadwolf | the look of your tool set documentation is going to be such a laugh ..... | 1-Nov-09 7:59 |
| 65 | Maxim | obscene data creates terror, shown in horror/view | 1-Nov-09 7:58 |
| 64 | Pekr | and for a hard-core stuff, probably for some peformance testing tool - GORE, FATAL, GRIND | 1-Nov-09 7:58 |
| 63 | Maxim | :-D that is sooooooooo nice... thanks !!! never would have tought about it | 1-Nov-09 7:57 |
| 62 | Pekr | for the layout scene editor, you could as well use OBSCENE | 1-Nov-09 7:55 |
| 61 | Maxim | doh... just reread .... My brain crossed the words terror and torture ... LOL | 1-Nov-09 7:23 |
| 60 | Maxim | and terror/area is nice in code ;-) | 1-Nov-09 7:10 |
| 59 | Maxim | but PAIN is my list of eventual monikers for new modules ;-) | 1-Nov-09 7:10 |
| 58 | Maxim | torture (as a word) was as close to terrain as any word in this line of thinking. (easier to remember what it does :) | 1-Nov-09 7:08 |
| 57 | shadwolf | istead of toture .... | 1-Nov-09 7:04 |
| 56 | shadwolf | what about PAIN ? | 1-Nov-09 7:03 |
| 55 | Maxim | just added CURSE module to SCREAM ... hehe it has all the core reusable code. | 1-Nov-09 7:01 |
| 54 | Maxim | its just just fun to type horror/scene in code :-) | 1-Nov-09 5:46 |
| 53 | Maxim | I'll keep torture for the AI IDE :-) | 1-Nov-09 5:43 |
| 52 | Maxim | DESPAIR is a good name for that module... I can just see someone with his eyes in the air, sighing, dropping his arms... :-) | 1-Nov-09 4:45 |
| 51 | Maxim | damn... TORTURE !!! wow that is exactly the name I was looking for!! right now its called MALICE :-) | 1-Nov-09 4:44 |
| 50 | Cyphre | Max, LOL. I think you are missing at least two more: DESPAIR - import/export module so artists can really use it TORUTRE - wysiwyg editor/IDE | 31-Oct-09 17:18 |
| 49 | Rebolek | Max, you do it just for the names, yes? ;) | 31-Oct-09 12:27 |
| 48 | Maxim | renamed this group so it incorporates the complete project which is beyond only 3D rendering... its a complete game architecture... the current framework is defined and started implementation as: !SCREAM - the whole package will include test tools, content creation, stand-alone AI simulation environments, etc. documentation and reference documents are managed at this level. !TERROR - High-level map management area, bodies, and terrain... basically a module to describe the world and provide logical control over it indenpendently of what renders it out. !FEAR - Fully Environment Aware Reasoning... An attempt at a run-time adaptable AI. fear works by sensing !TERROR and reacting to it, by manipulating !TERROR data directly. its decision-making process is totally independent of the structure, so you can basically use fear to implement different styles of AI. Even mix and match them. !SCARE - Scene Control And Rendering Engine Low-level 3D representation of !TERROR data. Converts/manipulates primitives into points & surfaces. Also responsible for all the transformations and polygon deformations. !HORROR - output module converting !SCARE data into rendering specific contexts like OpenGL or AGG. This wraps the raw 3D data into structures and callbacks needed to display the image in a raster. !MAD - Math library Every actual math operation used by ALL other modules is stored in ONE single module. matrix ops, vectors, geometry (point & planar). | 31-Oct-09 3:18 |
| 47 | Maxim | its fun, I'm actually starting to *understand* the 3D vector math I've been using for years blindly. :-D | 29-Oct-09 22:32 |
| 46 | Janko | another cool thing by our Maxim :) | 29-Oct-09 16:53 |
| 45 | Pekr | scare-face :-) | 29-Oct-09 12:59 |
| 44 | Pekr | we somehow have to manage Carl to finish Extensions, so that you can have some deeper experimentation with various stuff :-) | 29-Oct-09 12:58 |
| 43 | Maxim | funny code tidbit with regard to !SCARE... i've got objects called scare-scene scare-points I'm going to have to find a way to create something called scare-crow hehehe .... | 29-Oct-09 12:38 |
| 42 | Maxim | when the host shall be completely released... I'll probably start to look more closely and seriously at porting production code to R3. that way I can fix any interpreter issue related to view especially. | 29-Oct-09 12:36 |
| 41 | Maxim | I can't risk working 2 weeks and hitting an issue which can't be solved because its an unfinished part of the host. | 29-Oct-09 12:35 |
| 40 | Maxim | but view in R3 is MUCH faster in some ways, so there is appeal in trying to port some of my stuff to R3. especially with extensions providing an easy way to vastly accelerate some of my math algorithm... but right now, I'm more concerned with making a prototype which works within "known values" | 29-Oct-09 12:33 |
| 39 | Maxim | in some ways yes, in others no... its more prone to crashes, and because there are still so many core things changing from one release to another... code that works one day, stops working the next... and its ok, its alpha and not "feature locked" yet. | 29-Oct-09 12:32 |
| 38 | Pekr | Hmm, isn't actually R3 less buggy than R2? :-) | 29-Oct-09 12:29 |
| 37 | Maxim | another *go* | 29-Oct-09 11:55 |
| 36 | Maxim | liquid didn't even used to work... I'd have to give it another since Carl addressed the main issue which caused liquid to crap out R3. | 29-Oct-09 11:55 |
| 35 | Maxim | cause its buggy, cause I've got no time for release "surprises" nor can I use all of the several MB of code I already have which works in R2. going to R3 is a big endeavor for people like me who have a lot of code to convert. | 29-Oct-09 11:54 |
| 34 | Pekr | do you need VID? If not - then why not to start with R3 engine? I really don't understand, why ppl don't start to use R3 more productively :-) | 29-Oct-09 11:50 |
| 33 | Maxim | first ever screen shot of scream prototype doing some rendering :-) http://www.pointillistic.com/open-REBOL/moa/scream/scream-first-pic.png | 29-Oct-09 10:42 |
| 32 | Maxim | and there most probably will be edge issues... but worth a try... eventually. | 29-Oct-09 10:09 |
| 31 | Maxim | figured out a way to use AGG for polygonal texture mapping ... but its going to be slowwwww | 29-Oct-09 10:07 |
| 30 | Maxim | btw, scare will be integrated as a tag within remark, so you can serve 3D rendered graphics using http requests :-) | 29-Oct-09 9:39 |
| 29 | Maxim | I want the whole engine to have some ways of helping coder on other platforms than rebol, ... flash comes to mind, as does the iphone. | 29-Oct-09 8:45 |
| 28 | Maxim | the goal is to have people testing, contributing, using it ASAP, even if initially it won't be usefull for full-fledged games, I have a simple game in my head which I will proably want to code for the iphone as a commercial effort. soo, work on this is more serious than simple hobby. | 29-Oct-09 8:44 |
| 27 | Maxim | I want this to be a community project, so will be put on my web site day one. I will be working on my actual web site this week-end, finally. | 29-Oct-09 8:42 |
| 26 | Maxim | I'm workin on and off on this but since some of the math has already proven to be effective and usefull, I have started to convert my initial tests into the real engine for easy early use. | 29-Oct-09 8:41 |
| 25 | Pekr | Maxim - the big W H E N ? :-) | 29-Oct-09 8:38 |
| 24 | Steeve | yep, clear instead copy, i use the same trick each time i can. | 29-Oct-09 8:19 |
| 23 | Steeve | loops perfs are a big problem in R2. I never use something else than WHILE and UNTIL (sometimes foreach and repeat, but least often) | 29-Oct-09 8:18 |
| 22 | Maxim | keeping & clearing blocks instead of copy [] .... many little details which ultimately remove some of the normal simplicity to rebol. | 29-Oct-09 8:17 |
| 21 | Maxim | I'm just discovering how some usefull code patterns in rebol aren't very cost-effective performance-wise... I've even started to flatten loops here and there, and shitty things like that. | 29-Oct-09 8:15 |
| 20 | Steeve | well, you know, it's true for most of the algos you can invent. when you have a very deep problem of performances, in general, it's because you have developed a bad algorithm (whatever the language) | 29-Oct-09 8:12 |
| 19 | Maxim | or I'll do: point: tx1/ctx2/ctx3/points/1 if I really have too and reuse point in the algorythm. these little things really add up when you are looping over large datasets, so every % I can save, I do so as I have time to profile my code. | 29-Oct-09 8:11 |
| 18 | Maxim | for one thing, I've realized that walking paths in rebol is EXTREMELY expensive. in my isometric point projection function I was able to improve performance a full 30% by just re-organizing my data so there is little to no path lookup. ex: ctx1/ctx2/ctx3/points/1 becomes first points | 29-Oct-09 8:09 |
| 17 | Steeve | yep, i use REBOL in that way too (even when i have to code something in Z80 assembler). I tests my algos with Rebol (because it's faster to develop with it) before coding them in another language when i don't have the choice. | 29-Oct-09 8:05 |
| 16 | Maxim | even if algorithms usually come from the C world, we must adapt them to handle REBOL datatypes and specifics, so its always a bit of extra work. | 29-Oct-09 8:04 |
| 15 | Maxim | yep... this is all being addressed on thing at a time. even if slow in interpreted code, at least we will have a reference library to work on working on all platforms. with an optimized version as an extension implementing the same algorithms natively which is available or not on a platform depending on porting efforts. the rebol version is a good way to easily profile and debug algorithms before committing them to C code. | 29-Oct-09 8:03 |
| 14 | Steeve | matrix, scalar vectors, etc... | 29-Oct-09 7:54 |
| 13 | Steeve | To my mind, it's the greatest weakness of Rebol. To not have a native set of functions to perform advanced math calculations | 29-Oct-09 7:53 |
| 12 | Maxim | btw, I'm already rendering the isometric floor with an arbitrary grid on it, all built using 3d coordinates converted to AGG polygon and lines :-D most of the heavy-lifting is the math stuff which I am by no means an expert in. I know the theory in depth, but not the applied maths do get it done... so its a good learning experience for me. all the math algorithms are in a separate module, so when I get to R3 I'l be able to convert all the maths to C and make it SCREAM ;-) | 29-Oct-09 7:51 |
| 11 | Maxim | hehe | 29-Oct-09 7:48 |
| 10 | Steeve | ok, i will call mine DELIGHTS (draw engine loosy inheritance gladly hooked thru scare) | 29-Oct-09 7:47 |
| 9 | Maxim | and you'd be surprised how often sprites are used in high-end visual effects work for movies, without you ever noticing it. | 29-Oct-09 7:44 |
| 8 | Maxim | 3D game = 3D HW accelerated game | 29-Oct-09 7:42 |
| 7 | Maxim | manipulating animated textures on sprites in a 3D game can allow you to render a few thousand characters in real time without so much as a missed frame. | 29-Oct-09 7:41 |
| 6 | Maxim | there is a middle layer in between them which handles the scene description (no codename yet). FEAR can "sense" stuff within this middle layer and interact directly with it. SCARE then retargets the data into whatever rendering engine is being used... this means that I'll be able to switch to OGL or Ogre at some point without loosing all the work I'm doing. the current isometric engine is very usefull for creating a wealth of games, especially since it will be able to pre-render out a lot of its graphics and work with simple sprites, making it very fast when the game actually starts, even if used within a 3D engine. | 29-Oct-09 7:40 |
| 5 | Maxim | the AI engine which complements SCARE is called FEAR (Fully Environment Aware Reasoning ;-) | 29-Oct-09 7:36 |
| 4 | Maxim | hehe | 29-Oct-09 7:35 |
| 3 | Maxim | any hack that AGG can give me to speed up the display I will use including skew for quickly rendering texture mapped tiles, for example. as each feature is added, I do as much profiling and unit testing as I can and continually revise my algorithms based on better, simpler stuf I can find here and there. | 29-Oct-09 7:35 |
| 2 | Steeve | i can see the bad jokes if your tool doesn't keep his promises. :-) | 29-Oct-09 7:35 |
| 1 | Maxim | announcing SCARE (Scene Control And Rendering Engine) for REBOL. its a liquid-based scene graph 3D polygonal modeling/animation/rendering engine outputing data into AGG format. all the complex 3D math will be folded into VERY simple to use nodes and core objects. its litterally plug and play. liquid-paint bridge nodes are in the process of being built so that you can interact 2D & 3D processing in both ways. 2D -> 3D : using liquid-paint compositing into 3D as depth maps, textures maps, clipping masks, whatever. 3D -> 2D : plotting 3d elements into animated sprites, full-frame animation renders, or even interactive scene rendering. being lazy, the whole system should be responsive when things don't change totally. also with a few simple tricks, you can divide processing of game data thoughout a cycle, instead of at each refresh, so that can scale the amount of data crunching by a few factors too. | 29-Oct-09 7:31 |