Crowbar - an open-source editor

[NoodleCollie]

I understand your point, but I think I'll be sticking with Qt widgets for a few reasons:

A. The code's already there, complete with signals/slots/events that I'd probably have to re-code if I did everything in OpenGL. It seems stupid not to use it just to save a few megabytes on executable size, plus re-coding would be a very large task.

B. I'm not sure it would fit with the tabbed UI people have been wanting. With the Qt controls, I can stick an OpenGL window into a tabbed window and let Qt deal with the docking, whereas otherwise I'd have to write up a whole tabbing mechanism to work within OpenGL as well.

C. I'm intending to make it easy to extend the editor with plugins, and Qt already has its own plugin system and extensive documentation.

 

[VarietyBook]

I understand your point, but I think I'll be sticking with Qt widgets for a few reasons:

A. The code's already there, complete with signals/slots/events that I'd probably have to re-code if I did everything in OpenGL. It seems stupid not to use it just to save a few megabytes on executable size, plus re-coding would be a very large task.

B. I'm not sure it would fit with the tabbed UI people have been wanting. With the Qt controls, I can stick an OpenGL window into a tabbed window and let Qt deal with the docking, whereas otherwise I'd have to write up a whole tabbing mechanism to work within OpenGL as well.

C. I'm intending to make it easy to extend the editor with plugins, and Qt already has its own plugin system and extensive documentation.

Fair Enough

 

[NoodleCollie]

Note: Apologies for taking fucking ages on the pull requests on GitHub, I've been on holiday and our internet went out for 3 days because of a storm...

 

[NoodleCollie]

A small update:

OpenGL is rendering.


In other news, I've managed to hash something together out of Qt's dock widgets - they're pretty much perfect for the dockable window kind of thing but are usually only allowed to go around the outside of a window and not in the centre. If you set the central widget of a window to null then they can fill it all but the interface is still a bit clunky. I've uploaded a compile here for people to test out if they want to and tell me what they think.

EDIT: Another thing I've been wondering (since we're about at the right stage for me to be thinking about the architecture for it) is what the best way programatically would be for allowing a plugin interface. Ideally I'd like every tool to be a plugin, starting from the very basic things like select, create brush, etc., but I'm unsure about the best way to go about structuring this. From what I've done with SourceMod everything there is very event-driven: something is fired from TF2 like a round start notification, and the plugins hook into this signal and run their custom code when it happens. This seems like a good direction to go in but again, I'm not sure of the nature in which it would relate to an editing program rather than a game which already has all these situations in place to hook into.

I'm probably not explaining myself very well, but if anyone has any input I'd gladly hear it.

 

[Kuzma]

Well, uh, it wont run on my computer. Might be cuz of the fact that I'm on windows 8 :/

 

[stegarootbeer]

You forgot to include at least one DLL. MSVCR110.dll is the one it lists, but there may be others.

 

[henke37]

That's part of the visual studio C runtime. It is a free download.


As for the plugin system, you need to think carefully about the interfaces you expose. They need to be stable, otherwise plugins are going to mangle memory.

More importantly, you need to ensure that the plugins have the data they need. Some data just shouldn't be in a plugin. Doing this wrong leads to dependency hell.

 

[NoodleCollie]

Should I be packaging the VCR DLLs or expecting people to download them? I guess if I left it to a download that would ensure they were up-to-date instead of relying on whichever one came with the editor.

So far with regards to plugins I'd thought of something where a plugin can expose its unique identifier string, name/description/version and such to be registered into the editor when it starts. Then maybe have different callbacks for object selected, mouse clicked in viewport, etc?

 

[henke37]

You should NOT package the dlls. Package the redistributable runtime installer instead.

As for the callbacks, keep in mind the need for plugins to access data in addition to receiving events. A plugin needs access to all the level geometry and all entity definitions. Preferably in a nice and easy to work with way.

 

[Pocket]

Why is it even requiring Visual Studio crap if it uses Qt and OpenGL?

 

[Headhunter09]

Plugins should not be able to keep persistent data of their own. All data should be stored globally (although conceivably plugins can modify in-editor entity definitions that later feed back at compile time).

I think the smart way to go is have low-level event hooks like mouse and key input, GUI events, etc. Then create a higher-level plugin interface that can be built off of (hooks for when an object is selected, or a texture applied, etc).

If a plugin needs to go super-basic, it can, but otherwise can use a set of provided high-level functions.

 

[NoodleCollie]

The compile kit I used was a VS one (because I already has VS2012 installed). I think you can use MinGW so I might start doing so.

 

[henke37]

Why is it even requiring Visual Studio crap if it uses Qt and OpenGL?

You go and implement all the functions the c and c++ languages demand yourself. It is hardly crap. Do you want to write things like malloc, std::shenanigans and friends? The runtime offers a lot of important code.

 

[Pocket]

Source is compiled using Visual Studio. How do they get away with not bundling the Redistributable installer with their games?

 

[deadsource]

Source is compiled using Visual Studio. How do they get away with not bundling the Redistributable installer with their games?

maybe they include it inside their engine? It's all code after all

 

[Ice Crystal]

Source is compiled using Visual Studio. How do they get away with not bundling the Redistributable installer with their games?

I always thought first Source launch demanded an install handled by Steam, like a lot of other games do, but it's been a while since a fresh install so I don't remember well.

 

[henke37]

Steam allows applications to have some preinstall packages that run at before the main application. Such as the framework/runtime/library/whatever installers. Anything that is needed will be installed for you.

If source games need a runtime then the runtime is installed using this.

 

[Pocket]

Source games don't have any kind of first-time install process. In fact, they're just about the only games on Steam that don't. That's why I asked.

 

[Ice Crystal]

If they're just about the only games that don't have a first-time install process, perhaps Valve had Steam do it on installation. If I both made the games and ran the manager, I'd do the same thing.

 

[NoodleCollie]

An update on where I'm at right now - as always, to anyone with 3D rendering experience I'd love to have your input.

I've been looking into the way Hammer renders objects and it looks like every frame the vertex info is passed over to a mesh builder class in the material render system, which builds the mesh for a given brush and renders it. This seems to be a similar way to the way OpenGL used to render objects prior to the newest versions - every frame, you would provide both a list of vertices and a list of indices to the GPU (the indices specifying the elements of the vertex array to render in order) and the GPU would render them. In newer OpenGL versions (3.3 and upwards IIRC) you can specify a vertex buffer object (VBO) which basically means the vertex info is stored physically on the GPU in the high-performance video memory. The good news is that it looks as though with the new OpenGL version we'll be able to get a performance increase by storing the vertex data in VBOs instead of passing it every frame, so hopefully we'll be able to render more and render it faster than in Hammer. The problem is that out of all the material I've been reading on VBOs the vertex data being drawn is unchanging (ie. they've hard-coded a triangle or a cube for demonstration purposes) and so I'm not sure how one might go about creating and managing the VBOs when we're going to have brushes being created and modified left, right and centre. The Qt example creates a VBO when the viewport class is initialised so that may be one way to go about it, but I need to find out more information about how I should be doing it - I can see creating one VBO for the scene might be an option but I don't know how I'd deal with when that memory overflows.