quyse / inanity Goto Github PK

Graphics system should be able to say what capabilities is supported. Graphics system have to initialize the best supported version of graphics device, and fallback gracefully.
As concrete example, GL subsystem should not require OpenGL 4. It should work even on Open GL ES 2.0.

Make graphics system more general by removing manually assigned semantics. This would give more freedom to graphics implementation with how to implement uniform buffers, shader linking and so on. Make shaders subsystem mandatory if needed, possibly move it into main graphics subsystem.

Should be crossplatform.

Windows should support two modes: mouse capture mode and free mouse mode. Mouse capture mode could be used while main gameplay is in progress. Free mouse mode could be used in pause menu, to allow moving mouse out of the window (both in fullscreen and windowed modes). Modes should be switched programmatically by game logic.

As a linked issue, windows should allow to use native mouse pointers (instead of graphics-rendered ones). Native mouse pointers are always more responsible to user input, uses the same mouse ballistics as the main system, and, despite of limitations of native windowing systems, leads to more seamless integration with operating system.

Introduce graphics programs which would incapsulate OpenGL shader programs. Remove cache of OpenGL programs indexed by pairs of vertex and pixel shaders. DirectX would emulate shader-link behavior at no cost.

FolderFileSystem and accompaniyng classes should be moved into Inanity::Platform namespace (and possibly renamed). inanity-base library should be more cross-platform.
Also it's good to split FolderFileSystem into two classes - Win32FileSystem and PosixFileSystem.

For now objects are exposed to script with their declared "return type", and corresponding script object is cached while script is holding a reference to it. But if an object would exposed to script second time with another return type (subtype or supertype), it gonna be exposed as old cached script object with wrong method table and stuff.

To fix that we have to cache script objects taking into account the exposed type, and make several script objects - one for each exposed type of object. Note that reclaiming object should clear all types of object at once.

For now, when ComPointer created from raw pointer, it thinks that it owns that pointer, and one reference already here, so it doesn't add reference.
Proposed to change this in favor of ptr's way, and refactor all places where such assignment is done. It allows to freely exchange ComPointers and raw pointers without errors, just like ptrs.
Also, it would be cool to overload address-of operator of ComPointer, to enable easy receiving objects via pointer-to-pointers, like they are usually received. The same is done in Microsoft's CComPtr.

Using GLEW has several disadvantages, such as hackish OpenGL initialization and a use of global variables. The engine uses not so many OpenGL functions, so importing OpenGL functions manually isn't hard, and, after all, it tends to better understanding.

UniformGroup should not have a buffer's data. Proposed to make a separate UniformData class which would store data, and be sent to Context. It will make easier of tracking dirty state of uniform buffer data in contexts.

I would like to point out that an identifier like “___INANITY_STORAGE_HPP___” does not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

Add possibility of setting default sampler state to texture. This feature could be easy emulated on DX11, and is natively supported on OpenGL. Moreover, this allows to set correct sampling for textures even when OpenGL doesn't have ARB_sampler_objects extension (< 3.3), for example, in WebGL.

Replace current check-them-all GraphicsState with more optimal stack-based state setters.

Proposed to make reference graphics system, software rasterization and LLVM-based shaders. Such system would allow for easier debugging and headless rendering on servers plus maybe tests functionality. Of course, it should be fully abstracted like another backends.

XCloseDisplay crashes test program with no useful stack. Debugging shows that ATI fglx driver sets a callback for closing display event, but when display is closing that callback points to a wrong memory.

For now, compile-time metainformation extensions for script languages are included in source if the ___INANITY_META_<script>___ macros are defined (for now it is only ___INANITY_META_LUA___). ___INANITY_META_* macros have to be defined globally for Inanity libraries and a project which uses Inanity. In fact, the Lua support is hard-to-disable: commenting out ___INANITY_META_LUA___ from meta/Extension.hpp is not a good way to remove dependency.

Proposed enhancement is to separate defining of metainformation classes from the main source. Compile-time extensions are actually needed only in a code which work with scripts. So, I need to extract all META_CLASS/META_METHOD/... macros out of main source files, and move them to special include files, which are intended to be included in only source file in the executable. ___INANITY_META_* macros will all needed for this only source file, but not for the whole project.

EnumDisplaySettingsEx WinAPI function always returns 0 for some reason. Temporary "fix" has been made, but it needs full solution.

V8 javascript machine should be supported as scripting language, along with Lua.

Make a filtering file system which individually compresses files before giving data to underlying file system.

See F.A.R.S.H. demo on Windows, or banshee on Windows/Linux. One or more textures don't load (or load incorrectly) and appear as black.

Because of DirectX11's crazy linkage system we need to list all vertex shader's interpolates in pixel shader. Otherwise we will get Direct3D error about invalid linkage because output variables from vertex shader and input variables from pixel shader are set to different "hardware" registers. Maybe it is possible to workaround this automatically rather than manually, or invent some new abstraction like shader-stage interface.

Gambit looks like very good candidate for binding to. It provides interpreter as well as Scheme-to-C compiler. We could use interpreter for fast write-and-run cycles and compiler for release performance.

StreamWriter::WriteShortly and StreamReader::ReadShortly uses endian-dependent algorithm. This is wrong.

At first glance it is harder than V8/Lua because Mono needs precompiled assemblies to expose C++ things for C#, so it may need a special compilation process.

Add support for building for browsers with emscripten.
Requirements:

• general - should compile under clang
• graphics - should use WebGL-subset of OpenGL (related task is #8) plus fullscreen API
• input - should be done with javascript library (for mouse could use pointer-lock API)
• Platform::FileSystem - should use C++ standard library functions
• Javascript bindings - may be simplified for emscripten, at least whole V8 machine isn't needed :) But we can use the same scripting abstraction as for Lua and V8, to inter-operate with "native" javascript
• audio - use Web Audio API