Sorry your browser is not supported!

I thought it would be a good idea to include these requests into the dbw file format, if it is made, as you should always have a plan of everthng you are going to do with things like these:

1.the option for all media that would be external to be Included in the .dbw file.
2.animated textures
3.Entities that can be called upon to give co-ordinates.
4. resizable worlds.
5 the ability to lay small textured planes floating slightly of the map allowing you to make blood spills and flat plain shadows.
6. the ability to grab the positions and properties of up to 8 lights, so that the game objects can be lit in the same way as the dbw.
7.extra space at the end of the file where other data and game and Ai scripts can be stored and called upon by db.
8. A version number in the header of the file so that newer versions of the dbw file can be used, and so the format can be improved.
9. particle positions and properties are included in the file so that particle effects like fires can be used.
10. the ability to use linear collision.
11. areas for object – world collision not to be just spheres or boxes but cones, cylinders, and polygons, and also the ability to write formulas to state the exact shape of the object for collision and portals.
12. the ability to associate sounds with textures, so when a object moves over a surface, db produces the sound associated with that surface, like muffled steps or a clanging sound.
13.Bot tracks to be included in the dbw file for less processor intensive ai.
14.the ability to place 3d sounds and music.

Does anyone want to add anything?

On the points suggested:

1. Not really, I prefer the media outside the file and to keep DBW just for the level data, but I can see some people finding this useful.

2. Agreed

3. I think this would require the DBW world to be divided like this:

[DBW]
- Surfaces - Texture
- Alpha
- Areas - Coords
- Name

I think that rather than having entities, there could be "bookmarks" within the world, so you could mark a position (eg: player start) in an editor and get the coordinates easily in DBP. This is really the programmers job I think.

4. Not sure this is really necessary

5. That is definately the programmers job to do with primitives and so on.

6. I think just basic lighting options are needed, again, this is really work that should be done in the DBA code, not the editor.

7. Quite a good idea actually, although this would duplicate the media inclusion of DBP to an extent.

8. This should be included as a matter of course

9. No - I think that is not information that belongs in the DBW format IMO.

10. Yes, good idea. The collision needs to be better than the current BSP collision.

11. No comment

12. That is the job of the DBA code, not the DBW format.

13. That should be done seperately as well

14. This should also be done in DBA code.

An interesting list, personally I think the following things would be nice:

In the DBW format:

- Direct access to surfaces etc, so their textures can be changed or animated
- Transparency / alpha support
- Support for shaders on surfaces

In DBP

- Ability to construct DBWs from a series of primitives or models
- MAKE MEMBLOCK FROM WORLD, so that the levels can be edited at low level

Oki ... i know this is more speculation at this point cause the team is only "thinkin'" about it

buht here is what i would answer to these...

1. shouldn't be as part of the format, but should have a package format for contained media that it uses.
2. probably will have these in the forms of a sprite format, which you can actually do now within any version of DarkBasic
3. as Entities will no doubt be setup similar to BSP worlds (script language) which your game understands, this will probably be upto you to setup
4. there is no point in this, the whole point in a world if to you give you a genetic size to model to, not the other way around!
5. this will be done with decals which projects textures using sprites rather than using any polygonated model.
6. i doubt that dbw will use lights unless DBS add support for HAL DX9 lights. Look more at using lightmapped lights - you can actually do some quite good effects with dynamic lightmaps.
7. this is a job for the programmers, however if they add entity scripting you should be able to make paths with that
8. it will no doubt have this, but there will be no need to DBS to release that information as it will be predetermined by Pro
9. Again a job for Entity Scripts
10. No doubt the team will be working on a form of collision detection of thier own - and probably allow us to access the world polygon data manually as well so that we can create our own. But expect to use a command like SET DBW COLLISION ON and then check for collision in the same way as present like DBW COLLISION HIT([player],pdbw world number]) that is dependant on IF they add support for multiple worlds, which they probably wont for obvious reasons.
11. this will no doubt be pre-calculated and part of dbw's built in collision.
12. again this is Entity Script domain
13. Bot Paths probably will be precalculated based on the geometry of the dbw, however this is a job for the programmer and Pro
14. this will probably be a standard entity, no doubt put within the SDK to show you howto use the Scripter

I think most of what people want should actually be far from thier grasp ... for low level things like texture projection i think that you should be give access to the DBW memblock (using a second one would be suicide on low memory systems)

giving the users access to the geometry is enough for any needs - everything else should be handled with a scripter language.

shaders for surfaces would be a nice addition though, also scripter language for this would be good (^_^)

no one learns the scripted events (called entities) very well within most of the current BSP formats, but it is one of the best ways to give the users access to something without giving them access to the format itself and actually making the users life much easier