draconicent / kge Goto Github PK

Currently, CBitStream instances are created and destructed a lot within the scope of the netcode. In the scope of unpacking incoming messages, a single CBitStream object should be kept around and merely reset for each packet to unpack while also being instructed as to where its next unpacking target resides.

Further, when messages are sent at any time, a new CBitStream is constructed which entails not only memory allocation for the CBitStream itself but also the heap entry for its working data. These especially should be reused in the same way as they would be for incoming messages.

This is probably because I'm not forcing --std=c++11

It's probably worthwhile to allow for a Dedicated-only build that'll help facilitate server-only distributions of games. This is mostly intended to help cut down on download sizes for those who don't intend to run a client.

This entails the following:

• No sound libs are linked or invoked at any point.
• No UI files are to be loaded at any point.
• No textures are to be loaded any point.
• It shouldn't require any client scripts to be present.

Keeping the renderer in its own thread independent from the main game thread would help improvements all around especially considering the potential for "queuing" renderer commands from the main thread using EasyDelegate's deferred callers.

Obviously the engine should be capable of detecting if one of the asynchronous threads has crashed or is otherwise non-functioning (an infinite loop?)

Running more than one instance of the same game on the same system will result in a race condition as they will all attempt to use the same logfile. This is caused by the fact that all instances of the same game will attempt to write to ~/.Draconic Entertainment/gamename/LOG.txt

At least it does on my main PC. For some reason the included FindAllegro.cmake file fails on my main PC running Gentoo but works correctly underneath of Gentoo on my Thinkpad. It's likely just a PC specific issue, but it should be looked into anyway.

The error occurs in FindAllegro.cmake:
https://github.com/DraconicEnt/KGE/blob/develop/cmake/FindAllegro.cmake#L119

Something to do with the Allegro version, apparently:
[Wednesday 8:18:39 pm] Bahke "VERSION_GREATER" "5"
[Wednesday 8:18:47 pm] Bahke Unknown arguments specified

The projects CMake generates will run with the execution directory being at apps/engine instead of bin/ when ran from inside of the IDE. This makes debugging impossible (at least within Code::Blocks) unless the generated project is modified afterwards to have the proper execution working directory.

Right now, the CBitStream unconditionally allocates memory on the heap for use in packing incoming data to. Pretty much all usage situations say it should be part of the CBitStream itself: The actual length of said storage would then be governed by a template parameter which would also slightly increase efficiency with storage size checks against statically known values.

If the stream happens to run out of buffer space during a write, it should throw an overflow exception as it already is and let the calling code deal with it: It can be split into multiple packets then.

Implement the Lua sound module.

It should include the following global methods:

• soundHandle = sound.getSoundHandle("soundFile")

The following methods should be available on sound handles (it works for music as well):

• soundHandle.stop() -- Destroys the handle
• soundHandle.setLooping(true/false) -- This should dealloc the handle when it's done if false (by default they shouldn't loop)
• soundHandle.setVolume(0.0 - 1.0) -- Used if the sound is two dimensional
• soundHandle.setMinimumDistance(distance) -- Minimum distance represents the distance at which the sound will play at maximal volume
• soundHandle.setMaximumDistance(distance) -- Maximum distance represents the sound falloff
• soundHandle.play3D()
• soundHandle.play2D() -- Is what triggers the sound to actually play in two dimensions
• soundHandle.setPosition(x, y, z) -- Sets the position of the sound. Only used if it's a 3D sound.
• soundHandle.addCallback("callbackName", luaMethod) -- Bind a Lua method to a callback of this handle
• soundHandle.setPlayTime(timeValueMS) -- Tracking implementation
• soundHandle.setPaused(true/false)

There is a more detailed explanation of these methods at he following link: http://dx.no-ip.org/doku.php?id=projects:kiaro:modules:sound

A launcher for the engine will be necessary for proper logging & crash detection. As it stands, the launcher only needs to do the following:

• Spawn the actual engine process and hook into its cout and cerr.
• Anything printed to cout and cerr should be parsed and written to a file to provide asynchronous logging support. The launcher may preferably have support for logging systems such as syslog-ng versus handling the logging itself.
• If the engine exits with a non-zero exit status, there will have been special cerr output to parse before it exits. If it were a hard crash on *nix systems, this should still output some usable data.

All output to cerr and cout will be formatted as such:
(Type): Message

This makes it easy to read in regular terminal output but also is easily parsed in the launcher application.

The CBitStream (or a type deriving from it) should support filesystem targets. Reads may occur in blocks (whose size is probably specified via a template) where it unpacks from memory until a new block is to be read from disk. Writing is effectively the same way, which means that it should also flush any unwritten buffer data to disk when destructed before closing the file.

Replace all file I/O operations in Lua with native PhysFS calls so that the engine doesn't have to build the paths itself and to prevent the IO lib in Lua from getting into places it shouldn't be.

It may be beneficial to have an asynchronous net library. It would alleviate the main thread from having to run the regular net logic such as checking packets, assembling packets from segments, interpreting messages and so on.

When the main() method is invoked, it may be beneficial to send program parameters passed on the command line into it as well.

Demo recording should be possible via a toggle that causes libNet to write read messages from the remote server to a local file during the message read stage. IServer would then have implementations to launch as a listen server using a demo recording file to simulate net traffic versus actually initializing and using the network backend.

Currently, all messages are dispatched in individual packets. This is clearly not desirable in all scenarios so it should be possible to queue up messages to be dispatched in a single packet. Further, all reliable and unreliable messages should be queued separately for dispatch across the appropriate lines.

It may be possible to "queue" by writing to a CBitStream but not immediately dispatching the packet until the net update iteration is done in certain circumstances.