Hello. It's been a while. So, I was wondering how the development of FreeBuild/TBG is going. There hasn't been any updates regarding the game for a while and I am a bit sceptical if the game is even being made. I know Elfprince is a busy guy, so I don't expect anything big from him.



[edit by elfprince for archival purposes, since this thread has been repurposed a bit]
Earlier develppment logs can be found:

• 1.5 pre-alpha era
  
• 1.5 alpah era
  
• Switch to Torque3D era
  

There's a decent bit of crossover between those threads because people were posting all over the place, but the dates listed are when they were started.
[end of elfprince's edit]

Busy recruiting with the GameDevs group here at Brown. If you want it faster, I welcome the help.

He's also working on a PhD, so it's not like he has an abundance of free time.

Got one, possibly two, interested parties at this weekend's BGD meeting. Also got some coding done today.

I have a new LDraw model parser based on ANTLR4, and added in support for the BFC language extensions which I didn't have configured in my grammar for the Torque based parser. Also got more work done on the new preferences system to support loading of hierarchical configuration files from pure Python data structures. The next step is LDraw directory verification, then the caching, then model loading and rendering. I also have the necessary framebuffers set up for my inferred rendering pipeline, but nothing to do with them until I have LDraw models loaded with normal-group IDs. The infrastructure for the multiplexed console logging system is also functioning and in place.

Roadmap after that looks fuzzy but something like
* Functioning UI layer
* Networking + Physics
* Culling
* Gameplay??

Also, I don't know if I mentioned this officially yet, but I'm now using Scala/Jython (and a smidgen of Java that is slowly being phased out), instead of C++/Boost+Python. I'm coding much more rapidly, and it should be more accessible for other people to help, though I'll have to update the GitHub accordingly. Also, JVM garbage collection is mature enough that well designed code shouldn't have to worry about stalling like it would in most other managed-memory environments.

At this point the only thing required for porting/cross platform support is the implementation of 5 or 6 C functions that I call through JNA to get information about platform-native folders and storage for applications to write to. The Windows and generic Unix code could actually have been done in pure JNA, but the "right way" to do it on OS X required calling Objective-C, which I didn't want to deal with through JNA, so I've separated all of that out into its own library (which I'm calling libcrane, as a some kind of pun about folders/origami). The OS X implementation is only 85 loc, and 6 functions, so this shouldn't be much of a burden on porting efforts.

Also, I'm trying to target OpenGL Core Profile 3.2, so if your card doesn't support that stuff....I'm sorry, but after the research I've done, I don't think there's much chance of having it performant anyway without the 3.2-era functionality I'm using.

[edit]

Oh, and GitHub is updated if anyone wants to poke around.

libcrane is now built for Windows, so there should be no cross-platform dependencies holding you back. I had a working build for Linux earlier today as well, but then may have broke it getting Windows support up tonight. Hopefully I'll have that patched and stable in any freetime tomorrow. Now that the console infrastructure fully in place, back to graphics

(from here)

Currently working on a shader editor within my engine to make it easier to debug the graphics pipeline I'm building.
https://github.com/elfprince13/FreeBuild

Scroll upwards slightly for the current roadmap (the only real update to that is that I've knocked LDraw directory validation off of the checklist).

The most recent set of commits was the result of me rewriting the only 3 or so Java files in my current engine with Scala to unify the codebase. The only Java code that I'm responsible for compiling at this point is the tiny smidgen generated by my ANTLR grammars for LDRAW, since ANTLR doesn't appear to have a Scala target.

Double post, but if anyone cares, here's a screenshot of the result of a few hours work setting up the shader editor.




[edit]
Four hours later:


[edit 2]
And we now have a separate repo: https://github.com/elfprince13/GLSL-Shader-Editor

Screen Shot 2014-01-21 at 10.03.02 PM by elfprince13, on Flickr


Screen Shot 2014-01-21 at 10.03.11 PM by elfprince13, on Flickr


Screen Shot 2014-01-21 at 10.03.18 PM by elfprince13, on Flickr


Screen Shot 2014-01-21 at 10.03.29 PM by elfprince13, on Flickr


Screen Shot 2014-01-21 at 10.03.41 PM by elfprince13, on Flickr

One year later (*cough*):
This is actually more-or-less hooked up to the engine. I still need to work on the editable-pipeline stuff, but shader editing and test-compilation (and hopefully soon test-linking) is up and running. This should make further work on graphics stuff a lot faster, because it will allow for live-testing and live-feedback.

Working on the shader editor made me realize my console / logging infrastructure wasn't quite flexible enough, because I had no way to hijack specific bits of log to redirect into the compilation-output box in the shader editor UI. This handy comparison on GitHub shows the scope of the changes over the last two days (and omits a rather horrid 2 hour debugging session in which the builtin StreamHandler class for logging wasn't actually writing to the streams I gave it, for no apparent reason, since I could see writes firing, and then disappearing somewhere in a stack of JVM system library code without debugging symbols, which resulted in me rolling my own dumbed-down but functional version of the same class)

There was some discussion in the spring/early summer about trying to hook stuff up to Unreal, but like pretty much every existing engine, they have terrible support for networked vehicle physics (link behind a registration/TOS wall). Since this is likely to be the most difficult part of the FreeBuild nut to crack, I decided to start on this back in the JVM engine.

This week I:

1. successfully ripped out the Java bindings for Bullet from libGDX and ran a sim from Scala
   
2. started playing with netty's UDT support to implement a client/server model.
   
3. Went back to reread the necessary algorithmic discussions on client-side prediction.