kiith-sa / dpong Goto Github PK

Replace Vector by a copy of D2 std.container.array built on top of memory.memory functions
so we can still keep track of allocations.

Possibly also copy RBTree from std.container.

A map/hashmap/associative array with manual memory management might also be useful.

Update:
Phobos containers will get custom allocators in the future - wait for that.

Pong, game, as well as objects' properties.
Video settings, ball (and dummy ball) parameters, maybe even particle systems attached to (any) actors - would require some work, AI settings, game speed, object speeds, SceneManager update time, etc.
Each subsystem should handle its own settings.
With e.g. VideoDriver, some settings should be in VideoDriver, some in GLVideoDriver.
Also keyboard settings for everything.
Font Manager settings like number of fast glyphs and default font.

Basically, everything we can, not only the stuff that will be in options GUI.

Dependencies: #9

In-game options dialogs allowing to set some yaml parameters.

E.g. video mode, draw mode, line antialiasing, AI difficulty, keyboard settings, particle system settings even.

Also setting players (names, and whether or not they're players or AIs) at the beginning of the game - this should
be where player-specific keyboard settings would be set.

Dependencies: #10

Implement an audio subsystem and some basic in-game sounds.
Maybe even GUI sounds, but must not be invasive.
Also, background music (even if there is no background music - just support it)
We can implement a simple, RA2 style in-game music player that
allows the player to browse and play music in some directory.
(Ogg only, maybe FLAC in future)

Move drawing to a separate thread traversing both GUIand SceneManager through const methods, i.e. without ability to write to the objects (to prevent threading bugs).

It should not be a problem if we draw half of the actors in update #155488 and half in update #155488. In the physics/game thread, we still need to keep fixed update rate, we can spend the rest of the time first in placeholder infinite loop, then, when the things work, try sleeping (don't sleep if it leads to lag or temporal aliasing, though).

The only significant problem: The drawing thread must never read data that is invalid at the moment, e.g. during an update. We can use per-object locks for that (only acquired by non-const methods, though - or maybe D2 has something more elegant, like synchronized)

Write a minimalist YAML parser, both to read and write YAML.
Concentrate on simplicity over speed.

D1 is dead.

First, rewrite CDC in D 2 or Python 3.

Then, start moving to D 2, first CLI parser, then platform/video/gui to get to main screen, then game stuff, etc.

We also have to move to Derelict 2, SDL 1.3 .

Each source file, not just class, should have a documentation header.

Derelict2 selective loading is not documented yet, once it is, we should use it.

Module file.file is currently written using C file I/O functions which are ugly and bug-prone.
D2 Phobos has more D-like functions in std.file and std.stdio .
Rewriting file.file using those might simplify code somewhat.

Time weak singleton class.

Should be passed when updating actors, instead of time_step, game_time.

Should also make timed delegates/actions possible, delayed both in real time and game time,
replacing clunky logic in BallSpawner, ScoreScreen.

Might make signals with delays, or ones that are fired at the beginning of the next frame, possible.

Only implement as much functionality as we can without using a full blown singleton, we don't want that.

Adjust the GUI, and maybe in-game graphics (instead of zooming) to many screen resolutions.
From 640_480 to 1920_1080.

Dependencies: #12

Ensure that the code compiles on Windows, create a packaging script (maybe just modify linux packaging script).
Windows binary package needs to include SDL, FreeType DLLs, maybe more if needed.
It only needs to be 32bit, no need for a separate 64bit package.

Also write tutorials on installation from source and setting up a davelopment environment.

Implement background colors for GUI elements (nothing more for now, just colored rects).

GraphData can consume quite a lot of memory over time, especially with multiple monitors running at the same time.

Ideas:

1. Lower-precision floats, or even fixed point with shorts - we could use a template for multiple options.
2. Gradual data loss (i.e. data points measured longer time ago would be more sparse)
3. Compression of older data with zlib in memory
4. Automatic and/or manual dumping to files
5. Fixed time to retain measurements
6. Manually specified time resolution (data point density) - some monitors don't need that much

Needs new DMD version or usable D2 GDC support,
as floating point asm generated by DMD is
horrible at the moment and overshadows everything else.

Profile, find performace issues and optimize.
Use OProfile (CodeAnalyst?), ApiTrace, Linux perf tool, Valgrind, Massif, etc.

In particular, profile the main menu performance, i.e. not in-game.
The FPS in main menu seems to be way too low. (Try fullscreen as well - maybe it'll provide more accurate results)

Next DMD release should fix the bug with clear() on classes calling default constructor.
Once it is released, replace die() with destructor where possible.

Will require a networking subsystem, and probably significant changes in the engine.

More advanced AI that takes note of ray hints from BallSpawner and tries to predict where the ball will move. Not perfect, though, that would kill the gameplay.

The CLI parser has sour some major design failures. We need to get our value out of the parser manually
after the parsing to enable better error handling. opDispatch can help there. Also, we should replace the builder pattern style for CLIOption with a with(new CLIOption("name")){do stuff; add_to(parser);} style.

Since the CLI parser is not a crucial component, this is low-priority. It could become more important if we use the CLI parser more.

Replace usage of GL_EXT_framebuffer_object (taking screenshots) with GL_ARB_framebuffer_object - it is more futureproof and provides more guarantees. Requires Derelict2.

GUI should be serializable to/from yaml.

There should be a default set of values in a mod directory for e.g. GUIButton, and widget-specific settings can override that.

Of course, serialization can't be without limits, e.g. signals still need to connect, but we should at least be able to
e.g. choose implementation of a menu. Still, consider even full serialization with signals specified in yaml.
That might work if we have some sort of dynamic signal object, any number of which could be added to a GUI element.
Might be possible to do that elegantly in D2.

Separate from GUI layout, there should be skins/themes. One skin per entire GUI. The skin could specify:
border, background colors, font size, possibly Z index like HTML/CSS, maybe also element dimensions, not sure about that as it might end up with one skin declaration per element.

The skin would be in CSS-like format, using #id' s and .class'es to identify elements.

There should be a GUIStyle class separate from GUIElement, dedicated to this. Each GUI element would have a link
to its style and use that for drawing/updating/whatever.

Also, we need an option to reset and reload entire GUI subsystem at runtime (at least in the main menu) - this would
be immensely helpful for fast modding/testing.

Dependencies: #9

Write developer tutorials with stuff like how to get started hacking the code, see
such documentation in Wesnoth, OGRE, other projects for ideas.

Most important:
How to set up an environment to start hacking
(i.e. getting dmd, SDL, FreeType, etc.)

Some ideas:
How to read a file
How to create a widget doing X
How to create a monitorable and a monitor