Canardia

I think it's good that only UU3D works in a professional pipeline. All 3D modeller's export routines are broken, and I hope it will always be so, because then UU3D is the only working pipeline, and we can focus on one 100% working thing instead of a million broken things.

Don't remove hardware skinning. Just write one page of documentation how to export models, and make sure the web site doesn't change every week and half of the tutorials and docs are lost A skin change should not be able to change any functionality either, it should be just CSS change.

Modo exported bones, but you don't have the skin shader in your mat file. Remove the bones in Modo or add the skin shader to your mat files.

You might need to run Windows 7 in Safe Mode with Networking and Administrator account, because Windows 7 does not support the internet like Windows XP does.

Bullet has automatic fracturing and glueing, deforming, and breakable constraints. It has also GPU support for both ATI and nVidia using OpenCL, while PhysX has only for nVidia. Bullet has also softbody constraints, PhysX doesn't. Bullet has ropes, PhysX doesn't. Some cool demo: http://exocortex.com/simulation/momentum

Today I wanted to start a GameLib tutorial series, and wanted to eliminate all temporary code and build the tutorial from beginning so that it will only expand and build on the previous tutorial steps. Loading models and creating meshes programmatically is out of question, as you don't do that in real games. You would at least somehow have them loaded from a config file. Then I thought I should put all assets into a Leadwerks Editor scene, but that won't work with real games either, as you can't save gamestates with sbx files. Well, you could have a small seperate gamesave file, but then you would need to load the sbx file each time and remove things which are not there anymore in a later gamestate. Then I thought that having the assets in a sqlite database would work, as then I can just save changes into the database, and it would load much faster than a sbx file anyway, since it would load only assets in camera range. Of course the game should leave the original sqlite database unchanged, and rather use a copy of it. A combination of static scene dbs and dynamic scene dbs, and also partial scene dbs would work. There's only a little problem using sqlite databases with LE: There is no visual 3D Editor for Leadwerks which can use sqlite databases! With sqlite3 there comes a handy table editor, but that's not enough for making game scenes. As I'm working on a dynamic MMO also, and I wanted first to make the GameLib tutorial series to see that everything works, it seems I need to make a Leadwerks Editor SQL first. If my game uses sqlite scenes, the Editor would be needed also by team members who are working on the game content. The first version of Editor SQL can be quite simple. You can place models in front of the camera, and then you can move/scale/rotate them with the cursor keys, including grid alignment. Scaling should be possible, if I study the phy file format a bit, and change the phy file according to the mesh's scale.

If VC's x86 optimizer is superior, how come that MinGW creates faster code then? As far I know MinGW doesn't need any runtime, it's all in the exe.

I voted Bullet for the following reasons: 1) Bullet is free and comes with full source code 2) Bullet has SIMD 3) Bullet is being actively developed 4) Bullet has advanced options how bodies behave when they are overlapping, so they don't explode randomly like in Newton 5) Havok is semi-free only for Windows, but not for Linux and Mac, as you don't get the download for Linux and Mac without buying the full license 6) PhysX makes really sense only with nVidia GPUs 7) PhysX needs the user to install some seperate driver SDK 8) PhysX has no determistic behaviour and it's not even planned 9) PhysX has no 64-bit Linux version and it's not even planned 10) Newton is too slow

Coronas don't show when they are behind or inside a mesh.

When you do a FreeEntity() just set the entity pointer to NULL after that, then you don't accidentally and incidentally do anything more with the entity. LEO does that automatically already, and LEO should be used in first place anyway, or even GameLib which uses LEO also.

You need a light for the corona, and you need to position the corona where the light is: TLight lamp = CreatePointLight(); TCorona corona = CreateCorona(lamp); MoveEntity(lamp, Vec3(0,2,2)); PositionEntity(corona, EntityPosition(lamp)); SetCoronaRadius(corona, 10, 20); PaintEntity(corona, LoadMaterial("l:/lesdk541/sdk/models/entities/environment/corona/flare1.mat"));

2D doesn't mean necessarily capability, but also gameplay. You can very well have a AAA 2D game.

Then just go for Little Big Planet style AAA quality 2.5D games, it's awesome. I admire the realism of those sharp textures. Leadwerks is your best choice for productivity for that.

Not really, it will be internally all 3D anyway. But like I said 2.5D is perfectly possible. You just need to get over the past and understand that everything today is 3D, recently even 3.5D like with Samsung 3D TVs.

Yeah, like Little Big Planet would be perfect with LE2, since it uses AAA quality rendering. But flatout 2D games make no sense with LE2, and nobody wants to play them anyway.

I'm testing Code::Blocks with LE2, instead of Visual Studio 2008/2010. So far it seems quite nice, and very intuitive to learn and configure. I already found some benefits of Code::Blocks over Visual Studio: 1) LE2 syntax highlighting can be configured to be different from the built-in C++ keywords. In VS they always have the same color. 2) Compiling time is much faster, because it can use MinGW. 3) Generated code is much faster, because it can use -O3 and -O6 optimizations. 4) Loading the IDE is much faster. 5) Compiling can be configured to stop at the first error, while in Visual Studio it always tries to compile the whole source code first which takes ages and is useless if there was a first error. 6) Code::Blocks works also on Mac and Linux, so you can have the same IDE under any OS. 7) Using MinGW in Code::Blocks gets rid of the VS RunTime needs, which needs the user to install MSVCRT90.dll, or you to include them in an Microsoft.VC90.CRT folder with your game. 8) Intellisense is super fast and smart. It shows only keywords which match what you typed so far, and it works with LE2 commands too. 9) Code::Blocks work also with Wine in Linux, while Visual Studio does not, so you can use Linux to write and play your LE2 games. Wine runs also LE2 games 20 FPS faster than Windows XP (and of course much faster than Vista/7, since XP is much faster than those). 10) Showing/hiding the console window of LE2 can be easily turned on/off in Code::Blocks with the -mwindows linker option, while in Visual Studio you need either some preprocessor pragmas or some complicated System target settings. 11) Code::Blocks cleans up whitespaces after lines automatically, while in Visual Studio you have to do this manually. I will make a tutorial how to setup a LE2 project with Code::Blocks next.

Why don't you make your own server? It costs you around $10 per year with all the backup drives.

How's that possible? Because even LE2 has it's own namespace LE. Are you sure you put your own functions into your own namespace also?

We could develop the website from scratch as a community project It's quaranteed easier and faster to make, than to screw around with some buggy BBS software whose developers destroy useful features in each patch. Josh should focus on LE3 only, and not waste his time with things which he is not good at. Let the people who have skills do those web sites.

All UI packers are slow, but the command line is fast. So if you just search for some certain file pattern, like *.gmf it will be very fast to list all gmfs in a .tar.gz or any other archive format.

You should install a test server where you can play around and test untested things like backups and restores. And you should have a fallback server too, which has always the last good state. Even a $100 netbooks are good enough to act as test and fallback server. And not to mention that with Domino this could never happen, since there data and design is seperate, and you can just switch take a backup of a design, replace it with another and switch back to the last good design anytime. It wouldn't happen with a self-made PHP/MySQL app either, since you are in control what is changed, but these ready-made boards are all ****. Also CPanel is ****, and I've never understood why it's even needed, as you can do much more and much easier things directly with SSH command line, or you can make your own CPanel with PHP or LotusScript. And I wouldn't trust any application level backups. Always take a OS file system level backup.

Today I tried to make a simple web page using the Domino Designer 8.5.2FP1 XPage design element on a Domino 8.5.2FP1 Linux server. Getting to know how it works is pretty easy, and I didn't need to read any documentation. I made a Form with a Subject and Body field, and a View which shows the Subject, then I made an XPage which uses the Form as its Data Source. Then I found some good and bad sides about XPages: The Good The Bad 1) It's quite easy to learn how to use XPages, as the UI makes sense. It's pretty close to Visual Studio also. 2) The design element toolbar is nice, and you can drag and drop any design element to your XPage. 3) You can easily connect fields from Notes Views and Notes Forms with visual design elements. 4) A RichText type field activates CKEditor automatically, and it saves it as Notes RichText so it can be visually seen in the Notes Client also. Getting rid of the IBM Oracle Java RichText applet was a very good decision of IBM. Now they just have to get rid of the rest of IBM Oracle Java in Notes/Designer/Domino and things would be faster and better than ever. CKEditor rocks hard! 5) XPages have many useful premade actions which you can use in Buttons, for example Create Document, Edit Document, Toggle Read/Edit mode, Create Response Document, Delete Document. 6) The design elements have a nicely structured Data/Style/All properties tree view, from which you can visually change many CSS tags, JavaScript events, Notes functions, etc.... This makes visual working effective and fun, even when it's only visual coding, as the visual output is a different issue. 7) You can integrate standard JavaScript libraries visually into XPages, like Dojo, JSon, REST, etc.... 1) The visual layout in Designer does not match the visual layout in SeaMonkey or Notes very much. I get a much closer match with SeaMonkey's Ctrl-E visual editor, from which I can copy/paste individual design elements into a Notes Form for further processing. I thought that maybe the main reason is the difference in the default settings of SeaMonkey/Notes/Designer, and by adding a CSS stylesheet, the visual output would match closer in all clients. A stylesheet didn't help either, and Designer still shows the HTML page completely different than the browser. I found a workaround though: adding computed fields with HTML code on the XPage around all XPage design elements solves the problem, and I get a decent browser output. 2) The HTML/CSS source code is calling some XSP JavaScript class, and it's impossible to edit or analyze the page with SeaMonkey afterwards, since there are no div tags or any other HTML tags. This is not very compatible with anything, and makes development harder. It seems there are divs after all, but they don't support the position:absolute style. 3) The fact that CKEditor saves RichText as Notes RichText has its bad sides too. You can't correct errors in the HTML code when the transformation goes wrong. Also the Source button in CKEditor is missing, as well as the Layer (=div) button. Maybe there is a hack to make it save as HTML? Fixed: It actually saves as MIME/HTML so the HTML source code of the rich text field is intact, this is great! 4) When I made a very simple XPage with only a Subject and Body field, Domino Designer managed to mess up its own XSP code and caused 2 errors which broke the XSP compiler, and the XPage could no longer be compiled/updated. I removed manually some duplicate action/save tag in the XSP code and it worked again. 5) When Domino is configured to run on port 81, and even when I have the firewall opened for port 80 and 81 from my Workstation and Server, the XSP RichText CKEditor breaks when port 81 is used, and only a small textarea is shown. This is however not a real issue, as I need to add some redirection code anyway to redirect Domino back to port 80. I just hope XPages allows such redirection, like the $$Return field in Forms does, or the Print statement in WQS LotusScript agents. I wonder why Domino even tries to force the user to port 81, when the web page was opened from port 80 or no port was specified (which defaults to 80). Domino should not care what is written in its server document, but only look at the incoming URL. 6) The XPage opens fine in SeaMonkey, when I choose Design/Preview in Web Browser, and it worked first in Notes too, but after I added the Body field, it stopped working in Notes completely, and I only get an error: Item not found. Workaround found: Opening the XPage manually from the server works fine in Notes. I would be glad to hear what I did wrong, and how I can get those bad things fixed. Source

Since the end of life of Notes/Domino 7 is coming in 2011-04-30 according to Ed Brill: End of Life for ND7, it's a good time to review the benefits of the two best Web Database platforms available on the market today: LAMP (=Linux Apache MySQL PHP) and Domino. 1) LAMP database design can be edited with any text editor remotely, even with vi via secure shell (SSH). Domino Designer 7 and Notes 7 work fine, but not Domino Designer 8.5 or Notes 8. Domino Designer 8.5 is written in Java and is thus ridiculously bloated, slow, buggy and exposes lots of security holes. Notes 8 crashes when opening documents which contain HTML code, while the same document opens fine in Notes 7 and Notes 8.5, although some of them crash also Notes 7, but Notes 8.5 doesn't crash on any of them. Android got rid of Java in their OS, and users are praising the smaller memory footprint of 30MB and the incredible raise in speed due to native C++ code. OpenOffice uses Java also, and is a bit slow, but by miles not as slow as IBM's Java engine, which you can experience with Domino Designer 8.5, Notes 8.5 and Symphony. Although many things can be done with a graphical design in Domino Designer, the graphical features need to be replaced with LotusScript code when the application needs more features and customization. If you've ever worked with a simple application ready web server like Quickr, Sharepoint or Ruby On Rails (which are all horribly slow and inflexible compared to LAMP or Domino), as a developer you will love systems which are exactly the opposite and have thus full programmability and speed, and easy customization support, even if they don't have any ready apps. Hmm, actually this is a good question why does Domino not have any ready apps, or does it, if you count openntf.org? It's just not marketed as such by IBM. I think IBM should understand what collaboration really means, it means that the community does eventually official things, and not only IBM. A half point goes to LAMP. 2) LAMP combines HTML and server side code in the same php document. This makes coding very easy and convenient, while in Domino Designer you need to juggle with a WebQueryOpen and WebQuerySave agent, which usually needs then more code and visual design elements to handle all different situations - you have to place additional fields in the Form and address them in the LotusScript code. This point is a draw though, since in LAMP you need to code everything, while in Domino Designer you can avoid some coding, and despite that it usually needs some more effort later on, it also saves time. 3) The Domino 8.5 server has had known and fatal bugs for years, and although IBM knows about them, they haven't been fixed. One of those fatal bugs is for example that LotusScript WebQueryOpen agents keep running forever, until the memory is full, when the user closes the browser. The only workaround is to make a HTTP restart every night. In Domino 7 this problem does not exist. Another fatal bug is that chronos.exe crashes the server, however this can be fixed by deleting chronos.exe (speak: move it to a backup subdirectory, as you might need it for the next incremental installer), as it is some remain from Domino 1.0 where it also crashed all the time. And a third fatal bug is that compact increases the database size. This works fine in Domino 7. And a fourth fatal bug is that DAOS enabled databases with attachments cannot be copied to a Local file system when they are restored to a backup server first. This works also fine in Domino 7, since it has no DAOS. Domino 7 vs LAMP would have been a draw, but since businesses are forced to upgrade to Domino 8.5, this point goes to LAMP, as it has no such fatal bugs. In a similar situation, where Microsoft's Windows Vista was a plain failure for businesses (there was no business need or even benefit to upgrade) and Windows 7 (better than Vista, but it made itself required by ending the OEM Windows XP support), there is still support for Windows XP until year 2020, because that is the end of life of Windows 7 and the Windows XP downgrade is part of Windows 7, so it extends the end of support of Windows XP equal to the end of life of Windows 7. I find it a bit ironic that Microsoft has now better backwards compatibility, while this was the ace card of IBM over Microsoft for decades. 4) LAMP is open source and free, while Domino 8.5 is closed source and commercial only. Android won iPhone, Sony/Ericsson and Nokia because it is open source and free. Likewise, the importance of a free version of Domino is to get a bigger market impact and get it more supported. This point goes to LAMP. 5) LAMP works on 12 hardware platforms, while Domino works only on 5. An important version is the 64-bit Linux version on Intel and PowerPC, and Domino doesn't have them either: FAQ: 64-bit version of Domino This point goes to LAMP. 6) Readers and Authors type fields and Groups and Roles are a major benefit of Domino. This point goes to Domino. 7) Love for Lotus and the visual development environment keeps the developers motivated. This point goes to Domino. As it stands now, LAMP wins Domino 8.5 with 4.5:3. LAMP vs Domino 7 would have been only a 4.5:4 win. Source

By the time LE3 comes out, I think Bullet will be quite a close match to Newton in accuracy. It already wins in many other features, but I want to see that it wins in all features before I can clearly say that Bullet is better than Newton. It would be kinda silly to have 2 physics engines in LE3, especially when you have the full source code of the physics engine, so it's your own fault if you can't unify them.

Actually Bullet is much faster, I just noticed a huge inefficiency in my Bullet class Now it positions and rotates all cubes in each frame, but it only needs to do that when the physics body has moved. I tried to get Bullet deterministic by removing all srand() functions and making all rand() calls to return 0 always, but it didn't work (it acts just like before, works fine, but is not deterministic), so that's something where Newton still wins. The Bullet lead developer, Erwin Coumans, lives also in California, just around the corner where Josh lives, so maybe he should have a visit some day