kiith-sa / dpong Goto Github PK
View Code? Open in Web Editor NEWPong written in D language.
License: Boost Software License 1.0
Pong written in D language.
License: Boost Software License 1.0
<!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>
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 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
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
Write a minimalist YAML parser, both to read and write YAML.
Concentrate on simplicity over speed.
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)
Each source file, not just class, should have a documentation header.
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.
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 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
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.
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.
Will require a networking subsystem, and probably significant changes in the engine.
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)
Implement background colors for GUI elements (nothing more for now, just colored rects).
Adjust the GUI, and maybe in-game graphics (instead of zooming) to many screen resolutions.
From 640_480 to 1920_1080.
Dependencies: #12
GraphData can consume quite a lot of memory over time, especially with multiple monitors running at the same time.
Ideas:
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 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.
Replace usage of GL_EXT_framebuffer_object (taking screenshots) with GL_ARB_framebuffer_object - it is more futureproof and provides more guarantees. Requires Derelict2.
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)
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 .
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.
Derelict2 selective loading is not documented yet, once it is, we should use it.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.