next »

[knuckles]

I experiment with BSP-format levels. I chose it because it seems mostly universal for almost any kind of game: from FPS to RTS. It's performance oriented, can store arbitrary game entities, supported by popular editors and can be loaded into Xith. For editing I use GtkRadiant.
BTW, before I went too far - is there something better or simpler than BSP for a RPG game level design with an editor available?

As far as I got it BSP levels utilize special texture names to define in-game look and behavior of some objects. For example Quake3 maps use such texture names as "texture/common/caulk", "...nodraw", "...trigger", "...clip" etc. There are no such texture files - hence their specialty. Radiant editor recognizes those and draws them semitransparent (see screenshot). It uses .shader files to setup their look. Quake engine does not draw such objects (however they're structural brushes) at all but rather uses their geometry for other purposes. Xith fills these brushes with its default "check" pattern.
How do I tell Xith (or Jagatoo?) not to draw these brushes and how do I handle them in my game in some arbitrary way?

I also found this code in Jagatoo (BSPEntitiesParser.java) :

Code:

    else if ( classname.startsWith( "trigger_" ) )
    {
        if ( classname.startsWith( "trigger_multiple" ) )
        {
            entity = new BSPEntity_trigger_multiple( classname );
        }
    }

Which seems somehow related to my question. I don't fully understand whether those algo is used only for entities and also why there is no handler for textures starting with "trigger_".

[Marvin Fröhlich]

Maybe this is related to these "BSP shaders", which are actually no shaders, but some kind of textual descriptions for textured objects. JAGaToo and Xith don't currently support them.

[knuckles]

Maybe this is related to these "BSP shaders", which are actually no shaders, but some kind of textual descriptions for textured objects. JAGaToo and Xith don't currently support them.

Any ideas on how to teach Xith this new trick? Is that hard/possible? What classes need to be patched? What will be the architecture behind this?
Or is it better to do some post-processing in the client application? Find all those brushes and modify their Appearance?

[knuckles]

OK, I digged some Xith sources and here's the situation as I see it.
After the initial BSP file is parsed the BSPConverter takes the data, chews it and produces a SceneGraph-enabled structure. During this process it assigns Appearance to each shape for which it uses the AppearanceFactory instance passed by ModelLoader to BSPPrototypeLoader. This looks to me as a  really good place to assign all those surface descriptions to shapes. But this is a game-specific data which cannot be incorporated into a generic library as Jagatoo or Xith. So apparently a right thing is to pass your own shader-aware AppearanceFactory to the BSPPrototypeLoader.
Right now it seems that it is simpler not to patch ModelLoader but rather handle BSP loading in a client application. Like this:

Code:

BSPPrototypeLoader.load( ..., gameAppearanceFactory, ... );

Any comments and advices are welcome. Marvin?

[knuckles]

By the way, BSPConverter already has some form of texture appearance logic:

Code:

boolean isTranslucentTex = ... || ( baseTexName.indexOf( "flame" ) >= 0 ) );

Which is not sufficient nor a flexible solution. IMHO such things should be handled by a game engine, not a BSP loader.

[Marvin Fröhlich]

If BSP shaders really are, what is missing here, then this doesn't need game specific code, but a generic implementation of BSP shader loading in JAGaToo.

If you really need a game specific AppearanceFactory, we might need to trick the ModelLoader to take an instance of it to do loading with it.

[knuckles]

If BSP shaders really are, what is missing here, then this doesn't need game specific code, but a generic implementation of BSP shader loading in JAGaToo.

I don't think they are "BSP shaders". They're rather "Quake3 shaders". BSP format itself seems to have no particular dependency on those. Right now I have no facts of their use in games other than of Q3 engine family.

If you really need a game specific AppearanceFactory, we might need to trick the ModelLoader to take an instance of it to do loading with it.

Well, I did some experiments again with those classes. Here's where I am now. Passing my own AppearanceFactory to the BSP loader is not a problem. I just copied some code from ModelLoader. Don't be scared, this is Scala

Code:

object LocationLoader extends ModelLoaderWrapper {
    def loadLocation (locationURL: URL): Model = {
        val location = new Model()
        BSPPrototypeLoader.load(locationURL.openStream(),
                                LoaderUtils.extractFilenameWithoutExt(locationURL),
                                null,
                                new XithGeometryFactory( Geometry.Optimization.USE_DISPLAY_LISTS ),
                                true, 0.03f,
                                new GameAppearanceFactory,
                                new XithNodeFactory,
                                location, GroupType.BSP_TREE,
                                getSI(location))
        return location;
    }
}

BTW, loading a BSP through ModelLoader is not very useful anyway since BSP models are not as generic as all others and need some special treatment in 90% cases, since they contain much more data than just a model.

So, I had to wrap ModelLoader with another Java subclass to get access to SpecialItemsHandlerImpl, because its protected static and thus inaccessible to Scala object model:

Code:

public class ModelLoaderWrapper extends ModelLoader {
    protected SpecialItemsHandler getSI(Model model) {
        return new SpecialItemsHandlerImpl(model);
    };
}

What's really bad is that I can't subclass neither XithAppearanceFactory nor XithNodeFactory and override their methods because they are all final. The idea is to write my own XithAppearanceFactory.loadOrGetTexture which won't return fallback texture for a missing file if there's a shader description instead. Then in XithNodeFactory.createShape it will be possible to catch those textures and apply appearance properties described by a shader - effectively making a BSP brush invisible or whatever else. It can't be done earlier, because BSPConverter may alter Appearance many times before creating a final shape.
That's the plan. Now I have copy-pasted XithAppearanceFactory (can't override) to make my GameAppearanceFactory and going to make the same with XithNodeFactory. This looks ugly, but I have no better idea . But no modifications to Xith or Jagatoo are totally necessary right now.

[Marvin Fröhlich]

Don't hesitate to change JAGaToo or xith. I can grant you dev access.

[knuckles]

Don't hesitate to change JAGaToo or xith. I can grant you dev access.

I'm afraid this may end up in totally breaking API backward compatibility
But, sure, if I won't give up my pet project, I'll need it sooner or later.

[Marvin Fröhlich]

I need your sourceforge account name then.

[knuckles]

Sent with a PM.

[Marvin Fröhlich]

done