ArcLib Development Blog

2nd to Last Status Update...

2010-05-21T16:37:00.000-07:00

Hey All,

I'm in the real world now, where there is less time for just "what the heck why not" projects, I need to work with my time a lot more strategically now.

I've taken up Taekwando and Hapkido, heavily recommend martial arts to anybody.

I'm probably going to start some sort of open source web toolkit thingy soon :p

That's why this is the second to last announcement.

So I'm not doing D or ArcLib anymore, someone else can take over the project.

I guess I could give some simple advice to the D folks while I'm at it :p
A) Don't make the language a kitchen sink, purge ALL duplicate features and evolutionary stumps
B) Don't split your very small community
C) Make your language inter-operate with other languages

transmission = 2
transmission--;

Reddit D link for DM

2010-01-01T10:29:00.001-08:00

http://www.reddit.com/r/linux/comments/akkj2/dread_moon_linux_andromeda_release/

Support if you wish.

Dreadmoon Linux Andromeda Release

2009-12-27T13:45:00.000-08:00

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

2009-12-27T13:36:00.000-08:00

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

2009-12-02T19:24:00.000-08:00

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

2009-11-18T17:38:00.000-08:00

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

2009-11-03T12:18:00.001-08:00

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

2009-11-03T08:45:00.000-08:00

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

2009-11-02T12:47:00.000-08:00

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...

2009-07-09T11:31:00.000-07:00

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

2009-06-26T16:08:00.000-07:00

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

2009-06-24T18:38:00.000-07:00

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...

2009-05-18T09:04:00.000-07:00

http://pcsa2009clay.blogspot.com/

Busy as Hell

2009-05-12T09:19:00.000-07:00

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

2009-04-25T06:58:00.000-07:00

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

2009-03-20T13:57:00.000-07:00

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...

2009-03-18T10:58:00.000-07:00

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...

2009-03-11T09:31:00.000-07:00

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

2009-03-09T19:57:00.001-07:00

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...

2009-02-16T13:56:00.000-08:00

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

2009-02-16T08:20:00.001-08:00

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

2009-02-01T14:21:00.000-08:00

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...

2009-01-29T18:30:00.000-08:00

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...

2009-01-24T15:36:00.000-08:00

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...

2009-01-20T15:59:00.001-08:00

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

2009-01-20T09:27:00.000-08:00

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...

2009-01-16T15:01:00.000-08:00

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

2009-01-16T14:23:00.001-08:00

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...

2009-01-14T19:57:00.000-08:00

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

Taking a break...

2008-12-28T08:28:00.000-08:00

Graduating Spring 09, looking for jobs, need to improve my C++ skills, might make a C++ game w/ C++, Lua, Box2D, Fmod, OpenGL, may look for a job as a gameplay programmer, or look for a job in a different industry and try to get into gamedev on the side.

Therefore, I'm taking a break from D for a while, and looking to start a career. I'm going to keep a blog on my game development on a different blog, Rise of Super Penguin . This game will hopefully help me crack into game development as a game play programmer.

DSSS update...

2008-11-16T12:22:00.000-08:00

DSSS has been updated so all the ArcLib extensions, including freetype, should work with the net intall.

(Offtopic) Blender Game Engine

2008-11-14T13:01:00.000-08:00

This Blender Game Engine looks quite promising.
I've been wanting to learn 3D modeling and such, and it looks like Blender is not only a full fledged modeling program, but it also has a fully featured game engine.

Learning this would allow me to learn modeling, animation, do scripting in python, and have blender do the work using Ogre and Bullet in the background.

/me needs to learn this.

arc_extname trunk change

2008-11-06T17:19:00.000-08:00

arc_extname changes are now in the trunk. This fixes the problem of arclib extensions polluting the library name space in general.

particle is now arc_particle
light is now arc_light
freetype is now arc_freetype
etc.

Free Mind - My Favorite Game Design Tool

2008-11-05T12:49:00.000-08:00

http://freemind.sourceforge.net/wiki/index.php/Main_Page

Let's you map out all the ideas for your game on a tree, and export it to cool formats. A great tool for organizing ideas. I use it for trying to think of every possible feature to be implemented into my game, the levels, the setup of a level, the menu, etc. Once the mind map is complete and very detailed, it gives a really good solid foundation to start coding with. It also is a good tool to show how complex a seemingly "simple" idea is, and the feasibility of such an idea.

If you can't mind map it, you can't code it.

I'd suppose this would work well for any large software projects.

ArcLib status + The Problem with D

2008-10-16T08:20:00.000-07:00

Just a short time to post, spending most of my time finishing up college, looking for jobs, thinking about the possibility of graduate school.

ArcLib status: ArcLib development should be considered "on hold" until about May 8th, 2009. I'm leaning towards doing some more work on ArcLib after that. It is already on solid ground and the D community is fairly awesome.

The Problem with D: From a language standpoint, there is one major problem with D, and that problem is that D is not C. I have a feeling that most serious system level projects (Operating Systems, Game Engines) are done in C, because...

1. C is everywhere, there is a compiler for every system
2. Everyone knows C, it is tried and true
3. C is a better language to program in than C++ for large scale projects. The C++ STL is not up to par, and C++ adds more complexity than useful abstraction. Game companies that do use C++, like EA, implement their own version of STL. I'm guessing they also use a restricted subset of C++ features.

I think what is holding D back is
1. You can not find a D compiler for every system
2. Not many people know how to program D
3. There is too much legacy code written in C++ / C

Problem 2 and 3 are problems due to marketing and language maturity. Also, as more code gets written in D, even more code gets written C++, so the amount of D code will probably never be able to eclipse C++ / C code.

Problem 1 can be addressed, but needs to be addressed via the community like what is happening with the LLVMDC project.

So, D will probably stay as being a very niche language in the ecosystem of computer language's, catering to those few independent minded folks who do not need to program for the Ps3/X-box, etc., and who actually value the beauty of a language over it's acceptance in the world, and who don't mind having to re-invent the wheel. These "problems" are actually acting like a filter, and so the D community itself is very cohesive.

WC Release v.2 - Lights

2008-06-27T21:17:00.000-07:00

I've integrated lights into the tile map, and I've allowed the editor/game to place, save, and load lights.

The yellow dots and the red polygons are there only for debugging purposes only, and I will soon get rid of those as I smooth out the system.

I also ditched the scenegraph system, as it was too complicated for what I wanted to do, and instead resurrected my old Camera class which allows simple transformation of the screen to give a scrolling effect. The new camera extension can be found in my ArcLib svn.

Lights are a really nice way of bringing the detail out in the scene, and prevents it from looking boring and repetitive. Thanks Christian K and OrangyTang!

So, for the lights, it seems like I will be using those for a 'Fog of War' type system for the bots. The bots will have a limited vision range, which the programmer can see by the current area it illuminates.

Now that lights are in, the next big step will be to integrate the lights and tilemap with the excellent Blaze physics system.

Until then...

Game Delay...

2008-06-23T09:39:00.001-07:00

The game is going to be delayed a little bit. I don't have anything to show in this post, but the next post should be amazing... when it's done.

WCR Release .1 - Tilemap + Tilemap Editor

2008-06-06T16:26:00.000-07:00

Tilemap and tilemap editor is complete. Can edit tiles, save to XML, and load tiles again. Most of the code taken from the Tankwars project.

Quickpost this image to Myspace, Digg, Facebook, and others!

WCR Release v0.0 Main Menu

2008-05-30T11:09:00.000-07:00

The first installment of a series of 11 releases, the first being the main menu.
I had to add a new shape to arclib, the drawRoundEdgeRect shape, and then I created a new GUI theme "WarCoders" and I created the mainscreen.xml for the GUI.

Below is a clickable thumb:

I decided to steal the mars rover shot for my main screen because it looks nice, its a robot on a foreign planet, and that planet is Mars. I made the title text with cooltext.com as well, and am using a dungeon.ttf for my main screen font.

There is an options button, but currently doesn't work. I'm hoping I'll have time to get to it at the end, but it is not really too important.

While I won't host on dsource as its own project, it will be hosted here for backup: http://svn.dsource.org/projects/arclib/dev/warcoders/trunk/game . This folder has all the dll's and exe required for windows users, btw, so if you want to svn up along, feel free. *nix users, you are good at compiling ;)

I'm writing the code from scratch but taking inspiration from my TankWars setup, which seperates game media and game source, and then moves the exe to the game media folder after a successful build.

WarCoders Ressurection

2008-05-28T09:46:00.000-07:00

So now that ArcLib is basically "finished," I wanted to put down game programming for a while, however my ancient past has come back to haunt me, so I must complete the cycle, and build the game that originally started me off on ArcLib. When the game is complete, I will simply just maintain ArcLib / the game, probably stopping development, or just do tiny incremented dev here and there.

The game will be named WarCoders Ressurection, and each week until Aug 15th (the completion date) it will have a release. The whole development is completely planned out. I will not create a dsource project until the 1.0 version is done. There will be a total of 11 releases + accompanying screen, which I will just post on my blog here, and save 1.0 release for the D newsgroup. The project will use minid as its scripting language.

With that, stay tuned...

Light package

2008-05-27T11:15:00.001-07:00

The light Arclib extension is more or less done... the beauty of extensions is that they are a lot quicker to make and maintain instead of trying to put it all into one giant library, and then can be dropped out for better ones in the future if necessary.

Just so folks know, this code was mostly written by Christian Kamm. Here's a screen:

Maintainance fix ...

2008-05-27T08:02:00.000-07:00

ArcLib GUI now works well. The light demo doesn't crash, and I will soon make a lighting extension.

Current arclib + extension features...
1. 2d physics
2. gui
3. freetype font rendering
4. openal sound/music
5. particle fx
6. sprite

To be soon done
1. 2d lighting

"WarBots" blockers are now...

1. Simplified scene graph
2. In-game text editing component

Networking would be nice too, but not necessary.

ArcLib to begin maintenance phase

2008-05-15T06:45:00.000-07:00

Arc has been an interesting spare time project. Arc began in 2005 as a library that needed to be developed in order to complete my Warbots game project. After 3 years, it slowly took on a life of its own as I forgot about Warbots. I wrote code that would be useful to me and assimilated it into one library.

I have learned much about the D language, binding, and writing 2D game style code. I’ve had fun, but time doesn't permit anymore to actively develop 2D game code.

ArcLib will now move into maintenance phase. For this maintenance phase I have split ArcLib up into an ArcLib core and several extensions.

Current Arc Project Structure
1. Arc Core
2. Arc Extensions
- Blaze 2d physics
- Freetype font rendering
- GUI (currently crashes, however, due to assocArray.keys call, but tech has worked well in past)
- OpenAL sound
- Particle system
- Scenegraph
- Sprite

These extensions will all depend on the ArcLib core, but compatibility between extensions will not be guaranteed.

From now on, ArcLib will be on a yearly maintenance cycle.

ArcLib and all its extensions should soon be installable via DSSS as well.

Only example code will be kept up-to-date, tutorials and the like will not be.

ArcLib all-in-one vs. modular design

2008-05-01T08:03:00.000-07:00

Forum thread: http://www.dsource.org/forums/viewtopic.php?t=3861

Here's an idea that I'd been thinking about in my head a while, about
which design route I should be taking ArcLib in.

1. Modular design
- Arc Core Library
- Arc Scenegraph
- Arc Particle
- ArcLib compatible Blaze
- etc.

2. All-in-one design
- The way it is now. Everything is well mixed together.

I'd rather stick with one design or the other, to have a strong design
philosophy behind the library, at least.

I've been leaning towards the all-in-one design, which is what ArcLib
is currently, for ease of use. However, to keep up with this design, I
/will/ need to integrate Blaze directly into the ArcLib code base. It
also puts the pressure on me to maintain / develop more code, and
slows down the release cycles.

Recently I've been thinking of a modular approach as well... this
approach works well for the SDL library (SDL_image, SDL_ttf, etc.) It
would allow game programmers to 'pick and choose' which components of
ArcLib they would want to use, and the core of ArcLib would become
really well polished. DSSS would remove the pain of installing all the
libraries separately. This way, different members of a future 'arclib
community' can make arclib compatible extension libs and people can
choose to use them or not, and my 'GUI' implementation would have the
possibility of 'disappearing' if a better one from the community
emerged, or certain sections of arclib can be redesigned without
really much of a problem.

Anyways, I've been struggling with these ideas for a while and kind of
want to know what others think about them.

Last 2 weeks of semester....

2008-04-12T13:55:00.000-07:00

Last 2 weeks of the semester... nuff said.

Just posting to say I'm still thinking about ArcLib stuff and expect some new stuff for the summer, but right now and for the next 2 weeks I'm totally booked to the point where I can't even write a decent blog post about it.

Tango XML and Blaze

2008-03-16T10:43:00.000-07:00

Blaze is nearing a 1.0 release. See Announcement. Blaze supports 2D physics for polygons, and has recently added joints. Since Blaze is too fast for me, I added some timing code into the Blaze demos that will cap the frame rate on faster machines.

I also replaced my XML code in ArcLib with the Tango XML code. The whole process was pretty simple, I only had one or two questions for the Tango folks about Tango XML, and then using Tango XML allowed me to reduce my lines of code count quite a bit, too.

First Blaze 2D Physics Engine Release

2008-02-17T12:37:00.000-08:00

See the announcement for more details.

Get the Windows Demo: Blazed-Demos

*nix Users: dsss net install blazed-demos

What does this mean for ArcLib? It means, finally, that a major roadblock for Arc v.3 (polygons in physics) is removed, and all the built in Box2D Lite stuff that was built into ArcLib will be removed, as well.

Also, the next release of Tango looks like it will feature XML, so I can remove my own XML code from ArcLib in the next release. I can also remove a bunch of my templated code in ArcLib, thanks to Tango.

Box2D4D Officially Abandoned...

2008-02-15T06:53:00.000-08:00

If someone wants to pick up where I left off...

1) branches/ has the old c++ --> D port and the attempt at a java --> D port
2) I think trunk/ may have the new c++ --> D port

The reason Box2d4d is being abandoned is because...

1) Impossible to debug (been trying to debug it for about the past 3-4 months)
2) Code is too complex for its own good
3) There is something better on the horizon...

:)

~ Clay

GlazeD, Chipmunk --> ActionScript 3.0 --> D

2008-02-11T09:36:00.000-08:00

Alright, so box2d4d is a no go because it is impossible for Mason and I to debug. If somebody else can figure it out, feel free.

So, Mason found an Action Script 3.0 port of Chipmunk, except that it doesn't support joints. We are now trying to convert it to D, and it does compile but we haven't had the chance to figure out if it works or not.

As usual, I kept my habit of making doc comments. Here are the Ddocs.

So, hopefully this one will be easier to debug because it is simpler, and this one at least supports polygons.

Then, if we get it to work, Mason will base his rb2d efforts off of glazeD and add various features and things to it over time.

And, the big picture for me is, that I will have a physics engine in native D that I can integrate into ArcLib, that I won't have to maintain or add new features to myself.

Play Tankwars on Win32

2008-01-28T20:07:00.000-08:00

Alright... probably should have posted this a long time ago... but here is tankwars for win32. For *nix users, wine will probably work.

Just in case anyone out there on windows wanted to try it.

Box2D4D 1.4.3 Documentation

2008-01-24T12:08:00.000-08:00

Box2D4D 1.4.3 Docs

Ok, so I started over again with the latest box2d, and one of the things I did this time, was to give every variable and function a doc comment!

I got it to compile, and immediately compiled these docs.

Enjoy, Box2d fans :-P

On a side note, here's a link to a promising 2D physics engine written from scratch in D, rb2d. You can obtain it with 'dsss net install rb2d.'

Both these projects are one man wonders, so if there are any 2d physics programmers in the D community, feel free to jump in and join the fun!

TankWars Screen Shot

2008-01-15T10:01:00.001-08:00

http://svn.dsource.org/projects/tankwars/downloads/screen.PNG

Just in case anyone didn't see it on the project page.

ArcLib Development Slowing Down...

2008-01-14T18:24:00.000-08:00

ArcLib has been slowing down its development rate. I simply don't have the time to develop as much as I used to, so development from now on will probably be in short spurts every couple of months or so, and be more into a maintenance phase.

~ Clay

Finishing TankWars

2007-12-05T11:34:00.000-08:00

It's the end of the semester, and my partner and I spent about 7 hours yesterday finishing up tankwars with about 30 svn commits total, mainly loading tanks and helicopters and allowing them to randomly move and shoot on the map, adding sound effects, and letting the player shoot at the tanks. We had some trouble trying to get the tank pointed at the player, even using the point.angle(point) function, which we never resolved.

If you want to check out the final (unfinished) product, svn co svn.dsource.org/projects/tankwars/trunk/game, and run game.exe. There is a level editor that allows you to place objects and there is a game that allows you to 'play.'

Anyways, unless I get some abundant future free time, this project will most likely be stalled from this point onward, as I'll probably be spending time on my arclib and getting that in better shape.

Box2D for D, take three

2007-11-24T17:38:00.000-08:00

Alright, the java port was not giving me the correct output that I wanted. So, I decided to take the C++ D port, remove the memory management code, and implement the java solution for dealing void*'s. Now I'm getting an assert error. So, what I'm going to D, is mostly use the C++ version to base off of, and trace the C++ code versus the D code to see where I have gone wrong.

Box2D for D, take two

2007-11-19T16:19:00.000-08:00

Alright, so I become stuck on box2d4d not only with the custom memory management code, but also with all the pointers, of which Erin Catto is a fan of. I didn't really have time to deal with the pointer problems, so I'm taking a different strategy.

There is already a java port of box2d, so I'm taking that code and porting it to D. I already got it to compile. After I get some examples working, I will then add doc comments, upgrade it to the latest box2d version, and perhaps the re-implement custom memory management.

The box2d4d project already has more files than my own ArcLib project has, to give an idea of the scope of the project.

TankWars Development Update

2007-11-15T10:33:00.000-08:00

The media is almost all complete. All required sound effects, and still images of the tank, helicopter, and person, as well as missle and tank shell. We have some tiles too. We still need person/tank/helicopter fire muzzle flash, destroyed vehicle art, and some dirt tiles.

Also, the XML level reader and writer is 90% done, the last 10% will just be testing it to see if it works.

My next task is to hook up the editor with the level reader and writer.

ArcLib get's a logo...

2007-11-13T09:19:00.000-08:00

Keyframe win's the logo contest! Many thanks and appreciations to all those who entered. It was a difficult toss up for me between CodexArcanum's logo and Keyframe's logo, but I feel that Keyframe's logo has a more professional look, and indeed more professionalism will be the theme of the Arc v.3 release as I believe that will be the first one on which real work can start being done with games and such as things start to stabilize and the scope of Arc is realized.

ArcLib Logo Contest Final Showdown!

2007-10-30T16:41:00.000-07:00

The ArcLib Logo contest final showdown has begun! There have been a lot of good logo submissions, and there is still time to submit a new killer logo.

Here is the link to the final logo contest thread. As you can see, if you decide to submit a logo based on the specifications given in that thread, you can guarantee you'll win if you submit the only one and it is somewhat decent.

Good luck!

TankWars Editor Interface Complete

2007-10-29T12:37:00.001-07:00

I've completed the TankWars level editor interface... you can now change the tiles on the tilemap and place game objects on the screen such as Tanks, Helicopters, and rocks. My group member is working on loading and saving a level with XML, and once that is done, the editor will be able to load up levels, edit them, and then save them back as XML files.

The editor is really simple and consists only of 'hotkeys' to edit. The most difficult part for me was simply trying to think in terms of a scene graph, but that took me a day or so and then I figured it out. The way I have my scenegraph set up right now is like so...

WorldTransformNode
-> TileMap (draw all the tiles)
--> Mouse notify node (sends signals to tilemap when mouse is clicked, gives relative mouse coordinates to the tilemap, based on transformation)

The advantage of the scenegraph is not having to calculate transformations myself, which saves a lot of hassle and is worth it once it is figured out.

Also, one of the aspects of Arc v.3 that I'm looking forward to is a large reduction of code without any loss of features :) This will be accomplished by moving all physics code to another project, simplification of the scenegraph, and reliance on Tango's template containers, as well as a possible re-factor.

TankWars Update...

2007-10-23T20:53:00.000-07:00

Here is a little update on my semester long class project that is now 'officially' started.

The TankWars main screen is pretty much complete, it just needs a 'resume' button and a title. It has a 'New Game' button, an 'Editor' button, and an 'Exit' button. When the new game button is pressed, it takes you to a screen that shows a TileMap in a world transform node that can be controlled with the players keys.

Nothing too fancy yet...

I myself am semi-new to the scenegraph in Arc, I havn't really done too much with it until now. I got myself running with it pretty quickly from the scenegraph test, however. The scenegraph is probably not the most newbie friendly concept, and today I thought that it might help to store a scenegraph scene in an XML file and have some sort of scenegraph builder program. It would shorten the users code dramatically, and the scenegraph could be seen visibly as it should be. Until then, ArcLib users need to be pretty proficient in programming to use it.

Development halted for a week or two...

2007-10-17T13:31:00.001-07:00

Alright, development has pretty much halted for a week or two. This week I have 3 midterms and this weekend I went to the ACM conference and watched presentations by the founder of the XKCD web comic, the guy who wrote the digg.com software, the authors of Girl Genius web comics, and a few other presentations.

When I get time, I'll be working on TankWars.

Flashbacks from the past...

2007-10-04T17:10:00.000-07:00

Today, I delighted myself by stumbling on one of my old school WarBots projects. Before I started ArcLib, the project was actually called WarBots and was meant to finish a game that me and my friends attempted to build in High School but never got very far because the lame school admins shutdown the project from their lack of competence (grrr... see: http://warcoders.sourceforge.net/ for more info on what the project was meant to be and how far we got).

Anyway... I ran the exe and amazed myself at what I could accomplish in 2005 with limited D and OpenGL knowledge back in the day, when compiler numbers were still in the .70's and one had to write their own bindings from scratch.

For the curious, here's the way to access the files via SVN.

1. svn co -r 172 http://svn.dsource.org/projects/arclib/ warbots/
2. cd 'warbots\trunk\current'
2. Run 'game.exe'

To interact with the game, click the building, click 'train unit,' type 'miner' then hit enter. Then proceed to witness the miner vehicle collect metal scrap on the map. It uses per-pixel collision detection and a lua script to define the miner's AI.

I'm also amazed that SVN actually kept /EVERYTHING/, I'm afraid to know how much space my project takes up on poor old dsource.

The part that gets me is that I didn't even realize how far I got on that project.

And, as time passed, I decided I needed to write a good generic 2D game library before attempting to write any more game code. I've discovered that large projects have a 'point of no return' where, once the project reaches a certain size or complexity, more and more manpower must be used to achieve less and less of a result.

WarBots reached that complexity for a 1 man project, and ArcLib was the answer to reduce it. Look how far it's gotten me ;)

Current Development Highlights ...

2007-10-03T12:28:00.000-07:00

1. ChristianK was able to figure out the problem with one of the D files crashing. Apparently it has to do with forward references and enums, and putting an enum in its own file fixes the problem. For the curious, here is the actual bug link.

2. Box2d is almost able to compile, there are just a few last minute memory management codes that need to be implemented and some other small fixes in b2World before it will be able to compile. After it can compile, then the next stage is getting it to work.

3. When working on my TankWars game, I ran up against an OPTLINK bug. Thankfully, that was fixed by using the beta linker found in the bugzilla issue. All that is done for the project is the project layout and a simple 'main screen' for the game with 3 buttons, New Game, Editor, and Exit.

4. I'm really busy. Most of my time will go to my new TankWars project I'm working on for a class, and if I do get any free time, I will be working mostly on the Box2d4d port.

5. ChristianK has implemented some really sweet particle effects in the current development version of arc & asteroids.

6. Tango's logging system is really nice. Each module can have it's own logger, and each logger is part of a tree hierarchy, so you can grab a hold of the root logger and then output all the information of each logger anywhere you want, I like to use the FileAppender. The output looks like this.

Box2D C++ porting woes...

2007-09-20T18:28:00.001-07:00

My projects are somewhat stalled now, due to the porting of box2d.

1. This problem has stopped me for a while, until I gave up and asked for the answer on the Box2D forums. I knew what pointer + i was, but pointer - i is new to me.

2. D compiler crashes when trying to compile some of the .d files. I'm hoping this will resolve itself as I get more and more D code to compile. If not, it's another potential time waster as I look for a work around or wait for a compiler fix.

I still have some hope that I can get it done soon, though.

Box2d, for D!

2007-09-14T12:34:00.000-07:00

Alright. Erin Catto's Box2D (www.box2d.org) is going to be /the/ 2D physics system, as the success of his original Box2D has already created many spin-offs.

I want to be able to have access to the most advanced 2D physics I can have in ArcLib, but keeping the physics system up-to-date with Erin's new stuff is going to prove a challenge, and in order to accept this challenge, I started a seperate box2d4d project on dsource which aims a providing a close-to-source as possible translation of Box2D.

The ArcLib physics system upgrades is now a three step process, now without pressure of us ArcLib developer's having to develop new physics features ourselves, but merely staying up-to-date.

The pipeline goes like...

Erin Catto Updates Box2d --> box2d4d updated --> arclib updated if needed to support latest version.

Simple, mechanical 3 step process. The first pass will be the hardest, the rest will be easy and I can concentrate on other aspects of ArcLib, like lighting and the API. Until then, my time will be spent on box2d4d.

~ Clay

Requested Project on Dsource

2007-09-11T11:34:00.000-07:00

Today, I gave my partner the run down on arclib, had him install D + DSSS + Arclib, and requested a dsource project for the game.

~ Clay

About this Blog and New Untitled game project in the works...

2007-09-08T13:29:00.000-07:00

About this blog:

I'm going to use this blog to post about the development of my ArcLib Project and my game projects that I will design using the ArcLib.

Untitled Game Project

I'm going to start making a game for a class this semester, for my graphics class, and it's going to use the ArcLib. I've convinced one of the class members to use D and ArcLib to work with me on the project, as we have to work in teams. I've already started the first stage of game development: writing down my concepts on paper. The goal for the game is to be fun and to be complete within one semester. Here's what ideas I have so far for the game, which I wrote on paper first w/ pictures, and I re-wrote it here as well. Paper + Pencil = greatest way to write down concepts.

1) Codename: Tank Wars.

Terrain styles: Desert and grass

Mission types: Destroy all enemies, stay alive for X amount of time, and retrieve enemy data and bring back to 'base'

Vehicles: Civilian, Tank, Jeep, Truck, and Helicopter, along with weapons that correspond to each vehicle.

Graphics: Photo-realism would be nice...

Levels: Either randomly generated, or loaded from an XML file

Soundtrack: Maybe some techno

Game Objects: Tree, rock, buildings

Features needed to do: Tilemap, lighting, custom GUI theme

11 Steps to get the project done:

Prototype 0: Custom GUI theme and start menu and player hud
Prototype 1: Wire frame tank that moves with other tanks on the map
Prototype 2: Tank Graphics
Prototype 3: Sound Effects for the tank, and tank Weapon Fire, Sound Track
Prototype 4: Implement Destroy All Mission
Prototype 5: Implement Game Objects
Prototype 6: Implement Jeep vehicle and civilian vehicle, and allow civilian to enter and leave vehicles at will
Prototype 7: Implement truck vehicle
Prototype 8: Implement helicopter vehicle
Prototype 9: Implement the rest of the mission types
Prototype 10: Implement lighting effects and night/day time settings

Of course, the prototypes are just a rough guide of how to get a game complete with manageable chunks.

Player Keys:

Enter: Enter / leave vehicle
Space: Fire weapon
Arrow Left-Right: Rotation Left/Right
Arrow Up-Down: Move Forward/Backward
Caps Lock: Turn on-off vehicle lights

ArcLib Project Recent Developments

1) Christian Kamm has developed some cool lighting, which will slowly make it's way into Arc.

2) I fixed the GUI theme system to be an over-loadable class so users can simply write their own themes for their own games. I also need to make a default theme in Arc that looks sort of decent but doesn't require any user-graphics.

The reason for this whole theme thing, is so users can make the GUI look pretty themselves, and I don't have to worry about GUI prettyness, just it's functionality instead.

As I attempt to develop a game this semster, most of the development I will do on Arc will probably be making sure existing features work well, and the MultiLineTextBox and other 'from scratch' features may have to wait.

~ Clay