Dreadmoon Linux Andromeda Release

http://dreadmoon.com/index.php?option=com_content&view=category&layout=blog&id=3&Itemid=14

http://dreadmoon.com/

"This release is primarily intended to eliminate a major roadblock to the development of games and multimedia applications under Linux that is a consequence of the fact that many of the related software libraries are not available as installable packages."

These many libraries are the D libraries and programs required to have a build system on Linux. Tools are in developmental phase.

All ideas are welcome. Email clay dot smith dot r at gmail dot com.

Source Code Repository Moving to Github

Dsource.org/projects/arclib will be ArcLib's official "Web Page."
GitHub will be the official source repository.

This move is being done to provide more exposure to ArcLib and make it easier for contributors to contribute (after the git learning curve).

Post Re-Post on the Blog

Post-Disclaimer Disclaimer: Originally written for the D NG to focus on 2 questions.
1. Does D really want to be popular? Be the "cool" kid?, and
2. What would it take to achieve popularity (The geek view would be the most technically superior language will win, but this is like saying the smartest man has the best chance of becoming president, we see how that works out in the real world ;) )

Disclaimer: Within a finite amount of time, I wrote this quickly, fully explaining the finer details would take a lonnng time ;)

Concise Summary:
D language popularity can increase dramatically if:
* C++ support is improved
* D is ported to .Net
* D is ported to JVM
* Driver-run grassroots marketing campaign (kind of like intelligent spam or context-sensative ads, where the driver is the central machine that tells where to advertise and when and how, etc, and people would post on different sites. The driver machine could be a community member who organizes this campaign on a wiki, and D citizens could carry out the deed.)

Long post:

Maybe this is just stating the obvious, but if popularity is really what D wants then features are not the choke point or problem with D adoption, I see the choke points as

* How well does this language interact with others?
* How stable is this language ?

I think the D language can make great strides by riding piggy back on

* .NET MSIL (Doesn't exist?)
* JVM (Doesn't exist?)
* C++ (D 2.0 implementing this somewhat)
* C (already done)

The fact is that no one wants to re-invent the wheel, I would never have used D if not for the fact that it can ride on C's progress. Similarly, it is very feasible to have D run on top of C++, MSIL, and JVM.

Great progress have been made in both the .NET and Java libraries, and I suspect D or a similar language would do well there.

D wouldn't do as well on .NET as Java perhaps because C# is already halfway decent, but it would increase D adoption anyways.

D on JVM on the other hand, if it's possible then I think it can be a big hit. You can say there are fundamental philosophical differences between JVM and D, but I see it as a way to increase D adoption. Then suggest move to mainline D when speed is a greater concern.

Now, I'm not the one to do this work anytime soon, but perhaps it is a good idea to remind others. I think language adoption comes from

1. How well the language interacts with existing technologies (Only can interact with C and C++ with a lot of effort, no MSIL or Java interaction)
2. How useful the language itself it (D is already incredibly useful)
3. Language stability (Rapid growth is a good start, however without stability its like trying to build a building on a fault-line )
4. Massive marketing machine (D's actually doing decent in this)

Looking at these points it becomes obvious why languages are successful. Interpreted languages have gotten away with not requiring too much compatibility because of their nature, and C# and Java are decent products with a good amount of hype behind them. C had AT&T and was actually useful, and C++ became popular on the sole fact that it extended C.

Now we have D, which talks to C and therefore the next "C".
D can also be the next "C++", "Java", and "C#" if D can have direct access to these languages libraries.

- Clay

SVG, Scenegraph, and Arctographer

I'm working on implementing an SVG loader / renderer using ChristianK's resurrected scenegraph extension for rendering. Also, SirAlaran is working on a arc.x.level extension and tilemap editor, take a look here:

http://www.dsource.org/forums/viewtopic.php?t=4775&sid=7d989c8c6604ff0adcff4dbcb602d3f9

and 

http://www.hackerpilot.org/images/game_project/map_editor/screenshot-2009-11-15.jpeg

All in all, things are looking up. 

 

ArcLib v.03 GUI-Physics-Refactor release

Dear D community,

I would like to announce the latest release of ArcLib, Arc v.03 GUI-Physics-Refactor release. See http://www.dsource.org/projects/arclib/report/6 for full list of work done on this release.
The greatest changes were made to the structure of the project. Also includes the joystick support, camera, per pixel collision detection, sprite, and 2d lighting system.

See http://dmedia.dprogramming.com/?n=Tutorials.ArcIntro for getting started with D and ArcLib.
The real purpose of this release is that I finally got everything working and cleaned up in the trunk. I had ported the hybrid GUI, but don’t have time to support it because of the massive amount of code and my lack of familiarity with the system. I will also drop scenegraph unless others want me to keep it.

I will now create the stable branch.
- Clay

Introducing the arc.game Game class

Here is the first incarnation of the Game class. The idea behind the class is that the user will overload the this() class for init, process() for game loop, and shutdown() for shutdown code, and the Game class will handle the mundane details, such as input processing and window swapping. After creating their own class to extend the Game class and overloading the correct functions, the main loop simplifies to

// main entry
int main()
{
// initialize game
Game g = new MyGame("Arc
Graphics Primitives", Size.d640x480, false);

// loop game
g.loop();

// shutdown() is called by loop() after loop exits
return 0;
}

Here is an example I’ve modified to make use of the game class: http://svn.dsource.org/projects/arclib/trunk/examples/arc/draw.d

Of course, use of this class is optional. It may gain more features in the future, such as setting up game states and integration with the GUI. For now, its very simple.

Back from the Round-a-bout

I’m back from the round-about (South America -> Minnesota -> New Hampshire -> Finding Job)

I’ve been out for a while, but I’ve decided to clean up my project a little. I left it hanging with a broken subversion for too long.

Anyways, I want to get ArcLib fully integrated with eclipse, so I’ve installed the descent plug-in and have an eclipse project file. I plan to use xfbuild when I can get it to work, but right now its complaining about not having the –deps flag, and I can’t get the current hg clone to build. So I’m using reliable old dsss until I figure out how to replace it with xfbuild, and then I’ll figure out how to run xfbuild straight from eclipse.

I find eclipse to be an excellent editor if you have the memory to run it. It has useful features like global project search and replace with the option to use regex, and other neat features.

The news is this: The current trunk now compiles, yay! I haven’t checked to see if it works, but it should for the most part. Also, I’m not going to support hybrid and the scenegraph anymore, for the sheer amount of code they have, and my lack of familiarity with these systems. If I need, I may write a scenegraph or similar features from scratch in the future. Also, arclib should be able to be compilable with xfbuild, once I get that to work.

Speaking of Round-a-bouts, a nearby town decided to install two of them on the roads, with one on the highway. Both round-about's are design fails.

Current plans...

No decent internet connection until the 20th.

I've been thinking of hooking ArcLib up to the minid scripting language to provide rapid prototyping of games.

Some more extensions I plan on to help provide the rapid development of games as well.

arc_actors - keep track of actors in game

arc_menu - in game menu capability

arc_credits - end credits capability

arc_hud - in game hud capability

arc_tilemap - bird eye tilemap

arc_scrolling- scrolling tilemap


Some other tools in consideration...

Map Editor

Sprite Editor

Tools to facilitate rapid game development plans are the current future.

D - Good, Bad, Ugly, Pretty

Well I just got back in South America and it looks like the community is trying to get an honest evaluation of the D language so that it can plan for its future correctly. This is a healthy process (unless the complaints are ignored), therefore I will voice my opinion on the state of D, or more so what should be done for D's future success.

First of all, I see the biggest problem for D is that the community is small, and there is no incentive for the community to grow. All jobs are done in C++, Java, C#, etc. Because D isn't really old or rich, the community isn't likely to grow much in the future. From my experience, D is a hobby language and that isn't looking like it will change much in the future, not without a lot of money. I see D's small community and lack of real world jobs in D as the MAJOR problem with D, and probably as a huge reason why people try D, like it, then move on. Those who stay are not in it for the money, but the love of the language.

Second, productivity tools. You can have the most productive language in the world, but if C++ or C# has better productivity tools for refactoring / coding, the productivity of the language itself may not matter as much as the productivity gained through the productivity tools. Plus having no productivity tools scares away main stream programmers.

Third, stability. While stability is somewhat accomplished with D 1.0, there is a new DMD release, new phobos + Tango release about once every month or two. These releases tend to have small breaking changes that make old code obselete if not updated every month.

Fourth, simplicity. The simpler the language, the easier it will be for new people to pick up or maintain. Some people enjoy complexity, while I enjoy the simplest possible solution. D 1.0 is almost perfect, but IMO D 2.0 is creeping on the complexity scale. If a concept can't be quickly grasped by most programmers, perhaps it should be left out.

I really don't see the D language itself as the problem, and I see the D tool chain easily improving in the future. The real problem with D is that no one is ever going to use it in serious applications, because no one really knows it. Its not taught in the University, D has no means of spreading the word of itself, its not revolutionary enough to really catch anyone's eye. No one will use it because no one uses it, there are other languages that perform a decent job with decent productivity tools to accomplish practically the same thing as D (C#, Java, Python, etc).

So, what's the future of D? I think the future of D is in indie games. The end user doesn't care what language its in, productivity is increased, and most game bindings are already converted to the D language. Since indie games are usually written by a small team without industry experienced "bosses", they can freely choose the language they want to use.

D will continue to excel in hobby projects as well, since there is no real money stream coming from D incorporated to fund itself.

My prediction is that D's state will probably stay the same, maybe picking up some more indie game developers, for the future.

Back From SA

Back from SA: http://pcsa2009clay.blogspot.com/

Need a couple weeks to get settled down, working on ArcLib if time permits.

South America for 42 Days...

http://pcsa2009clay.blogspot.com/

Busy as Hell

In one week, I have had...
* Finals
* Graduated College with B.S. Computer Science
* Packing up apartment
* Getting ready for my 42 day South America trip

Leaving May 13... Getting back June 24th.

http://pacificchallenge.org/?page_id=18 Search South America

I will be gone for a little while, then. I also have just installed Ubuntu 9 side by side with MS Windows, but I'm contemplating making Ubuntu my main OS for this computer.

Hybrid now runs on the ArcLib Core

The Hybrid GUI has been ported to the Arclib Core from DOG.
The main issues in the process was deleting DOG and getting xf.input to run on top of SDL (thanks LeoD). In addition, I added input code to read in SDL's unicode characters. The only problem is that now when you type the backspace character, it inserts the backspace character instead of deleting text. The xf. imports were changed to arc.hybrid, as well. Besides calling

arc.window.open("Title", 800, 600, 0);
while(true){ arc.input.process(); arc.window.clear(); <--hybrid code--> arc.window.swap(); }
arc.window.close();

and renaming the imports, all the code should pretty much work the same. Here are the examples I have working so far.

So, ArcLib now has a good GUI. Enjoy!

Per Pixel Collision Detection Extension Added

There is now a collision map class in the new arc-perpixel.
Usage link.
Implementation link.

This class allows for per pixel collision detection. It can also build its own collision map circle, box, or create a collision map based on the intersection of two boxes. It can test for collision between two PerPixel classes, or it can test collision against a single X,Y point.

Software Releases...

I'm going to start using release numbers again. The release number will cover all changes to arclib-core and its extensions, and after every release I will create a new branch of ArcLib. I'm going to update the track ticket system for the current release and future release. I'll let track be my change log.

Arc (0.3) will have massive changes compared to Arc 0.2. Completely new physics system (done), scenegraph simplification (done), new GUI system (working progress), completely re-factored arclib code layout (done), as more as seen in the above log.

Texture Pixel Data...

I've changed the functionality of the Texture struct in ArcLib. Now it will save the SDL_Surface* pixel data by default, and if one doesn't need to manipulate this data, you need to call

texture.freeSDLSurface();

If one want's to access this data

SDL_Surface* img = texture.getSDLSurface();

And if one want's to re-set the SDL_Surface data of an image

texture.setSDLSurface(img);

The behavior of setSDLSurface re-uses the image's OpenGL ID number, so all images bound by that ID number will change.

Edit: Changed the default behavior to not save the SDL surface. If you want to keep the SDL surface, use
Texture t = Texture("tname.png", true); // true sets the bool keepSDLSurface, which defaults to false

*-ary tree structure

I'm in the process of creating a *-ary or N-ary tree structure, where N can be any number. It's a tree with any number of children allowed, simply because I do not like to program limitations into my code.

I'm going to use this tree structure to represent a Top Down File menu. I'm not 100% sure, but I believe this tree may prove useful for a scene graph structure as well.

This tree structure is going to be the heart of my Top Down File menu widget for my GUI. I stuck the development version directly in the trunk.

Is anyone aware of a 'standard' N-ary tree? I've found out about the K-ary tree where K is a konstant, but haven't had any luck in finding a standard way of making a *-ary tree. Also, there is no Tango equivalent that I am aware of.

BATCH files for Windows users...

For folks who do not want to use DSSS net or just want to install ArcLib / the examples from the trunk.

In http://svn.dsource.org/projects/arclib/trunk/ ,

build-examples.bat - Builds all ArcLib examples
build-install-arclib.bat - Builds and installs ArcLib and all its extensions
uninstall-arclib.bat - Uninstalls ArcLib and all its extensions

A little time saver.

Arc Light now works on more graphics cards

There has been a recent fix by cyhawk of the dsource forums to make the lighting work on graphics cards that it previously did not work on. There has also been an improvement to set the filtering to linear for the penumbrae. In addition, the lightmaps have been updated to be more accurate and I've also added the python files used to generate those lightmaps, so folks can generate their own lightmaps at different sizes as they need.



Thanks, Daniel Darabos aka cyhawk! :)

Re-structured ArcLib for the last time

Re-install the ArcLib libraries + extensions, and in the code change

arc_extname

to

arc.extname

for all extensions.

All extensions will now go into the arc/ folder, similar to how Derelict works. Each extension has its own sub-folder. DSSS can install / uninstall extensions as need be, and ArcLib can now be as big or as small as the users want it, allowing them to pick and choose which features to use.

An exciting future...

The future looks bright for ArcLib. Expect exciting future announcements, within the year if things work out.

http://arclib.pastebin.com/f7910fa49

DSSS recently updated to reflect core changes...

DSSS recently updated to reflect core changes, arc-freetype and arc-openal removed, added arc-camera.

arclib-blaze
arclib-camera
arclib-core
arclib-gui
arclib-light
arclib-parcticle
arclib-scenegraph
arclib-sprite

ArcLib intro tutorial rewritten...

Learn the premise of ArcLib and how to write 'hello world!'

http://dmedia.dprogramming.com/?n=Tutorials.ArcIntro

Stay tuned for the next seven :p

~ Clay

Font Rendering and Sound Code Moved to Core

I’ve decided that the FreeType font rendering system inspired by h3r3tic and the OpenAL sound system inspired by JoeCoder should make their way to the ArcLib core.

Different reasons why they should go into the core.
1. Other extensions depend upon them
2. They require their own dll's
3. They are essential to create a game
4. There are no viable alternatives to these systems

The release schedule plan...

0.0 - Menu
0.1 - Tile Map + Tilemap Editor
0.2 - Lights
0.3 - Add day and night settings
0.4 - Player Main Base (physical entity)
0.5 - Miner Bot (physical entity, art, sounds, AI, minid script, headlights)
0.6 - Tank Bot (physical entity, art, sounds, AI, projectile, minid script, headlights)
0.7 - Add trees
0.8 - Add rocks
0.9 - Add computer AI
1.0 - Bugs, polish, missing options, etc.

Small, manageable, implementable pieces. Let's get this thing to 1.0 :)

WarBots Ressurection Compiles Again

Hrm... After finding some missing physics code, updating to the newest tango, ignoring a new missing proc for OpenAL "vorbis_synthesis_idheader", I find that it compiles!

The joy of compiling large semi out of date projects ;)

Back on the D train...

Some interesting circumstances have lead me back to the D and ArcLib train.
There will be more development, there will be more updates.
Stay tuned.

~ Clay