team-doominati / doominati Goto Github PK

Will need to be done after PNG support, since that includes implementing DEFLATE and the zlib format.

already have a working commit stashed away for this

WHY NOT?

We need a blockmap before we can do physics. (Technically untrue, but adding a blockmap after the fact would invite unnecessary issues.) If I end up writing it, it will be a plain fixed-size grid (as in Doom). This leaves the question of how to determine its size. Both the overall size and the cell size. The former would ideally be determined per-map, while the latter would be more efficient if made a compile-time constant.

Alternatively, we could do a dynamic block subdivision and thus be able to start off with the entire map limits (as determined by the coordinate format) as a single node that is divided as-needed.

Needing to use NativeLoader stub functions to get natives to actually get added defeats the entire purpose of distributed definitions. It is less of a concern in Code itself, which can reasonably deal with its own quirks, but it is unacceptable to need this in other modules.

Unfortunately, just making the NativeAdder objects not static is not enough, so some other solution needs to be found.

need to try and optimize via SSE as per #8 and test with practical effects

DGE_Point2I DGE_Font_GetTextSize(unsigned font, char const *text);
DGE_Point2I DGE_Texture_GetSize(unsigned texture);

for fonts just return the width of the biggest line and height * lines
for textures I need to add the width/height of textures to TextureData, at that point I can also make RenderThinkers default to rendering at that size (instead of 0x0 pixels)

This may not be implementable on most of the drawing functions, but should be implemented with alternative functions at some point.
For circles, it may be possible to do this with a shader, very carefully. Any immediate mode functions will Just Work.

[5:06 PM] Kyle873: think about something like SOTN
[5:06 PM] Kyle873: and how it merged 2D and 3D usage so. fucking. well.
[5:07 PM] Marrub: I want 3d support for that and because I think it would be nice for a FPS as well
[5:08 PM] Marrub: with the way I use VBOs it won't be hard, just need to expose matrices to the script engine
[5:08 PM] Marrub: and add convex hull collisions etc

This depends mainly on what spatial information the engine has (as opposed to what scripts have) -- whichever one has more info should be doing this.

needs regular inputs, probably buffered, IME support (should display ingame and not on system), and some way to network sync via magic

Having everything be in one file is ugly as fuck.

The mouse position should be normalized, but not relative, like it is right now.

AAAAAAAAAAAAAAAAAAAAAAAAA

is ugle

These will likely be some kind of Thinker that's tracked through some global state.

Music needs to be streamed and so it needs its own module which depends on AL.

Unfortunately this also means we need to write more loaders, but whatever.

Formats to be supported (suggestions welcome):

• Opus
• Ogg
• FLAC, maybe? Not very good for streaming.
• MOD/IT/XM/S3M/&c. Module formats.

Also, because we'll have a whole module for music, it would be cool if we had an omega sequencer like Sympathy in-engine.

This would be nigh fucking impossible in scripts just because of how complex it is and could be a selling point :P

JPEG support would be great for large images and photos (very big file size reduction)

WebP would be nice as long as the format isn't too hard to use or has a good library

can just use a std::vector inside Renderer::PrivData here, function needs parameter bounds
calling this every frame causes huge slowdowns so the function isn't even worth using

Use system APIs with conditionally-compiled code to handle exceptions, so Windows users won't be confused when the game crashes.

and also so we can have it play a clip of DID THEY EVEN TEST THIS GAME BEFORE THEY RELEASED IT

Currently fonts will only render one font face, ie. bold, italics, emoji, other languages, &c. will only render if the entire font face has it. This is a problem when you have a lot of characters you need or want better bold/italics rendering.

Fixing this issue should be fairly easy, all that really needs to be done is layer FontFaces onto eachother, which will require me to make the FontFace API virtual (as is also required by #20).

There needs to be a way to access Thinker members from scripts by ThinkerID, obviously. But it needs to be fast and (reasonably) robust. Doing a name-based lookup at runtime is right out. Most likely there will be a loader lookup that translates to an index. This index can either be an enumeration (safer) or an object offset (faster). That does leave the question of whether or not to split the API by type. For natives, the obvious answer is yes, as otherwise it would require very strange hacks to access non-integer members. Internally, it's hard to say. If the API is not split, then the Thinker member functions presumably just convert to Code::Word. Accessing a member by the wrong type will give a malformed result. If the API is split, then there is an actual question about how to handle type mismatch. Either it fails to find the member (and thus returns whatever that value is (probably 0)) or it converts to the desired type. I am most inclined to have a non-split internal API.

There is also the question of storing extension members. I am currently leaning towards allocating them along with the owning object and accessing them by ThinkerID and index. This does require the number of extension members to be committed to at object creation, but I think that is reasonable. There will likely be two kinds of extension members. Global ones, which are registered during engine loading (either in codedefs or gamedefs) and are always added to any allocation of the relevant Thinker type. (And are also referenced by name during loading.) And instance ones, which would be specified as a count passed to the creation native. Instance members would be allocated after global members, and so would be indexed as an offset of the combined size of global members, also available as a loader symbol.

Putting this up, because some of these affect how the base Thinker class gets designed, and in case anyone has other ideas on the subject.

Currently the code just checks the GNUC macro, which ignores the possibility of platforms for which dynamic goto is not implemented, as well as MSVC's dynamic goto support. CMake can be used to solve this.

TTF/OTF support needs to be in, maybe using freetype

We have manual threading, C++11 threading, and script threading.

I'm thinking, though, that OpenMP may be useful as well for
certain big operations which have no mutual exclusion needs.

OpenMP is fairly unintrusive, providing compiler pragmas when supported.

For example:

// openmptest.cpp

#include <cmath>
#include <chrono>
#include <iostream>

int main()
{
   constexpr double tau = 3.14159265359 * 2.0;
   constexpr std::size_t tableLen = 900'000;

   static double sineTable[tableLen], cosineTable[tableLen];

   auto begin = std::chrono::high_resolution_clock::now();

#ifdef USEOPENMP
   #pragma omp parallel for
#endif
   for(std::size_t i = 0; i < tableLen; i++)
   {
      sineTable[i]   = std::sin(tau * (i / double(tableLen)));
      cosineTable[i] = std::cos(tau * (i / double(tableLen)));
   }

   auto end = std::chrono::high_resolution_clock::now();

   for(std::size_t i = 0; i < tableLen; i++)
      if((i % 10000) == 9999)
         std::cout << sineTable[i] << '\t' << cosineTable[i] << '\n';

   auto durationNS =
      std::chrono::duration_cast<std::chrono::nanoseconds> (end - begin);
   auto durationMS =
      std::chrono::duration_cast<std::chrono::microseconds>(end - begin);

   std::cout << "done in " << durationNS.count() <<   "ns ("
                           << durationMS.count() << u8"µs)\n";
}

// EOF

Compile with clang++ openmptest.cpp -std=c++1z -o b.out and you get:

...
-0.275644       0.96126
-0.207919       0.978146
-0.13918        0.990267
-0.0697634      0.997564
-6.98132e-06    1
done in 151062290ns (151062µs)

But, compile with clang++ openmptest.cpp -std=c++1z -DUSEOPENMP -fopenmp -o a.out and,

...
-0.275644       0.96126
-0.207919       0.978146
-0.13918        0.990267
-0.0697634      0.997564
-6.98132e-06    1
done in 50347741ns (50347µs)

A very noticable increase in speed, essentially for free, just by adding a compiler pragma.

Thoughts?

This can probably be done with a string table like LANGUAGE or something.
It should be outside scripts and easily editable to work with any language to ease making translations of existing games.

Need a way to iterate over FS::Dir objects directly, rather than using forFile.

Doppler and pitch are already implemented, but two others I could see having lots of practical use would be low-pass and high-pass filters. Low-pass for effects such as open menus which pause gameplay and high-pass for things such as accompanying disorientation/confusion/flashbang/underwater/etc effects.

iuno how to thing

There's something that is a very big issue in ZDoom: There is no real way to debug scripts.
I think the reason this is an issue is obvious, so my question is, how should we handle this in DGE?

We should only really support:

• WAVE (done)
• Opus
• Ogg
• FLAC

Anything else would be extraneous or subject to patent issues.

Need to consider sound engines to use, or we could roll our own (and possibly go insane doing so).
libvorbisfile/libvorbis/libogg seem to be pretty good, so those will probably be candidates for file decoders.

Currently text rendering is limited only by the fact that you can't do things with individual glyphs, only strings of characters. The current API is completely fine, for 90% of cases it's all you need and works great. The issue comes along when you need to do more complex text effects like having each character fade in individually, which without killing performance is currently impossible. The plan then is to add functions for getting information on and drawing particular glyphs in a font.

aaaaaaaaaaa

This depends on geometry and spatial information much like AI, and will be hard to work out until later stages.

We need a lot of thought for how the whole of logic should work.
This is more of an open question that should lead both to discussion here and via new issues.

Here's some main components of game logic, from lowest to highest level:

• Framerate (game snapshot rate)
• Positioning systems (how big is x/y/z? how do we know? can we change it? how does this change rendering?)
• Thinkers (objects which call functions during game snapshot and store data)
• Large, sectioned collision data and graphics (maps)
• User input
• Rendering occlusion

And some parts of thinkers we need to address (also in order of lowest to highest level):

• Data mapping and storage
• Callbacks (what functions do we call and when?)
• Events (how do we trigger what, when and where and why?)
• Ray intersections (hitscans)
• Collision response
• Physics
• Animation (discussed elsewhere, but recap and ideas would be good)
• AI

Also important, I feel, is how we name things.
When we add something, we're going to be typing it and reading it a lot, so let's make sure we're happy with how we name it.

Thinker is a game object that changes over time. Entity is a Thinker that reacts to external stimuli at a higher level than basic physics. Given the latter's obvious core usefulness to gameplay, it needs to come into existence. As discussed elsewhere, the class hierarchy will be Thinker -> PointThinker -> RenderThinker -> PhysicsThinker -> Entity. While the most basic parts of defining these classes should be simple, now is probably the time to start thinking about how Entity is going to interact with the environment (including over time).

Considering adding LZMA and bzip2 compression streams, as well as .7z, .xz, and .bz2 format support.

OpenGL has line antialiasing and functions for setting the line width and stippling, these should be available as functions in Window

As discussed elsewhere, considering adding a new DGE_NTS format for defining engine defaults.
Here are the things I propose be added:

• Default (physical) window size
• Entry points to run on scripting init (maybe put this in CODEDEFS instead)
• Default engine tickrate
• Command-line options to add
• Texture/shader/font aliases to load

Could also maybe add arbitrary CODEDEFS/GAMEDEFS files from here, not sure on that.