Firstly, I made a patch to SDL2 that blends the alpha and not just the RGB colors. I have to still get a better blending system added, but w/e, it works for now.

Secondly, The RTT system was added, but not used. I will see about expanding it to allow easy usage for many things.

Thirdly, I have animated MD5 mesh loading and drawing. Now, this is all keyframe based and all bone deformations are calculated on the CPU. I can either try to offload this to a geometry shader which would work universally, or I could use CUDA/OpenCL to offload all animated mesh drawing.

I will work on getting some test objects added that will have a custom interface on them in order to test the UI/RTT system. I will also see about lua for these GUIs.

I decided to work on profiling! I have a nice global profiler set up that will keep track of timing critical parts, such as rendering, worker thread timings (for physics and such), networking, etc.. Prints out to a nice structured table. I am already seeing that just rendering an MD5 mesh without any bones is costly compared to my static mesh format (animation also takes a toll, same time as to render it).

I plan on having this profiler keep averages as well so that I can get a good sense on what I need to optimize. For now, I can ignore profiling until the core parts of the code become more complete.

Keep up the great work on this, AHelper! I've been monitoring the thread as you've been posting, but I'm afraid I haven't had too much in the way of constructive contributions to add to it.

Thanks!

I am working on having a Lua script sync data and function calls over a network connection. This is needed since the same scripts on the server (in each map) run on the clients, but execute differently.

For data sync, I am allowing scripts to register tables to be synced over a network. This will be done in the script's init code calling sync functions. On the server, these sync requests will be detected and the script will be given its own 'entitiy'. This 'entity' is just a way used to keep track of any changes and handling the transmission of the data. The client will then listen and sync the tables given data chunks.

For method calls, this will just be used to, say, allow a server script that has been watching other entities in an area to alert a client if any enter or leave.

More Lua coming up! Also will be looking into changing the network code a bit to allow variable-sized packets. Nobody likes a one letter or 1000 letter long message forced to 512 characters.

<edit>

Working on the sync code, I realize that I need a 2 maps of maps to get lua table syncing going. This will not be fun. On a brighter side, I have one week of class and one week of finals, then I will be free to code away non-stop.

Slightly less-related, I can now send messages to all players from the server The clients have no idea what to do, but it is dumped to the terminal.

Made progress syncing Lua tables up with clients. I can now see what data must be sent to a client, get the serialized form and send packets. The client is the next phase, where I need to reverse everything I did for the client side

I am having a bad problem and I will not go to space today.

Why valgrind? Because memory leaks, that's why. On that note, my client leaks about 200KB because of problems in SDL_Mixer/pulseaudio/alsa and in nvidia's libGL and such, my code is fine. On the plus side, my server has yet to have any memory leaking other than 77 bytes from libGL.

Lastly, I finally got a script on the server to store data to a table and have the client see those changes. An example below:
Code:

This will cause the client to start spamming numbers, ever so often getting new values for the table.

I find it odd that I can't find much easily on mixing skeletal animations. I don't think that lerping is ok.

Hmm, blend based on the vertex weight?

Anyways, I have started to work on this again. I mean, I have to get through making models and animating them. Once I get the first few done, I should be ok to power through them. However, this means I need to make the models, rig them, then get code together to 1) Do mixed animations 2) Manual bone control and 3) Pipe this control to lua (for AI and manual control for scripting). I then need to get these models to sync over the net. Next is actually rendering nicely. This requires a stable model format. I am thinking collada is best as I will be able to rely on blender having full support at nearly all times. Then I need to get shading working for them. Oh, and bullet bindings to the animation will be a pain :/

Past that, stuff should breeze by with model creating and coding. Also, I plan to make this game use threading even better (right now, the server uses it for each tick, and it sure does help with 6+ worker threads per frame), as animation seems to need the threading.

Progress!

COLLADA loading in progress! I loaded (I hope) mesh data and I hope it is sane. I just tested in my server, and it seemed happy. None of that is in a map, but that will change once I drop it in one, get some UV mapping, texture linking, etc..

Are you loading models entirely through your own code, or are you using a library like Assimp? Assimp can load .blend files, in addition to many others. That makes development a lot easier, since you can work directly with the mesh files, instead of having to export them as your format on every update. Then when it's time to release your game, batch convert all the .blends to something that saves space, like .3ds or a custom format. That's how I'd do it if I ever got serious about making a 3D game

I think you missed the whole point.



The blender format isn't a set-in-stone format, it has had large changes and I don't know if it has calmed down yet.

I am not exporting as my own format, I am using COLLADA, with built-in export support in blender.

If (Read: when) I have my own format (Read: fully featured format), what's the point of including a library that can't read it?

Instancing system is being made, will need to move over some of my hacked in instances. Then to worry about lights and cameras and such. Then bones. Then getting this in the backend and client :/

Previously, the core of the RED engine was setup to load resources using a resource group to scan all files in a map directory and create individual resources based on the file types. The collection of resources was stored in the group and would then be used by other code to find resources.

Now, the resource group is a front-end to resource packs, collections of resources. Resources now can be packs and contain more resources in them, namely COLLADA and my map format. Previously, the actual objects that were in scenes, like model instances, lights, etc. were using odd classes hiding in my map format resource which was then used by the backend/client to make entities or render. That is now gone with the clear separation of raw data (resources) with elements in a world that reference resources (instances). This is much better than hacking in a weird format. The other good side is that I can delete/change the instances, I cannot do that with resources.

For quite a few days I have been working on compiling Redintegrate on a different system with a fresh install of Fedora 18 (now 19). My goal was to run it on a second laptop to test more on the multiplayer server parts. Well, OpenGL 3.2 isn't supported on my GPU, so I am now working on cross-compiling to test on Windows. Oh joy.

One good thing came of this: My CMakeLists has a lot of improvements, mainly checking for libraries and headers and failing when any are missing.

Windows build system finally works. I had some issues with 1) SDL2 mouse movement failed in SDL2 on windows, 2) OpenGL 3.2 context loading 3) GLSL shaders having attributes starting a 1 and leaving 0 unbound, and 4) non-standard usage of dirent's to determine entry types.

I have another F19 computer set up dedicated to mingw32 cross-compiling, which so far works well. Getting the server to run didn't need much and works just fine. The client, however, was a PITA. First off, GLEW is broken, cannot build from git/svn. Second, other extension loader libraries, well, don't handle core contexts. So, settling with a built-in GL3.2 loader generated from a python script did the trick.

The client now runs properly which means I can continue development on the linux side (I mean, really, make -j 24 vs. mingw32-make -j 2 on 64 C++ sources) and quickly test on Windows. :3

Oh, since I lack screenies...



What's going on right now:

Instancing system. Old system had 'entity' that just had data for all entity types in it, wasting memory. Instances will have a base class and various child classes set up to handle different data, but with the parent class used to sync up over the network.

The thing still on my mind is interpolation and separation of interpolated data from the server or client (should bullet on the server control this primarily or the client?).

More though put into packaging maps. Right now, maps consist of a folder, a map.map file, and any required files (directory structure not important, all files are processed). I was going to zip them up, but now, I was thinking about simply serializing the resource system and producing a bzip'd binary blob of serialized resources. This would remove unneeded files and data in the formats and only store the raw data needed.

The use of blobbed and non-blobbed maps will be supported as map makers can simply build the map and when done just have the engine convert it to a blob. Only thing to think about is writeback for config files and such. (Ex, if you wanted to make a pinball machine and store high-scores (Yes, you would be able to pull this off in Redintegrate using Lua scripting), then write-back is needed. Look at Trials Evolution and the insane maps).

Working on data serialization that will be used by the instancing system. Lots of operator>> and operator<< in order to make sure that all data structures I use can be synced nicely. I mapped out the classes, model skeleton in place, just needs coding to be done on the serialization and onwards.

I haven't been following this project nearly as closely as I should be, but based on your "progress log" of updates in SAX, it seems like you are working very hard on some rather challenging problems. My offer to help out with Collada in whatever I can do to help make it more understandable remains as valid as ever, given the depth in which I have had to delve into the format for my SparseWorld project. I certainly look forward to playing around with this game engine when it reaches some demo-able state, and special kudos on your efforts to make one cross-platform codebase.

I'm jealous of the amount of free time you have for this. Great work so far

Anyone heard of dynamic_cast failing in C++ that doesn't return null or throws bad_cast? Pointer address is 0x6f7e90 and dynamic_cast's return is 0x50...

Sounds like memory corruption... Someone's been playing in the forbidden area!

Or me getting the data from a function that should return a vector but has no return :/

Prepare for a long rant on the usefulness of destructible terrain and other in-game models affecting the dynamics of gameplay and such:

Yes.

When planning the game, destruction was a top priority. I wouldn't go without it. And seeing some 3D convex decomposition of meshes used to shatter/splinter meshes when used with a physics engine made it a required feature.
...
Well, finding a library that does what I want, fragments a mesh using different plug-n-play algorithms with limited parameters and a seed using a built-in random library, doing UV mapping of fragmented pieces, running stress tests, particle engine integration, rooted fragments... nope.

So, I finally figured out a working algorithm/process to do 3D voronoi fragmentation (as well as the other features, but the fragmenting part was what I hadn't gotten down). A giant chunk of code is building up in a test program that right now is working on building the cell walls of a voronoi tessellation. See, if I have two cells, it is quite easy, just slice a mesh on a plane, done. But this ain't no fruit ninja game, I need a lot of points.

Essentially, a cell wall starts out as a plane and is then sliced by all triangles in the base trimesh and by all other cell wall planes.

Right now, I just got a cell wall to be sliced to the trimesh. I will start to work on having 3 or more cells as I need to factor in the other walls in the slicing code. Then: slice the trimesh, find all walls for each cell and dupe the faces to make separate trimeshes, generate UV coordinates for all new triangles made (base trimesh is easy, internals will be interesting and will be configurable), "smart-shrink" the trimesh and make a bullet collision object for it, glue all pieces and anchor specified trimeshes.

Screenies:


Output of triangulated cell wall for a cube. Selected triangles were generated in-code and exported in .obj format for ease-of-viewing.


Made the plane have odd floating point numbers for the cell origin midpoint and normal, added in fuzzy comparisons.. because floating point numbers. But hey, solid rendering, easier to see!