kiith-sa / dpong Goto Github PK

Pong written in D language.

License: Boost Software License 1.0

Vim Script 0.13% D 97.20% Shell 0.02% JavaScript 2.35% Python 0.30%

dpong's Introduction

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
<title>DPong</title>
<link href="style.css" rel="stylesheet" type="text/css" charset="utf-8" >
</head>
<body>
<div id="header">
    <div id="headercontent">
    <h1>DPong</h1>
    </div>
</div>
<div id="content" >

<img src="dpong_logo64.png" alt="DPong logo" width="64" height="64"/>



<h1>DPong version 0.6.0</h1>

<h2>Introduction</h2>

<p>DPong is a fast-paced Pong remake with nice, vector style graphics
written in the D programming language.</p>

<p>At the moment, DPong is unfinished and is still missing sounds and multiplayer.
These should be added in the coming releases.</p>

<h2>Gameplay</h2>

<p>The goal of the game is to use your paddle to throw the ball behind the other 
player's paddle. You control your paddle with directional arrows.
You can take screenshots using the Scroll Lock button. Screenshots
can be found in <code>.dpong/main/screenshots</code> in your home directory.</p>

<h2>New in this release</h2>

<p>DPong has been rewritten in D2.
Much of the code has been simplified thanks to improvements in D2 and its standard 
library.</p>

<p>CDC build script and memory debugging code have been completely rewritten.</p>

<h2>Compiling/Installing</h2>

<h3>Directory structure</h3>

<ul>
<li><p><code>./</code> <br />
This README file, utility scripts, DPong sources outside of any packages.</p></li>
<li><p><code>./data</code> <br />
Main game data directory, contains game data that is never modified.</p></li>
<li><p><code>./user_data</code> <br />
User game data directory, contains modifyable user data such as screenshots, etc.</p></li>
<li><p><code>./dependencies</code> <br />
Source code of libraries DPong depends on (only derelict at the moment)</p></li>
<li><p><code>./doc</code> <br />
Documentation.</p></li>
<li><p><code>./xxx</code> <br />
Other directories: DPong source files.</p></li>
</ul>

<h3>Requirements</h3>

<p>DPong is written in D2, so it requires a working D2 compiler such as dmd or gdc.
DPong also depends on SDL 1.2, FreeType, OpenGL, and Derelict, 
source of which is included for convenience,</p>

<h3>Compiling/Installing on Linux</h3>

<p>First, ensure you have all dependencies, as specified above, installed.</p>

<p>DPong uses a D script, <code>cdc.d</code> for compilation. In order to compile, you first have
to compile <code>cdc.d</code> by typing following commands, for dmd an gdc respectively:</p>

<pre><code>dmd cdc.d #dmd

gdc cdc.d -o cdc #gdc
</code></pre>

<p>To compile dpong, use the following command, which will build the release build target.
This should take about a minute with dmd, or a few minutes with gdc.
Alternatively, you can consult <code>cdc --help</code> for specific build targets - 
you need the release target if you want to install using the install.sh script.</p>

<pre><code>./cdc release
</code></pre>

<p>If you don't want to install, you can run DPong from the package's top
level directory by launching <code>./pong-release</code> binary or binary of any
other build target.</p>

<p>To install, run following command as root (e.g. by using <code>sudo</code>):</p>

<pre><code>./install.sh
</code></pre>

<p>This will copy the release binary to <code>/usr/bin/dpong.bin</code> , and a simple
launcher script to <code>/usr/bin/dpong</code>. Main game data will be copied
to <code>/usr/local/share/dpong</code> and DPong will create a <code>.dpong/</code> subdirectory in
your home directory.</p>

<h2>License</h2>

<p>DPong is released under the terms of the 
<a href="http://en.wikipedia.org/wiki/Boost_Software_License">Boost Software License</a>.
This license allows you to use the source code in your own
projects, open source or proprietary, and to modify it to suit your needs. 
However, you have to preserve the license headers in the source code and the 
accompanying license file. This doesn't apply to binary distributions, 
but it wouldn't hurt you to at least mention what you're using.</p>

<p>Please note that these games are based in part on the work of the lodepng library.
Any derived works, source code or binary, must preserve lodepng copyright notices,
which can be found in lodepng bases files (e.g. <code>./png/pngdecoder.d</code>).</p>

<p>Source distributions and repositiories of DGames also include source code
of the Derelict multimedia D bindings for convenience.
Derelict is also released under the Boost Software License.
Source distributions of any derived works must preserve derelict copyright notices,
which can be found in the <code>./dependencies/</code> directory.</p>

<p>Full text of the license can be found in file <code>LICENSE_1_0.txt</code> and is also
displayed here:</p>

<pre><code>Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:

The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
</code></pre>

<h2>Contact/Credits</h2>

<p>DPong was created by Ferdinand Majerech aka Kiith-Sa kiithsacmp[AT]gmail.com</p>

<p>Parts of code based on the D port of the LodePNG library.</p>

<p>DPong was created using Vim and DMD on Debian Linux, and uses the 
Derelict multimedia D bindings.</p>



</div>
<div id="footer">
Copyright © Ferdinand Majerech 2011 <b>kiithsacmp[at]gmail.com</b>
</div>
</body>
</html>

dpong's People

Contributors

Stargazers

Watchers

dpong's Issues

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.

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

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

YAML parser

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

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)

Documenation headers

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

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.

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.

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

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.

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.

Multiplayer over a network

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

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)

GUI background colors

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

Adjust GUI for multiple resolutions

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

Dependencies: #12

Decrease GraphData memory usage

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

Ideas:

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

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

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.

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.

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)

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 .

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.

Use Derelict2 selective symbol loading

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