News
Analyzed 6 days
ago based on code collected 6 days ago.
|
Posted
14 days
ago
Various new features developed for next Castle Game Engine and view3dscene:
NavigationInfo.transitionComplete support. Demo model transition_multiple_viewpoints.x3dv shows how to use it to make an animated transition between a ... [More] couple of viewpoints. Thanks to Abou Al Montacir we will have packages with Castle Game Engine and view3dscene in Debian! Most of this software was developed by Michalis using Debian, so having my software in the Debian repository would feel really great for me :) See here for our forum thread, and here is the Debian bug marking ITP (Intent To Package) for engine: #706408 and for view3dscene: #707932. For developers, new chapter of our tutorial describing network support is available. Engine examples contain a simple tool examples/tools/to_data_uri.lpr that can generate data URI (to embed your texture, audio, model, etc. inside a VRML/X3D model, or a webpage, or other documents) from any file. It gets the file and guesses MIME type using our existing CastleDownload unit, so it supports local files as well as http links, and MIME type is retrieved from server or guessed based on file extension. There is a demo data_uri.x3dv showing how you can use data URI to embed all kinds of things inside X3D file: textures, sounds, other 3D models (to Inline or Anchor to them), scripts etc. MultiTexture.function support (forces shader pipeline rendering for given shape; there's no way to reasonably implement this using fixed-function pipeline). Demo in functions.x3dv. A set of X3D multi-texturing tests is available, testing support of view3dscene and other VRML / X3D browsers for multi-texture features. This is part of my ongoing effort to improve X3D MultiTexturing specification. There is a progress bar showing the process the downloading. The download is still blocking, but at least now you see what's going on :) If you load or save image sequences using the syntax image%d.png, for example inside our extension Movies for MovieTexture can be loaded from images sequence: the new syntax to indicate counter inside the URL will be @counter(4), where 4 is the padding. For example image%d.png has to be changed to image@counter(1).png and imageM.png has to be changed to image@counter(4).png. For loading, you will have to use new syntax with @counter() with new view3dscene / Castle Game Engine versions. You will have to update your VRML/X3D models, old syntax will unfortunately not work anymore (reasons below). For saving, the old syntax %d will continue to work for some time (along the new @counter() syntax, and you're encouraged to upgrade to new syntax). The reason for this is that MovieTexture.url is now correctly treated as an URL, and this means that percent character % needs to be escaped to %. Inside URL the sequence M has to mean letter M (ASCII code 77, which is 4d in hexadecimal). So there is unfortunately no way to avoid breaking compatibility — we want to correctly support URLs, which implies that M must be interpreted as letter "M", not as a magic counter. Looking back, it was an unfortunate choice to use percent character to indicate images sequence, since percent is special inside URIs. It was done for consistency with ffmpeg, that supports things like imageM.png on the command-line (but not when using URLs; for example, ffplay /home/imageM.png works, but ffplay file:///home/imageM.png does not work, neither does ffplay file:///home/image%4d.png). So, one can say that it was ffmpeg that made a bad choice, but then ffmpeg did it for consistency with common string formatting functions (C sprintf, ObjectPascal Format)... Comments about this change are of course welcome, through forum or any other means. Right now, I just don't see a way to avoid breaking compatibility. We made a bad decision to use %d to indicate image sequence, and it has to change in order to correctly support URL encoding in new versions. A couple of bugfixes. Including bugfix to a quite horrible mistake in ShaderPart node, in some circumstances the shader code would be reloaded from file at every frame, causing a horrible slowdown. It's fixed now of course. [Less] |
||||||
|
Posted
about 1 month
ago
Hello everyone!
There is a contest for best open-source project on Polish portal http://www.spinacz.edu.pl/. Please take a moment to vote for our Castle Game Engine! Our engine was submitted to devmaster.net, with lots ... [More] of information and screenshots. You're welcome to review and rate us there! We also want to remind that we have a Google+ page about our Castle Game Engine, you can follow it to see (a little more frequent) news about our engine development. New engine features in development: Mac OS X with native look. This is already much more user-friendly than our previous GTK-based releases for Mac OS X. See development details. Hopefully, this will allow us to release next view3dscene as normal Mac OS X application, that will be trivial to install for Mac OS X users. Network (http) support. Most "FileName" parameters and properties are now URLs. You can use protocols like file: and http: and data: everywhere, and of course http will be automatically downloaded. Try view3dscene from snapshots, enable "Preferences->Download Resources From Network" and then use menu item (Ctrl+L) to load URL, or pass URL on the command-line. This is a little user-unfriendly, as the downloading is blocking (the process waits for the download to finish, instead of letting you enjoy the game and download in the background; there isn't even any nice way to cancel the download, or even notification about it, except for --debug-log message). For this reason, it is disabled by default: you have to explicitly allow it by "Preferences->Download Resources From Network" (in code: CastleDownload.EnableNetwork variable). For some test scenes on the Internet, try e.g. Inline demo or Texture demo or AudioClip demo. (from ConformanceNist X3D Examples Archive). Or see our demo models through http, by browsing through SVN http link. view3dscene automatically downloads the model, as well as all linked resources (textures, inline models, sounds, scripts etc.). You can also use VRML/X3D Anchors to jump to any URL (for example, you can jump from a local file to a model available through http). Also data: URI handling is now more uniform. Also the engine uses now MIME types more, instead of merely file extensions. This makes us work with http transfers, and improves cooperation with data: URIs. In a game, you could also use URLs inside files like level.xml and resource.xml. For example, you could distribute now a level.xml file that contains URLs to levels on your server, downloaded each time. Clipboard (Ctrl+C, Ctrl+V, Ctrl+X in message boxes, especially handy to copy/paste URLs). For developers: use Clipboard.AsText property. Implemented for CastleWindow WinAPI, GTK, LCL backends. CAD level 2 support (CADXxx nodes). Improvements to 2D rendering. They also workaround crashes on some Mesa 9 drivers. Support for 8 and 16 samples for anti-aliasing, there are (at least NVidia) GPUs supporting it. Renamed our event Idle to Update. This reflects our implementation and usage of this event clearer. This event is for continuous tasks, called even when the application is not "idle" (when application is processing something, like mouse moves). Our Update event doesn't correspond 100% to normal (as used by LCL or GTK) meaning of "idle" (which is also evidenced by code if TCastleWindow LCL and GTK backends, that cannot simply use LCL/GTK "idle" concepts to implement our Update). TCastleControl.AggressiveUpdate* are removed. The (simplified and improved) version of this mechanism is now always "on" and automatically makes mouse look work better. It's still not perfect (it seems LCL event loop is just too slow to process events during mouse look fast enough), but it's better now. If you want perfectly smooth mouse look, you should still consider TCastleWindow instead of TCastleControl. [Less] |
||||||
|
Posted
4 months
ago
We proudly present the Castle Game Engine 4.0.0 release! This is the greatest release of our engine ever for ObjectPascal developers interested in making their own games:
We introduce a high-level game API, to construct a ... [More] fully-working 3D game really easy. This includes integrated units to manage levels, creatures (with smart AI), items, player, with inventory, management of 3D resources, easy 3D sound, flexible game data layout (you can use XML files to define a lot of things without touching game code), and so on. Of course, we use VRML/X3D for all the 3D models, so everything can be animated and interactive, and may use features like shadows, mirrors, shaders and such. See our demo 3D models (in particular, check new water/caustics/ demo inside, by Victor Amat, movie showing it is here). There are a couple new examples in engine sources. First of all, examples/fps_game/ is a must-see: it shows a complete working FPS game, with a lot of comments in the source code and data files. The engine is very flexible, you can derive new classes and override a lot of methods to customize behavior of everything in ObjectPascal. You can define new level logic, new creatures, new items, and finally you can also use basic 3D classes to easily create any 3D entities suitable for your game. You can also easily create your own viewports, scene managers, 2D controls, use 3D sound and much more. Everything is explained in the new tutorial. We have a lot of new documentation to show you how to use the engine: Tutorial - introduces most concepts of the engine, with example code snippets. Classes overview (cheatsheet) - a quick ride through most important engine classes and ideas. Guide to creating game data - how to create your 3D models using any 3D modeling software (like open-source Blender), and how to write various configuration files like resource.xml and level.xml. As always, there is also a complete API reference. The full list of changes is definitely too large to fit into a normal news item. In the past I usually tried to list all the important changes in a release announcement, but there's just too many things this time :) New engine units include CastleCreatures, CastleItems, CastleLevels, CastlePlayer, CastleMaterialProperties, CastleResources. There are also countless changes in the rest of the engine to make it better and more integrated. See the news from the whole 2012 year for a complete list of details. For developers upgrading from engine 3 version: all of our unit names are now prefixed with CastleXxx, see doc/naming_engine_4.0.txt document. So you will almost definitely need to fix your "uses" clauses. Aside from that, the engine is quite compatible with previous version. Of course please ask of the forum if you have any questions about upgrading code from engine 3 to 4 (or about anything else, for that matter :) We also release a new 3.12.0 version of view3dscene, our VRML/X3D browser and viewer for other 3D model formats. The most important improvements are listed below. Note that improvements 1-7 are actually in the engine, instantly available for all the games/applications using our engine. But most users will probably observe them in view3dscene for the 1st time. Navigating in Walk / Fly modes by mouse dragging. Using 3D mouse devices. Screen-space ambient occlusion (see menu "View -> Screen Effects" menu item, developers: try the ultra-simple TCastleAbstractViewport.ScreenSpaceAmbientOcclusion boolean property). All screen effects cooperate now with multi-sampling (anti-aliasing). UNIT statement from X3D 3.3 is implemented. VisibilitySensor node is supported. Many fixes to triangulating concave polygons. New "Edit -> Lights Editor" feature. Many thanks go to Jan Adamec for implementing the 1-3 features above (and more)! Our engine is used as VRML viewer for shareware Room Arranger. All the other programs and data on our pages were updated to use/show new engine 4.0.0 version: The Castle 1.0.0 (finally!), malfunction 1.2.8, kambi_lines 1.1.7, view3dscene 3.12.0, rayhunter 1.3.4, glViewImage 1.4.1, glplotter 1.2.5, bezier_curves 1.1.9, glinformation 1.2.2, gen_function 1.0.5, demo models 3.2.0. [Less] |
||||||
|
Posted
4 months
ago
Many final improvements done to the engine, to make the next 4.0.0 release really polished for developers. Below is a list of new SVN features (implemented since last news, mostly within the last 3 weeks).
Engine 4.0.0 release is ... [More] almost ready, what remains is finishing the new tutorials. BTW, I got into habit of posting a little smaller (and more frequent) notes about engine development on our Google+ page, so you're welcome to follow us there. Latest improvements to the engine: New very important example program is available in engine source code: fps_game. It is a simple demo, with a lot of comments in code, of a fully-working FPS game. We have level, creatures, items (medkit and weapon), inventory, player can be hurt and die, player can shoot and kill the creatures, bump mapping, move limit, sectors/waypoints (for AI), buttons, notifications, custom viewport, sounds, sky, water, footsteps and a lot of comments. P.S. Various game data (knight, textures, sounds) are from opengameart.org, countless thanks go to it's many contributors. Details what is from where are inside AUTHORS.txt files in sources. Only level and items were modeled by Michalis from scratch. Improvements to game logic: Creature enemy is now configurable by overriding TWalkAttackCreature.Enemy method. The default implementation chooses the central player as the enemy (if the player is not dead yet), but you can override it to implement something more sophisticated (like creature vs creature fighting, teams etc. — not everything is tested there yet, but it all should be doable now, so go wild :). New methods to define creature/items (all resources) animations are available. You can load animation from kanim, or from multiple VRML/X3D files (one VRML/X3D for each animation), or from a single VRML/X3D file (in which case the file will have to contain different TimeSensor to activate each animation). Description how it works is inside DRAFT.modeling_tutorial.txt for now. Example of all 3 methods to define animations are inside castle_game_engine/examples/resource_animations/ in sources. Many improvements to our RenderDebug3D and RenderDebugCaptions mechanisms (you can see them e.g. in fps_game demo): respect Orientation (work with games with either +Y or +Z up), sphere is displayed better, caption is multi-line and contains "enemy distance" info. TItem.Picked method can be overridden to configure what happens when you pick item. Example code in fps_game shows how to make an item that is consumed on pickup (aka "power-up"). TextureProperties mechanism was enhanced into MaterialProperties, that can describe much more things. In the future, we can add there more stuff about material/texture that cannot be comfortably expressed in Blender, but that is conceptually tied to material/texture. For now, the main addition is that you can define bump mapping by normal_map properties there. The hack in our Blender exporter (to autodetect xxx_normalmap textures) will possibly be removed at some point (as it has no future, it's dirty). player.xml must be now loaded explicitly by Player.LoadFromFile (we try to never load the file from some hardcoded location without you requesting it). Also, all player properties have now sensible defaults, so in simple cases there's no need to use this file at all. Final code renames/refactoring: A lot of unit renames, to bring all units to CastleXxx names. I admit it was a mistake trying to have non-prefixed unit names in engine 3.0.0. After some time, many unit names had to be prefixed anyway, and this created inconsistent naming — some unit names had Castle prefix, some not. Now all unit names have Castle prefix (the only exception being X3DXxx units). It means that when upgrading your project from engine 3 to 4, you'll have to do appropriate renames in the "uses" clause of your units. Compiler will tell you where :) I also prepared a list of renames in doc/naming_engine_4.0.txt file. Many DefaultXxx global constants moved to constants inside classes, to not pollute namespaces with a lot of constants that are usually useful only as default value for corresponding property Xxx. All creature/items "kinds" renamed to "resources". Previously, terms "kinds" and "resources" were used to refer to the same thing, which could create confusion. Now it's simple: resource.xml file refers to the resource class (maybe it's creature resource, maybe item resource and so on), and creates resource instance. TCreatureResource is derived from T3DResource (as TCreature derives from T3D). TItemResource is derived from T3DResource, like TItemOnLevel derives from T3D. CastleKeysMouse (formerly KeysMouse) types are no longer aliased in CastleWindow unit. This was unmaintainable, and wasn't available in Lazarus CastleControl. Simply add CastleKeysMouse to your uses clause if you use any identifier from it. Removed units: VideosCache (merged into CastleVideos), Rectangles (merged to CastleOnScreenMenu), BezierCurve (merged to CastleCurves), NormalizationCubeMap (moved to bump_mapping example dir, not useful for engine; and bump_mapping was actually removed from engine core, as not useful anymore, it's now in obscure_castle_engine_demos_and_tools repo). Other engine improvements: CastleImages supports resizing images with bilinear interpolation. TCastleImage.Resize and TCastleImage.MakeResized take Interpolation parameter, riNearest or riBilinear. Default is still riNearest, so fast (and ugly) like before. CastleWindowProgress, when it needs to scale progress background image, requests riBilinear interpolation. glViewImage allows to test both resizing methods. Fonts: Huge refactoring of font units and types. We now have 4 units: CastleOutlineFonts, CastleBitmapFonts, CastleGLOutlineFonts, CastleGLBitmapFonts. TBitmapFont and TOutlineFont are classes, with Data field and some methods. This way utilities from CastleOutlineFonts become methods. font2pascal utility added, this is a very old Windows-only utility to convert fonts into our bitmap/outline font structures. It awaits eagerly to be reimplemented using freetype, contributions for this are most welcome! Memory optimization for models with many nodes (esp. using heavily prototypes), by about 10%, and another 10% possible if you define CONSERVE_TRIANGLE_MEMORY symbol. Improvements to CastleWindowProgress: Opacity property, configurable colors, using UIFontSmall when necessary, fixed to work with non-standard glViewport (like after typical TCastleViewport usage). "Home" key in Examine mode goes to initial viewpoint (configurable by VRML/X3D Viewpoint or SetInitialView in code), instead of always going to viewpoint with +Y up. This should be universally more useful and more natural than previous behavior. Fixes to viewports for ATI on Linux (one bug of Mesa, one bug of fglrx, see BuggyDepth32 and BuggySwapNonStandardViewport in CastleGLVersion). Examine camera has ExclusiveEvents = true, consistent with other TUIControl. CastleLog output stream is configurable. The caustics demo (you seen a movie of this in earlier news) is now committed to our demo models. Many thanks to Victor Amat! I hope to use these ideas to make such water available out-of-the-box for all games using our engine (right now you will have to adjust shaders for your specific case). [Less] |
||||||
|
Posted
6 months
ago
Sorry, still no new release... But, as usual, we have many new features to announce for the upcoming Castle Game Engine 4.0.0 :) For starters, a little movie with explosions fun:
New features: Creatures/items (commonly ... [More] called "resources" in many places) improvements: New example program: resource_animations. Demonstrates how to define creature/item animations in resource.xml files, from KAnim and/or X3D animations. Can be also used to preview animations from any resource.xml files, e.g. you can try it on castle1 creatures and items. See DRAFT.modeling_tutorial.txt (will be moved to nicer HTML page later) for notes about how to design your creatures/items. (The knight animated model comes from opengameart.org.) Defining short-range creature attack and/or firing a missile are trivial now. See TWalkAttackCreatureKind.AttackXxx and TWalkAttackCreatureKind.FireMissileXxx properties, and and elements in resource.xml. What actually happens is configurable by overriding methods TWalkAttackCreature.Attack and TWalkAttackCreature.FireMissile. So, while you can think that is "short-range attack" and is "firing a missile", in reality it's more like is "1st configurable attack-like action" and is "2nd configurable attack-like action". You still can use extra states for special purposes in TWalkAttackCreature (csMax+1, csMax+2 etc.), so it's possible to add even more kinds of attack (or really anything else) by overriding appropriate methods. Removing dead creature corpses from level is trivial, see RemoveDead property and remove_dead in resource.xml. Weapons behavior is trivial to define also: short-range attack and missile firing (with ammo or not) is configurable fully inside TItemWeaponKind (and related resource.xml file), no need for a single line of code. A weapon can also immediately shoot (like a pistol). Ammunition type is configurable both for missile firing (arrows to fire) and immediate shooting or short-range (bullets for a pistol). Die animations, and configurable RemoveDead, are also available for Still and Missile creatures. Die animation allows e.g. to make exploding animations for missiles and immobile objects (like barrel in the movie above). RemoveDead allows to keep the corpse on the level, with special twists for missiles. Your missiles, like arrows, can be left "stuck" in the wall. (This mechanism should be better and more intelligent in the future, as part of the "decal" system. For now, at least it basically works for some cases.) CastShadowVolumes and ReceiveShadowVolumes, default true, configurable for every item and creature (cast_shadow_volumes and receive_shadow_volumes in resource.xml). TItemOnWorld.AutoPick property, to control automatic picking of items by player, and TItemOnWorld.ExtractItem method to implement picking yourself. TItemOnWorld.RotationSpeed property, to control the speed of rotation of items (set to 0 to disable rotating). TInventoryItem.Stack method to override, to affect how items stacking works. New nice properties to control middle point used for collisions (see T3D.Middle, T3DCustomTransform.MiddlePoint, T3DCustomTransform.PreferredHeight). Unified gravity on items and creatures, with new comfortable properties (see T3DCustomTransform.Gravity, T3DCustomTransform.FallSpeed, T3DCustomTransform.GrowSpeed). More configurable from resource.xml file (middle_height, fall_speed, grow_speed, direction_fall_speed — see README_about_index_xml_files.txt). Removed default TCreature and TItemOnWorld behavior on "activation" (Input_Interact, usually "e" in 3D games like "The Castle" and left mouse click in traditional 3D viewers). Previously they were making a simple description "what you see" on the Notifications, which may not be a desirable default behavior for many games. If needed, you can reimplement this (or many other ideas) by overriding TCastleSceneManager.PointingDeviceActivate3D . You can also make your own T3D descendants and override their T3D.PointingDeviceActivate, like before. Our Blender X3D exporter updated for Blender 2.64a. New KAnim exporter for Blender 2.64a added. For the same reason as a couple of years ago (Blender standard X3D exporter still cannot export animations) we still need it. Levels improvements: Placeholders are nicer. You can indicate in level.xml how to detect placeholder names in 3D level file, for example use placeholders="blender" to use object names set in Blender. You configure it now nicely to support any other modeler. Also, we now make clear that this detection dependent on modeler is only for TGameSceneManager.LoadLevel placeholders, nothing else. See level.xml and resource.xml files documentation. You can register own callbacks, see PlaceholdersNames and docs of TPlaceholderName. Magic "margin" parameter around sectors removed. We now just look at waypoint's bounding box. See castle-development for notes about sectors/waypoints for user, and see TGameSceneManager.LoadLevel for developer docs. Extracting direction (for initial direction that the creature is facing) from placeholder. See placeholder_default_direction in README_about_index_xml_files docs. TCastleSceneManager.OnMoveAllowed callback, to control how the algorithm described at TCastleSceneManager.MoveLimit works — allows to limit the working of gravity and/or movement to some 3D space. Player improvements: TPlayer.RenderOnTop feature. Every T3DOrient instance has automatically a synchronized T3DOrient.Camera instance inside. This makes PlayerCamera synchronization work without any fuss. It also allows to switch your view into a computer-controlled creature, which is quite fun. In network games, other players will also be creatures (with data synchronized from network), so this will also allow observing other players when in "spectator" mode — I saw this feature in Tremulous, it's quite cool. TPlayer.Flying and TPlayer.FlyingTimeOut, a simpler and more flexible properties to control player flying (replace previous TPlayer.FlyingMode and friends). Image API improvements: Cleanups around AlphaChannel detection, code simplified (and much shortened). Our alphaChannel extension is now available for all X3DTextureNode. Introducing TGLImage class in GLImages unit, for drawing images on 2D screen. This encapsulates a display list, and in the future will be seamlessly changed to PBO for modern OpenGL versions. ForbiddenConvs parameter to LoadImage removed, along with TImageLoadConversions and friends. They were complicated, and not really useful in practice. (If you're really paranoid about conversions, you can use LoadImage to any class and make conversions yourself, honoring any order/limits as you desire.) Other changes: Unit CastleGameCache removed. We automatically use the global GLContextCache now, this makes things trivial to use and automatically optimal. If you really, really want to use a separate cache for some stuff, you can still do it by TCastleScene.CreateCustomCache and TCastlePrecalculatedAnimation.CreateCustomCache — but, aside from debugging, it's hard to imagine why you would need it now :) OpenGL resources are automatically shared between two or more TCastleControl controls. Also Idle fixes for multiple TCastleControl in a single application. Generic unit name Shape renamed to CastleShapes, Images to CastleImages, Triangle to X3DTriangles. New unit CastleTriangles extracted from VectorMath (to make a huge VectorMath unit at least a little slimmer). Large press / release callbacks and virtual methods rearrangement: all presses (KeyDown, MouseDown, MouseWheel) now go to a single Press method (with TInputPressRelease param). Likewise, all releases (KeyUp, MouseUp (we didn't implement mouse wheel releases yet)) go to Release. Same goes for callbacks, now you have OnPress and OnRelease. This allows a huge code cleanup (and shortening) in a lot of places. Since our engine concentrates input processing on TInputShortcut, where you can customize whether it's key and/or mouse button and/or mouse wheel, it makes sense to store "press" and "release" as a single TInputPressRelease value. Previously, a lot of code was complicated because of this, and also some methods had a lot of parameters to pass all key/mouse information in separate variables. If you want to add some key/mouse shortcut to your game, you can now do it easily: Create it, like this: Input_UseLifePotion := TInputShortcut.Create(nil, 'Use life potion', 'life_potion_use', igItems); Input_UseLifePotion.Assign(K_L, K_None, #0, false, mbLeft); Then use it in TCastleWindow.OnPress or TCastleControl.OnPress callback, or in an overridden TInputListener.Press method (TInputListener is an ancestor for many things, like TCamera, TUIControl, TCastleSceneManager) like procedure Press(Window: TCastleWindowBase; const Event: TInputPressRelease); begin if Input.IsEvent(Event) then ... end; The keymap management in CastleInputs unit cooperates with it nicely. For example you can check which shortcut matches by InputsAll.SeekMatchingShortcut. You can get an input from user by CastleMessages.MessageKeyMouse. This is great for games where you want to allow user to customize inputs. See GameControlsMenu in castle1 source for a working example of it, with TCastleOnScreenMenu integration. You can of course still hardcode the particular keys/mouse buttons etc., if you want. It's still simple as the TInputPressRelease is a pretty trivial structure, it has EventType field, and even helpers like IsKey. So you can do procedure Press(Window: TCastleWindowBase; const Event: TInputPressRelease); begin if Input.IsKey(CharEscape) then ... if Input.IsMouseButton(mbLeft) then ... end; [Less] |
||||||
|
Posted
8 months
ago
Work on the new Castle Game Engine 4.0.0 version continues :) Many improvements for the programmers that want to develop their own games using our engine:
Many improvements to engine tutorial, classes diagram ... [More] and level.xml and resource.xml files documentation. It's still a lot of raw, unformatted text, but the content pretty much covers now everything I want, and it describes the latest engine workings in SVN. Previous index.xml are now named level.xml (for levels), or resource.xml (for creatures, items, and other heavy 3D stuff that may be shared by levels). This makes things cleaner, and LoadFromFiles calls easier (you can just let it search whole ProgramDataPath). Placeholder 3D objects have now consistent naming. "Placeholders" are 3D objects that have special meaning when you load your level through TGameSceneManager.LoadLevel — objects with some special names are removed from normal level geometry, and they indicate... well, various things. See TGameSceneManager.LoadLevel docs (from engine SVN reference) for full reference. Short: Resources (creatures and items initial positions) placeholders and are now named CasRes.... Movement limit box is named CasMoveLimit (previously "LevelBox"; see TCastleceneManager.MoveLimit for docs). Water volume is CasWater (see TCastleSceneManager.Water docs). Sectors and waypoints are CasSector..., CasWaypoint... (for creature AI; see TCastleSceneManager.CreateSectors). Fix a lot of code to honour the "up" world vector to be +Y as well as +Z. Gravity is decided looking at Viewpoint gravity in VRML/X3D, and creature orientation is decided looking at T3DOrient.DefaultOrientation. See also engine tutorial section Which way is up. And see TOrientationType type values. CastleLevels improvements: LoadLevel interface much simpler. Much more docs around TGameSceneManager and TLevelAvailable. Ugly MenuBackground parameter removed, it's not needed at all. Oh, and TCastleWindow.SceneManager and TCastleControl.SceneManager is now of TGameSceneManager class. So if you use TCastleWindow / TCastleControl, you can use the levels system designed in CastleLevels really trivially: LevelsAvailable.LoadFromFiles; Window.SceneManager.LoadLevel('my_level_name'); Congratulations, you just wrote a game :) All that remains is to prepare a game 3D data, and level.xml file with name="my_level_name". You already have all the code you need :) See castle_game_engine/examples/3d_sound_game/ for a larger working example using this. An easy way to debug AI information, to see how AI "thinks". Just set global boolean RenderDebug3D (formerly RenderDebugBoundingVolumes) to true, and you will see: Yellow axis is the middle (eyes) position for each creature and item. This determines the line of sight, and helps with other collision decisions when "legs" position would be uncomfortable. Red axis, for each creature, is the last seen target (usually enemy, which is usually player) position. You often don't see it, because you're actually standing on it. But it can be seen when you dodge behind a corner, and you look at your previous position. Blue axis, for each creature, is the alternative walk target. Used when creature cannot seem to reach it's normal target. Basically, when straight line and sectors/waypoints fail, the creature wanders randomly hoping to get on the right track (or at least to avoid player shooting them easy). Of course, this is the last resort. If your creatures seem to be blocked too often, you may want to divide your level into more sectors and use more waypoints to "guide" the creatures. Unless you want your creatures to be dumb, of course, which is quite sensible for many games. Sound: engine units and classes simpler, no AL prefix everywhere. Also fixes to AudioClip X3D node (it wasn't always releasing reference when it should, causing crashes in special situations). Limit amount of logging by default. Our InitializeLog (see CastleLog unit docs, try --debug-log options of various programs) was producing way too much information by default, and important things were difficult to spot. Now by default it's shorter, showing only seldom happening things or important warnings. Much cleanup in CastleInputs unit. TInputShortcut and TInputConfiguration merged. Idea of "global" and "local" key shortcuts clearly defined and documented. TCastleSceneManager automatically handles now key combinations related to player inventory. Many renames in the new API. We want to get the new engine API as good as possible, before it's released and breaking compatibility will not be as easy. T3D.Pushable to T3D.CollidesWithMoving (it means that doors/elevators push or avoid crushing this object) ItemOnLevel, PutOnLevel etc. to ItemOnWorld, PutOnWorld etc. (we try to consistently use the term "World" to refer to your 3D world, and reserve the word "level" for levels recognized by CastleLevels.TLevelAvailable) TItem to TInventoryItem, and some Items properties renamed to Inventory. TItem was too generic, and in ObjectPascal "Items" has too generic meaning (many generic lists have "Items" properties referring to their contents; our "Inventory" is a now a list of TInventoryItem, which are things that can be used by player). MoveAllowed, Height renamed to MoveCollision, HeightCollision, consistent with SegmentCollision, BoxCollision and such. These check collision of other things with current 3D object (current T3D instance). Rename MyMoveAllowed, MyHeight to just MoveAllowed, Height etc. These check collision of point belonging to current 3D object with everything else (with the whole World, except current 3D object). [Less] |
||||||
|
Posted
9 months
ago
The work on the next Castle Game Engine version continues :) Looking at the size of the improvements, next version will deserve the new major number 4.0.0 (even though last version was 3.0.0). We have almost finished new engine features planned for
... [More]
the next version, and we have a lot of new documentation.
Diagram (as a text file...) of the most important "Castle Game Engine" classes is available. I may try to squeeze this into a real image (maybe just the important boxes, and add the text on a normal HTML page). If you have experience with some diagram-drawing tools (like Dia or other open-source tool) I would appreciate contributions here (send them through forum or e-mail to Michalis). "Castle Game Engine" draft tutorial is getting larger and larger (15 chapters now). Short documentation for index.xml files used by "Castle Game Engine" to define levels, creatures and items is also available. Tutorial and classes diagram describe in details how these index.xml files work. People interested in creating MODs for your games will appreciate them, as they allow to add levels, creatures and items by simply adding subdirectories to game data. New engine units since last news: New CastleLevel unit to find game levels (index.xml files), load them, scanning 3D level file for placeholders defining initial creatures/items, and integrating with player. New CastlePlayer unit to manage a central player object, with an inventory, footsteps sound, swimming and so on. This unit will probably shrink a little in the future, as most of it's functionality should also be available for creatures. New CastleItems unit to define items (things that you can use in a game, like a sword or a life potion or a key). Item is a TItem instance, that refers to a corresponding TItemKind instance, referenced by TItem.Kind. This is similar to how you define creatures (see previous news post about CastleCreatures unit), in that we have a separate class for an item and for item kind. A little complication here is that TItem is not a 3D object (it cannot be directly added to the level), instead you have to use TItem.PutOnLevel to get TItemOnLevel instance. New CastleInputs unit, centralized keymap handling, detecting key conflicts and such. Other changes, noticeable in view3dscene or next "The Castle" data: In view3dscene "Help -> Selected Object Information", show Blender object/mesh name. Handle beamWidth --> GL_SPOT_EXPONENT translation similar to Xj3D: OpenGL spot exponent is 0.5 / max(beamWidth, epsilon) (unless beamWidth >= cutOffAngle, then spot exponent is always zero). This allows to at least influence drop off rate with beamWidth, and gives precise conversion from VRML 1.0 dropOffRate -> VRML 2/X3D beamWidth. See engine internals doc about OpenGL rendering (sorry, just DocBook source now) for details. CastleScript writeln() can be used in games to make notifications. Also CastleScript shortcut() is now available, to show user the value of some key shortcut. See CastleScript SVN docs for details. This allows "The Castle" levels (and future Castle2) levels to make notifications using more standard X3D mechanisms: they now use ProximitySensor + CastleScript to show hints, instead of our custom invention. See e.g. cages level X3D source to see how it looks like. Our "thunder" effect (blinking light and some sound), used previously in "cages" level of castle1 and lets_take_a_walk, is now remade as pure X3D prototype. This means it's simpler, more configurable, and doesn't use a single line of ObjectPascal code :) See it's implementation here: thunder.x3dv, examples how it's used are at the bottom of base.wrl and cages_final.x3dv. examples/3d_sound_game/lets_take_a_walk uses CastleLevel, as a first demo (besides the castle1 game). New view3dscene menu item "Remove placeholder nodes from "Castle Game Engine" levels", a general way to remove some specially-named nodes (see castle development doc for reference of most of them, see sources for all). Removed previous castle-process-3d-model.lpr, it was uncomfortable and didn't really prove useful. Implement TCastleWindowBase.RedBits, GreenBits, BlueBits, in addition to making ColorBits cross-platform and sensible (reads/writes RGB properties). glinformation gets --red-bits etc. options. Comfortable TCastleWindowBase.AntiAliasing property, instead of previous GLAntiAliasing unit. You can now simply use TCastleWindowBase.AntiAliasing instead of TCastleWindowBase.MultiSampling for a little higher-level approach for MSAA. Oh, and since I just don't have any interesting screenshots for this news item (mostly code changes, interesting for developers...), the side of this news post contains just some best movies from the previous news in this year, possible thanks to Jan Adamec (RoomArranger, 3D mouse, SSAO) and Victor Amat (water with caustics). Thanks again! [Less] |
||||||
|
Posted
11 months
ago
Hi! Here are the latest news from the development of our engine and view3dscene:
Let's start with something shiny :) Victor Amat send me a demo of water with very nice caustics using our shadows and shaders and other VRML/X3D ... [More] features. Be sure to switch to HD and fullscreen, for best quality: This model shows a German Pavillion in the Universal Expo of Barcelona of 1929. The video shows a quick walk around the model in view3dscene, showing reflections and caustics visible above and under the water. We also show that all screen effects, like Screen Space Ambient Occlusion, work now with shadow volumes without problems :) Lights editor is available in view3dscene. Use the menu "Edit -> Lights Editor" to bring it on. It allows to interactively adjust a lot of lights settings. The scene is not paused — you can still trigger animations, walk around and generally do everything while you tweak lights settings. Of course you can try it right now by using view3dscene from snapshots. A lot of light parameters can be adjusted by comfortable sliders. My main motivation for implementing this was that light settings are usually hard to get perfect using an external modeller, like Blender, where light parameters do not precisely match the VRML/X3D concepts. Basic shadows settings (by shadow maps or shadow volumes) are also configurable using this. In particular try out the "Shadows (Easy: Shadow Maps)" setting (not for PointLight), it just works on an arbitrary scene. I hope that this will also make our dynamic shadows algorithms more discoverable :) Note: turn on per-pixel lighting by using "Shaders->Enable For Everything" menu item to see perfect lights results, this may be necessary to make local light effects really stand out. (See also the Shape.shading="PHONG" extension below to mark inside your X3D file that some shapes should use this look by default.) This is a tool for tweaking lights, not for designing them from the start. There's no option to add a new light, you can only change existing light sources. There's also no option to delete a light, although you can always disable light by setting "On" value to "No". This is a much cleaned up and improved lights editor that was previously available in our "The Castle" debug menu. It allowed us to make some nice light effects in "The Castle" levels, now it's available for arbitrary 3D models :) Of course you can save the edited VRML/X3D file back on disk by "File -> Save..." menu items from view3dscene. We have implemented a simple Shape.shading extension, allows you to force Phong shading for a particular shape. Problems with cube maps on Intel GPU on Windows workarounded: for Intel HD 4000, generating cube maps is broken, so don't do it. For other models, use glCopyTexSubImage instead of FBO. Also, glGenerateMipmap is either crashing or broken (makes black/random contents) on this GPU, so don't use mipmaps for cube maps. view3dscene menu item "Display -> Show Controls on Screenshots". Shadow volumes cooperate now with screen effects that read depth (like SSAO). Previous implementation had problems because on GPUs with packed depth+stencil (pretty much all existing GPUs? I didn't see a GPU without it...) you cannot just create depth texture and separate stencil buffer for FBO, instead you have to create special texture that contains both depth+stencil. And that's what we do now :) For shadow volumes to work, your 3D models must now be perfect 2-manifold. No border edges (view3dscene "Help -> Manifold Edges Information" must say "0 border edges", and "View -> Fill Mode -> Silhouette And Border Edges" must show only yellow edges — no blue egdes). Previously, allowing models with some border edges to be used as shadow volumes casters was an endless source of artifacts. And to avoid these artifacts, some parts of the castle1 were using CastShadowVolumes = false by default, effectively disallowing engine to automatically detect should shadow volumes be used (are border edges 0). I think it's cleaner to just require 2-manifold models (as they were in practice required already for bug-free shadow volumes, it just wasn't enforced by the engine), and do something safe (instead of weird rendering artifacts) for other models. Yes, this may force you to fix your 3D models. If you really really miss old non-perfect-manifold rendering, please report, we can make an option re-enable it. But we would really like to encourage people to instead fix models to be perfect manifolds. Remember that you can mark some shapes as not shadow casters to avoid considering them at all in the manifold/border edges set. Only the shapes that sum into a 2-manifold should have shadowCaster = true. Engine improvements for programmers: SoundEngine is now always TXmlSoundEngine, and some engine components (like OnScreenMenu) use sounds out of the box. You only have to initialize SoundEngine.SoundsXmlFileName at some point, and create appropriate XML file and sound files. New approach to saving user preferences, see new CastleConfig unit, used throughout the engine components. New CastleTextureProperties unit, to assign footsteps sound and damage to textures in games. [Less] |
||||||
|
Posted
12 months
ago
Hi!
First of all, we had a plan to release new shiny engine version at the end of May — sorry everyone, as you can see, we failed to make it on time. The work is progressing nicely (more details below), but there's just ... [More] never enough time to finish it. So, sorry, everything has to be delayed a little further. (And if you would like to help: we have a list of things you can do to help (not all of them require experience with programming), and donating is very appreciated (as it allows me to spend more time on the engine development, instead of on various freelance jobs). Thanks in advance!) New features done lately: Engine contains now the promised CastleCreatures unit (see inside src/game/ subdirectory in SVN), that allows you to easily create creatures with artificial intelligence. (For details see initial docs and castlecreatures.pas source.) There are various ways to use it: For starters, you can just use the walk-attack-state intelligence, by the TWalkAttackCreatureKind class. Such creature tracks the player (remembers last seen player 3D position, walks/flies to it, possibly through sectors/waypoints — so it can pass through narrow doors in a labyrinth or walk over a narrow bridge), attacks the player from the right distance (this can be either a melee attack, or shooting a missile — which adds a missile to the 3D world), eventually runs from the player (when he's too close and/or our health is low). For now, the player is always the main enemy, and there's no "creature vs creature" fighting, although it can be added easily in the future. For basic usage, there's no need to even derive new classes. All you need to do is to create a directory holding creature 3D data and index.xml describing it (for example, see various subdirectories of castle/data/creatures/ in SVN). There are a lot of settings to achieve particular behavior, e.g. cowardly/brave, offensive/defensive, melee/ranged, etc. There is also a "missile" intelligence (TMissileCreatureKind), that causes the creature to blindly go in given direction (possibly with gravity and/or homing (close-on-target) features). On impact, missile may explode, hurting player and/or other creatures. Any kind of missile, like arrow or lighting bolt, is represented as such "missile creature", that flies independently of the shooter. You can also derive simple descendants of above classes, to customize their behavior. For example, "The Castle" customizes walk-attack creature to give both ranged and melee attacks to the Spider Queen, to make werewolves howl from time to time, and such. See castle1 GameCreatures.pas unit sources. We plan to add a simple FPS game to the engine examples, to illustrate this nicer. Finally, nothing stops you from taking basic TCreatureKind, or even the more basic T3DAlive class, and add an intelligence there. Methods MyMove, MyMoveAllowed, MyHeight, MyLineOfSight allow you to add any kind of movement/intelligence to any 3D object. See Base3D unit and classes there. We also have CastleResources unit (for reference-counted, heavy 3D resources) and other new units in the src/game/ subdirectory. This achieves the major goal for the next engine version :) But there's still more work — we want to have there also (pickable) items, advanced player management, and advanced level loading. This is all already implemented in castle1 source, but we still need to generalize and clean up the code. Jan Adamec started implementation of a new camera navigation method, called Architecture now. The idea is to create a more constrained Examine mode, suitable for viewing models with a ground/floor, where you don't want to accidentally flip the model upside-down. The new navigation mode is already available on view3dscene header (take view3dscene binary from snapshots), it's also available for VRML/X3D models by NavigationInfo.type="ARCHITECTURE". Remember it's a work in progress for now, the behavior will change. Some more screenshots of Room Arranger scenes with Screen Space Ambient Occlusion, and more screenshots of triangulating of non-trivial polygons, are visible on the side of this post. See previous news for details about these features. Fractals demo using our engine (TCastleWindow and such) is available on github: github.com/michaliskambi/fractals-demo-cge. The code is GPL >= 2, by Michalis. Partially, I set this up to play with github :) But it also shows one way to distribute a code of a game/utility using our engine. You can look at README.txt, Lazarus lpi, and compilation scripts there as an example. lets_take_a_walk, demo of 3D sounds inside our engine, was refreshed (to use T3D classes) and added as another example to our engine sources (under castle_game_engine/examples/3d_sound_game/). Added comments about sponsoring, and links to FOSS Factory and Gun.io to our donations page. Lazarus TOpenGLControl component got quite a few improvements in Lazarus SVN, thanks to the work of Michalis, Jan Adamec and Andrey Zubarev: MultiSampling, AlphaBits, DepthBits, StencilBits, AUX buffers. This is an ancestor of our TCastleControl component, so all these improvements are directly useful also inside our engine. Other small fixes/updates: Workaround for NVidia GLSL bugs on "const in gl_XxxParameters". RenderedTexture.viewpoint fixed to send camera*Matrix events. Updated Windows DLLs to latest versions from gnuwin32.sourceforge.net: zlib upgraded to 1.2.3 (last change 20 July 2005), libpng upgraded to(1.2.37 (last change 4 June 2009). [Less] |
||||||
|
Posted
about 1 year
ago
Hi everyone! We have a lot of news about new features and improvements in our engine and view3dscene. No new release yet, we just announce what is available in SVN (and can be tested by downloading view3dscene from snapshots). I really
... [More]
have to start making these news posts more often, otherwise they get ridiculously long, well.. as long as this one :)
Oh, and before we start: if you like seeing the engine grow so much, please consider donating. I really appreciate it, especially as I plan to spend next year without a regular job, focusing mostly on the development of "Castle 2", a new great open-source game using our engine. Features and improvements implemented in the last months: First of all, great news — we have new developer working on our engine: Jan Adamec. He's also the author of Room Arranger, a shareware program to design your room, apartment, house and more. The next version will use our engine for the internal viewer of generated VRML models :) Here' a movie of our engine used to render a house model from RoomArranger: Thanks to Jan Adamec, we have a lot of new features and improvements to navigation in Walk/Fly modes: We support 3D mouse devices in all our tools (like view3dscene and all engine examples, games etc.). Only under Windows for now — contributions for other OSes are welcome, of course. The video below shows how 3D mouse works in various navigation modes: Navigation by mouse dragging is now possible in Walk/Fly modes (similar to other VRML/X3D viewers). Drag with left mouse button to move forward, backward and rotate. Drag with right mouse button to move sideways (strafe) and fly up/down. Holding Shift during movement allows to run (speed increases * 2). Mouse wheel (look up / down) works for cameras inside Lazarus control (just like in TCastleWindow). This nice screen summarizes most new controls used in Walk/Fly modes: Also thanks to Jan Adamec, we have Screen Space Ambient Occlusion implemented inside our engine. Available as comfortable view3dscene menu item "View -> Screen Effects -> Screen Space Ambient Occlusion" (for developers: TCastleAbstractViewport.ScreenSpaceAmbientOcclusion.) Works on arbitrary models out-of-the-box :) Uses our screen effects framework. Screen effects cooperate now wit multi-sampling (anti-aliasing). Previously, any screen effect (like SSAO, or view3dscene effects, or effects in VRML/X3D files like demo_models/screen_effects/ from demo models) was disabling anti-aliasing. Now we can use OpenGL ARB_texture_multisample to have multi-sample textures used with screen effects. The GLSL code of every screen effect is linked with some helper screen_xxx functions. If you use them, your effects will work both with and without multi-sampling. The new functions are documented in future Screen Effects docs (this will replace the current Screen Effects docs at the next release). All existing engine effects, like SSAO and other view3dscene effects in "View->Screen Effects", are already ported to use scene_xxx functions and cooperate with anti-aliasing. Triangulator fixes for complicated concave polygons. Various fixes to account for duplicated vertexes and (more general) collinear triangles inside polygon. Previously, they could cause problems, with normal vectors of polygon and ears determined incorrectly, and allowing invalid non-empty ear triangles. The video below visualizes how our simple triangulation algorithm (by ear clipping) works: X3D 3.3 handling. See X3D 3.3 specification for details. UNIT statement handled (in both classic and XML encoding), see demo_models/x3d/units*. Angle and length conversion is actually done. For example, you can now express angles in degrees by simple declaration at the beginning of X3D file. This affects interpretation of these fields: all SFRotation, MFRotation all creaseAngle TextureTransform.rotation Background.skyAngle,groundAngle Arc2D.startAngle,endAngle ArcClose2D.startAngle,endAngle Length conversion is also possible. This is less useful IMHO — you can as well just wrap your model in a Transform with some scale. Actually, that's exactly our implementation of "UNIT length" for now — we simply add appropriate scale (calculated looking at length unit of inlined model (inner), and looking at length unit of inlining model (outer)). MetadataBoolean node added. GravityPhysicsModelNode renamed to ForcePhysicsModelNode (spec was mistakenly confusing these two names). (Only parsing.) Added SliderJoint.sliderForce (Only parsing.) DISEntityTypeMapping has X3DUrlObject as ancestor (Only parsing.) The only relevant thing still missing from full X3D 3.3 implementation is the new, very exciting for me, Volume rendering component. I would like to tackle it at some point, as it may be quite fun, impressive and useful. (But no deadline yet, so if you're really interested in seeing it implemented — contact me, patches are welcome :) Victor Amat send us some very nice 3D model of German Pavillion in the Universal Expo of Barcelona of 1929, see the screenshots on the right, with very nice water and reflections. And, also from Victor Amat, a nice soft shadows demo based on shadow maps. It's an adaptation from nVidia SDK 9, but using a PoissonDisk sampler instead of a jittered grid pattern. You can see a screenshot from it on the side. The source X3D file is inside demo models SVN, see subdirectory demo_models/shadow_maps/soft_shadow_poisson_sampling/. Thousand thanks! The X3D feature to specify height of the tallest object you can climb inside NavigationInfo.avatarSize[2] field is now correctly supported. The demo model is inside demo models (open demo_models/navigation/avatar_climb_stairs.x3dv; only in SVN for now, until next release). VisibilitySensor node is implemented (looking only at frustum for now). See the testcase sensors_environmental/visibility_sensor.x3dv in demo models SVN. The speed of Examine rotation by keys is now capped at a maximum constant, to prevent accidentally making wildly fast (and, as such, useless and confusing) rotations. view3dscene gets the "Screenshot" button on the toolbar (as it's an often used feature). Making a screenshot in view3dscene doesn't capture GUI controls (like toolbar buttons). Previously, it was inconsistent, e.g. "movie screenshot" was not capturing toolbar but "single image screenshot" was capturing them (unless it was initiated from command-line...). The general rule now is: screenshot avoids the buttons, visualizations (bounding box), and such. You can always capture a screenshot using external application, with window frames and all features you want. view3dscene screenshot's purpose is to capture your scene — not any GUI cruft. Our Blender X3D exporter updated to be compatible to Blender 2.62 (and as close as possible to distributed original Blender exporter). Memory and speed optimizations for scenes with many shapes (iteration by "is nested" callbacks instead of temporary lists, better opaque/transparent detection and more). Also, Lazarus package settings are now more suitable for production use (no assertions, no range/overflow checks, optimization level = 2). This also causes an upgrade of our requirements for FPC version: we require now FPC >= 2.6.0. We need the "is nested" feature, which I like a lot — it allows to utilize callbacks in more places, making things like traversing various trees more optimized and at the same time comfortable. Developers: A lot of T3D class improvements to unify collision detection for all 3D objects. We now make all collision checks (every 3D object vs all others) go through exactly the same methods and look at the same properties. Of course you can customize it (e.g. player may not want to collide with items, to allow picking up items by stepping on them), but it's all uniform in the base T3D class. Previously, various collisions in "The Castle" (player vs level/creatures/items, creature vs level/other creatures/player etc.) had specialized hacky code. Also more useful base 3D objects, transformed in more ways, aware of the world around them. The idea is to move "Castle 1" creatures AI to the engine, to make it trivial to use creature AI in your own games. I want to allow both using existing AI (like our walk-attack state AI), and easy designing of your own AI for specific game needs. Details: New T3DMoving, T3DLinearMoving classes, and T3D.Pushable property: perfect for implementing elevators, moving platforms, and anything else than can move and push other players/creatures/items. New T3DOrient, to orient any 3D models to given position/direction/up. Good for things that have a sense of up and direction, like creatures and player avatar. Since player descends from T3DOrient, it's now trivial to position 3D items relatively to player. Both "Castle 1" weapons are now always displayed in 3D (when attacking or not), this simplifies a lot previous code. New T3DAlive class, for keeping track of things that have life/maxlife and can be hurt (with a possible knockback effect). Methods like MyMove, MyHeight and MyMoveAllowed, to easily check your own collision vs the rest of the world. The idea is that you can trivially derive new classes from T3DTransform or T3DOrient (T3DAlive any many others descend from T3DOrient too), and use MyHeight and MyMoveAllowed to implement your own artificial intelligence. It's very easy now. TCastleSceneManager.Player property, to guide camera (for 1st perspective view) and to be a target for hostile creatures (if you use default AI in CastleCreatures). Both walk-attack and missile creatures get a uniform FallingDownSpeed (units per second) property. Many other unifications and simplifications to creature, players, items handling. Developers: a lot of improvements to game data handling, to make developing new games (like "Castle 2") more comfortable. XML sounds/index.xml file improvements: now you can add new sounds to the game (castle, and future castle2) merely by adding them to necessary XML files. No need to reference the sound from ObjectPascal code. KAnim usage in "The Castle" improved: all castle animations are now separate kanim files, and can be browsed e.g. by view3dscene. "Castle 2" will not use kanim at all. T3DResource class, which can be loaded with reference-counting. This is a much generalized and reworked previous castle TObjectKind class. XML files for each creature, item and level and now separate. The idea is to allow you to add things such as a new creature, new item, and new level to the game data without the need to recompile or to edit any central "index" file. You just add some subdirectories with index.xml files inside, and the game automatically picks them up. See documentation of index.xml files in castle data. Developers: picking improvements with T3D hierarchy: unified "The Castle" style of picking, common to FPS games (pressing the "e" button when looking at item, stateless interaction with 3D items) with VRML/X3D pointer sensors (operating with TouchSensors and drag sensors, that is stateful, tracks isOver/isActive and generally more powerful). Now it all goes through T3D.PointingDeviceActivate/Move, that can be overridden at each T3D. The user-visible benefit from this is that you can now pick creatures to see their name and health status. (Press "e" (interact key) to see info about creature or item at the center of the screen.) The real benefit is that new games can use picking easily, for more purposes. Developers: camera classes improvements: their input shortcuts are now published (making it possible to customize them from Lazarus object inspector), they do not descend from TUIControl (as you should only use cameras on SceneManager.Camera), TCastleSceneManager.DefaultVisibilityLimit, better Camera.Radius treatment. Developers:Various improvements to example examples/lazarus/model_3d_viewer/, based on Jan Adamec patches: buttons to change navigation mode, to make a screenshot, and nice engine logo. Website stuff: As you may have seen at our header, our small website joined the protests against the bad legislations being pushed lately — pretending to be about anti-piracy, in fact being about censorship and anti-privacy. Stop PIPA and SOPA in USA, Stop ACTA (in Polish) (list of ACTA issues in English here.) Fundry.com (crowdfunding for software) has shut down in March/April. It was one of the ways to donate to our engine, where you could donate to a development of a particular feature (suggested by you or someone else). It's sad that the site bankrupted, as I liked the idea very much (even if my particular project didn't yet earn anything this way). Fortunately, I found quite a few alternatives for crowdfunding specifically for FOSS projects: fossfactory.org gun.io elveos.org (it seems the guys are looking for someone to take over the website, or to close it down... So it's probably not a good idea to jump on it now.) If you have any experience with these sites and would like to suggest some of them (or others), please share on our forum :) [Less] |
||||||
Code Data
SCM Data
Community Data
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.