Giter Club home page Giter Club logo

dpong's People

Contributors

kiith-sa avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

dpong's Issues

D2 containers

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.

Load/save settings from/to YAML files

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

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

Sounds

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)

Drawing in separate thread

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)

YAML parser

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

Move to D2

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 .

Rewrite file.file using D2 file functions

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 subsystem

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.

Windows package

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.

GUI background colors

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

Decrease GraphData memory usage

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

General profiling and optimizing run

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)

Replace die() with dtors

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

Smarter AI

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.

Rewrite the CLI parser

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.

Move to GL_ARB_framebuffer_object

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 serialization

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

Developer tutorials

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.