Karsten_

When you are done, you feed your brushes to the BSP compiler that took all the plane definitions that made up a brush, and spit out a quake level.

You do not need to send it to a bsp compiler. You can export it straight to .OBJ (or load in the .map directly if you write a parser and tackle the plane equations) i.e.

http://www.katsbits.com/tutorials/idtech/make-models-from-bsp-maps-or-brushes-advanced.php#gtk15

You could only create shapes that were legal in the games it was made to edit

The outdoor areas in Doom 3 were made in an older version of Radiant and they are probably still better than the majority of levels created by indie developers using any other tool.

You cannot easily change that just because radiant is OSS.

Of course you can. It has brush, face, winding, vertex structs which can easily be used / modified for pretty much any task I would likely perform if I was using blender for making maps. The code is also relatively structured and flexible so anyone with knowledge in C++ can tweak it.

Anyway, what would you suggest instead? A non-artist spends weeks learning something like 3DS Max or Maya? I dont know if this is some snobbery or what but if a developer wants to make a game without any experience in art, this old ID editor is still one of the easiest routes to take for artwork that is good enough for most indie games.

Anyways, this is off topic to the thread so I am going to stop here. I would just like to state that the tools used to create older AAA games (like Quake III) should certainly not be ignored by indie developers because they in most cases still provide greater functionality than required.

These errors look like the .lib files dont contain all the required symbols (but do contain some) so I assume the rest are found in the .dll file.

So, if I recall from my experience with wxWidgets, you need to define "WXUSINGLDLL".

The setup.h *should* contain this, but unfortunately is quite fiddly on Windows using Visual C++ for some reason and doesn't always seem to be correct by default (especially with the recent binaries).

So basically add /D"WXUSINGDLL" to the command line flags (or in the IDE settings) and rebuild your project.

I don't know why you would want to drag in a big OBJ brush mesh

I dont know if you have used *Radiant, but it is split up into multiple smaller meshes if required.

and then have to rebuild it from scratch in a proper scale (so lighting and physics work accurately with a proper meters based unit scale). Why do something wrong so you can go back and do it right later?

Though you find open-source an "irrelevant implementation detail", because Radiant is open-source, it is very easy change the scale that the exporter saves the .obj file as. (Though you will need to be able to compile the thing and thus have a fair knowledge of C and C++ rather than just a scripting language).

I also used to live in the BUILD editor...

Would be pretty good if it exported to .obj.

Tbh, any tool that makes it easy for a non artist to get their ideas across is good. Afterall, Maps can't be build in Unity alone.

Irrilict was a mess. Nothing worked very well. Basically made by a group of guys who just copied everything Quake2 did. Anytime you see an engine, and all the supported functionality revolves around what quake did, and quake file formats AVOID AT ALL COSTS! Forum is full of 'tard know-it-all, OSS zealots, who can't help you with anything when it comes to making games.

This is a tad unfair. Admittedly I do find the API a little messy and fiddly but it is good enough to get you started quickly with cross platform C++ games development. Something that UDK and Unity can't really achieve to the same extent (being closed source).

GTKRadiant (which is on the list) is not a good editor in 2013

Lol, I perhaps agree, but it also shouldn't be overlooked completely. Especially for coders who have no time to learn a full on modelling tool. Plus with the 1.5 version, it can export a map to Wavefront .OBJ making it quite acceptable for blocking out the majority of my level.

Usually IDEs deal with this sort of thing using .d files.

 

Basically when you change a header and add something like an std::string to it, you really should compile every unit (.cpp file) that has a dependence on that header.

 

I believe this is because otherwise the space for the new variable is not reserved properly from those objects.

 

I have this issue when using Makefiles but rather than fix the issue (making the build system quite a bit more complex), I just detect whether a header has changed and rebuild the whole thing.

Rather than outputing to an intermediate file, why not add the messages to a std::vector?
Then just display the last 10 lines or so or delete the first one until the length is less than 10 messages.

Also, rather than using Windows GUI components to display the messages, perhaps just make the messages draw to the screen as basic bitmap fonts or something. Have a basic boolean to toggle when you press the '`' key to specify if to draw the console or not every game loop.

For the console in a couple of my games, I simply display lines of a log (rather than using std::cout) so it can display on an Android device easily.

For writing commands, I simply send the message to all of my ingame objects in the hope that one of them intercepts the message and can react / respond to it.

But depending on what API / engine you are using, it really isn't too hard to implement bespoke rather than dragging in some other project and rigging it up.

If you want a single file for your users to click and run, perhaps you can look into tools like WinRAR that can create self-extracting .exe files.

 

This way it will silently extract to a temp directory, run the game and then clean up afterwards. I does work quite well unless the game is massive.

 

For UNIX you can do similar with something like makeself (http://megastep.org/makeself/).

 

This system pretty much works using any language, i.e you could include the whole java runtime or python environment. (Though it might be a bit large or take a tad longer to extract).

 

I did try it with Java and WinRAR a while back.. and it does work suprisingly well.

When teaching students header management, I always go through a few rules.

Always forward declare rather than including a header to a class unless...

1) The class inherits from the other class.
2) The class contains the other class (Not a pointer!)
3) The class contains (including a pointer) something from the standard library. (i.e std::string, std::string*)

This should get round the looping issue. Especially if you remember that two classes can never contain one another. One will have to only contain a pointer to the other (rule 2).

Also... beware of smart pointers. The deleter function in it will need more than just a forward declare. In this case make sure the class containing the smart pointer contains a destructor and the full header is included in the .cpp file. (A bit messy, but thats life...)

1. Investment. A lot of time has gone into writing C++ code, so it has inertia. The same thing held true of C in years past, and assembly in the era before that.

C and Assembly are still around and are still as strong as ever. These types of languages don't disappear or get swayed by trends.

2. Vendor lock. Most platforms for games only support C/C++ and maybe a couple other languages peripherally.

In practice it is the other way. Everyone makes libraries in C/C++ so they can be consumed by C# or Java developers. Whereas it simply cannot work the other way. Standard Java cannot use C# libraries. Standard C# cannot use Java libraries. And yet they can all use C/C++ libraries. Standard C++ (because of it's powerful low level functionality) can just about use C# libraries if you embed a mono runtime in it.. but not many people are going to do that.

Also, which Vendor is it that is trying to lock you in with C++? It is perhaps an example of one of the few languages which dont have a single company governing it's standard. Unlike Java or C#.

C++ is not a good language. It isn't even a decent language, for the most part. It's old, crufty, ugly, broken, and woefully behind the times (although C++11 is a good forward step). It is absolutely not succeeding on its inherent merits these days.

It has a lot of legacy cruft, I agree (like OpenGL I guess) but when a successful language has been around as long as C++, it can't be helped. The biggest thing for me though is RAII. It is simply missing in all other languages but Ada and is crucial if we have exceptions. C# stuff like LINQ.. I simply couldnt care less about for gamesdev.

More people are leaving C++ for game development, and with good reason.

Not really. Admittedly Gamedev.net does has a large presence of managed language fans, and there are reasons for this but as you know, in the commercial world (no indie crap or vendor lockin to products such as XNA and Unity) C++ is the only language quite frankly.
As for Android and iOS... It is simple, all the commercial games (especially ports) from AAA studios use C++ (with small Java/Obj-C shims) and all the hobby / indie developers use MonoTouch or the specific platform's lockin languages.

All the wishy-washy nonsense about performance and low-level access and blah blah blah

I agree. Especially since this isn't so much about the language but the platform. DotGNU (native C#) would beat C++.NET hands down in speed.

There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;)

Except that shaders *are* compiled into intermediate code for distribution, or distributed as source. Its the graphics card driver that takes the IL or source code and produces GPU-specific hardware instructions.

I did specifically say runtime (after all, most software is distributed in text form on UNIX). Though in some of the later specs of OpenGL, apparently you can use compiled (native) code rather than compiling it up from source at runtime.

Basically, if the shaders were JIT compiled as they were being used rather than being compiled natively up front. It is highly likely you would get worse performance. This is exactly the same with .NET.

For example, Assembly is more closer to the computer, but that does not necessarily mean it will be better

Except that C compilers (especially optimizing ones) *do* produce better ASM than a human (if asked to with -S in gcc). Whereas C# simply runs ontop of another (large) layer of software so can only ever be slower. It doesn't bring anything to the table speed wise. The only thing it (ahem.. Java) brought to the table was a (flawed) non-deterministic memory management system.

You can create fast games with vm languages... Just not as fast as native code... obviously

There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;) </troll>

On a more useful note...

@nimrodson, can you tell us why you can't get to grips with C++? Perhaps you should use a higher level library (like you would generally be forced to when using C# or Java).

If you use something like Irrlicht (with C++) or Irrlicht.NET (with C#), they should both be very similar in difficulty.

(Though unfortunately like most .NET bindings (XNA included) the Irrlicht.NET is quite unmaintained.)

I would suggest teaching them using whatever language / platform they can easily get set up and running on their home computers so they can start practising / having fun at home.

 

Java or (dare I say it...) Visual Basic 6 which comes with Microsoft Office is a great one for teaching.

 

Then when they are ready for a language that they can learn and use for life... ween them slowly onto C++. ;)

 (And it's normally < 100 lines of code)

I highly doubt that since native functions provided by most operating systems dont implement any sort of packet division. Thats basically sth one has to do himself or use a library.

To be honest, it is about this number of lines, remember that the server and client in most examples also duplicate some code, (on the reading and sending).

 

What I suggest is to create your own socket wrapper because it will ultimately simplifiy things and then allows you to solve things in an encapsulated manner (i.e how you deal with Nagle's algorithm etc...)

 

The great thing about network programming is that it isn't too hard. (Unless I assume, you get to MMORPG levels of things ;)

If you think coding a game is hard... Coding a game making tool is often much harder (or certainly less fun) unfortunately.

 

Perhaps instead modify other tools (such as GtkRadiant) to do your bidding for you. Perhaps even tailor your game's code to be able to read assets given out by existing editors (even though it may not be an ideal format).

 

I often reimplement closed source tools so I can use them on UNIX... and speaking from experience, developing tools is as boring as sin!

 

There is a reason why the internal tools at a game development company are so flakey... It is because no-one wants to spend time fixing them lol.