TexturePacker and Tiled

Tags

game development, games, google, html5, sprites, texturepacker, tiled

I recently watched a video on YouTube which was talk at google. The guy was talking about game development in html 5. I am not interested in html5, but I am interested in game development, so I decided to watch it while I was lunching (yes, I am that geek).

Even though I am not a game developer, I want to write some simple games, and that speech had interesting information on it. Among other things, it recommended tools for game development: Tiled and TexturePacker.

Tiled lets you build and experiment with sprite files. It’s mainly used for creating maps, but you can use it to build whatever you want, give you can build it by putting together images of sprite files. It’s very useful to just be able to build stuff in tiled and see how it’s going to look like so you can do it in your game.

TexturePacker lets you build sprite files. You put sprite files and/or single image files together, and specify the relevant parameters, and it’ll give you one sprite file with all your images. It’s very useful so you can edit/create images individually and simply build your sprite file later.

Honestly, I haven’t heavily used them, but they look really interesting.

Tiled, you can get for free.

TexturePacker, you can also get for free, in some cases. I found this by accident while looking at its website. You can request a free license for TexturePacker if you can prove to the author you meet his requirements (which are explained in the page). I filled the form in there, honestly I wasn’t expecting from an answer, but to my surprise, I actually got it.

The author of TexturePacker has other tools, such as PhysicsEditor or SpriteSheetMovie. He also wrote a book, but I honestly have no idea about those. Look at the websites!

Anyway, these two tools in combination look really good. You can experiment, test and build with tiled, and use TexturePacker as your sprite builder, as you incrementally build sprites (nobody comes with perfect sprites on the first try). The ability of building individual sprites, packing them, and then trying them out look really interesting.

Yet on the Space Invaders Game TSpace

Tags

game development, programming, tcl, tk, tspace

In my last post, I “released” a space invaders game written in TCL/TK. It has its own scheduler and task queue, which it uses to find out which thing on the screen has to be updated. It turns out that these things are done by the TCL implementation too, and it’s likely that they’re more efficient than the one I wrote.

So I modified the code to be a much simpler (without save/load, sounds and speeding up or down features) version of the game using the after command instead of implementing my own scheduler/tasks queue.

Just to be clear, I still could have the save/load, sounds and speeding up/down features if I wanted, with as much ease as in the other versions. I removed them simply because I wanted this stripped version of the game. Using the after command doesn’t imply in not being able to have these features, or in having a harder time in having these features. I could have kept them just as easily.

I actually liked TSpace, and I am likely to keep playing it. And I don’t care about sounds, save, load or messing up with the game speed. That’s why I took these out. I wrote them in the first place because I saw that I could, as a direct result of the different designs that I tried.

The interesting thing about this version is that it doesn’t try to re-invent the wheel, but uses what is already built-in in TCL. And it turns out that it ran much faster (notice that the other version may get slower later in the game, when you get lots of points, but it’s mostly because of the amount of sounds that are played with that many enemies missiles being shot at you — if you take the sounds off [not just turning the sound off in your computer, but actually changing the source code], the slowdown is not so much noticeable).

Here is the code: http://pastie.org/pastes/4598169/text.

To run it, you should use the image files from the TSpace game posted in the previous post.

(Much) Improved Space Invaders Game [in TCL/TK] – TSpace

Tags

game development, programming, space invaders, tcl, tk, tspace

In my last post, I sort of showed that it was very simple to put a space ship image on a black background with some asteroids floating around. Also having the space ship being controlled by the arrow keys and being able to shoot the asteroids.

Well, I decided to evolve that little game. The result was still a little game, but much better. There are screen shots in the end of this post.

The game went through some phases. The first one was that of the last post, which was pretty much a “can I do this?” thing. The second one was using the coroutines feature of TCL 8.6, which made the game much easier to extend. However, this second version only was a re-write of the first one. Then a third one was an evolution of this second one. I took the extendable version using the coroutines feature and started adding things to it.

This third version was a major breakthrough. It allowed pausing the game easily, also increasing its speed, or decreasing (you could use the plus and minus keys to make the stuff move faster or slower on the screen). Adding stuff was also much easier.

The basic idea was to dynamically generate coroutines, each to control an item on the screen. There was a scheduler function, which would go round robin on these coroutines. Pausing the game just meant telling the scheduler to stop looping through the coroutines queue. Messing up with the game speed was basically changing the milliseconds interval between each iteration in the scheduler.

Also, items on the screen were pretty independent, because they each had its own coroutine. So it was quite a nice thing.

However, it was generating a lot (really tons) of coroutines. And I wondered if I could do differently, just to see with what I’d end up with.

Then I had the idea of having a few controller functions which knew how to deal with different types of items on the screen. For example, the ship controller, the enemy controller, the missile controller. These functions would see the current situation of some item it can control, update it and produce its new current situation. This was the fourth, and current phase.

Each situation is actually called a task, because they replace the coroutines. A task has a procedure, which can perform it, and a bunch of other data (such as x,y position, image type, etc.). The scheduler, which used to run coroutines, now deals with a queue of tasks, and at each iteration, it takes a bunch of tasks, and run their controllers (which would be stored in the task’s procedure field) on the task by getting tha task controller and calling it on the task.

The advantage of this, now, is that the data needed to continue the game, from a given point, is more accessible. Which means that saving and loading game is trivial. And so, I wrote the save game and load game procedures. They pretty much saved this tasks queue, along with some other things, but the tasks queue is the major thing. And the load game function pretty much reads the saved data, and re-draw the canvas accordingly. Each task also has a load function associated with it, which could re-draw an item given its current situation, reflected in the task.

An important feature of TCL played a major role here. And it’s the feature that “everything is a string”. Since that’s true, to save the task queue, all I have to do is print it (there is no code for serialization, or any sort of conversion). And to load it back, I just read it (there is no code for parsing). That’s it. I mentioned some posts ago that  things are a little different from “everything is a string”, however, the language gives you that illusion, and you can program as if that was true. A more, it seems, accurate thing to say is that everything has a string representation. Being able to get the variable value by having its name stored in another variable also helped because it allowed for “the list of variables to save and load”. Currently, if I wanna add some more state to the game, then the code that causes that state to be saved/loaded is close to nothing; I just have to add the variables names to that list of things to save and load.

In an OO style, you could have a task interface, which has a load and iterate methods. And each screen item would have its controller, which would be classes implementing this interface. The task queue would then be a queue of tasks, and the call to iterate and load would perform dynamic dispatches. Obviously, you don’t need classes to do this, so a non-classic OO system also would allow this. And, in TCL, since you can use the value of a variable as the name of a function to call, you can just generate the name dynamically and call that (getting dynamic dispatch in effect). So, it may be that, in TCL, doing the OO actually complicated the program. Anyway, I didn’t do it this way also because idk how to yet. I still haven’t learned how to use OO systems in TCL.

That being said, if you wanna take a look at the game. I uploaded it on 4shared.

http://www.4shared.com/rar/HQHHcoAg/tspace.html

Here is how you play the game:

• The arrows move around.
• S saves the game.
• L loads the game.
• + and – and 0 deal with game speed.
• P pauses the game.
• F is the simple shot.
• D is the triple shot.

To run the game, you need a TCL implementation with the snack extension. An easy way to get it is by getting active tcl, and installing snack after done that. Here is how to:

1. Go to the downloads page, http://www.activestate.com/activetcl/downloads
2. Get the 8.6 version of active tcl (it cannot be the other older ones). You should also get the 32bit one, because iirc, snack is not available for 64bit. Even if you run a 64bit windows, you can download the 32bit version and it should all work (which I just found out recently).
3. Install active tcl.
4. To install snack, go to the command line and type “teacup install snack” and wait.
5. A friend of mine had the problem of not getting the Img package out of the box, and he had to install it. So you may need to. Do it by typing “teacup install Img”.

That should be it.

To run the game, extract it and double clicking on the tspace.tcl should do fine on windows. On some linux, you probably will run on the command line with tclsh.

And as a side note, I also found out I cannot spell words very well: I’ve been writing ammOnition and missIle (you will find this in the whole source code).

The images and sounds of the game were not created by me. I got them from sources I could use for learning purposes. Here are the credits (which you can also see in the sources.txt file in the .rar file of the game).

• The space ship images were gotten from http://prinzeugn.deviantart.com/.
• The explosions were created by GuShH, and they are from these two pages: http://gushh.net/blog/free-game-sprites-explosion-3/ and http://gushh.net/blog/free-game-sprites-explosion-4/
• The two missiles used I got from iconsarchive, http://www.iconarchive.com/show/arcade-saturdays-icons-by-mad-science/P-Type-Missle-icon.html and http://www.iconarchive.com/show/arcade-saturdays-icons-by-mad-science/E-Type-Missle-icon.html. Notice that, although I got it from iconsarchive, the images were created by this MadScienceLabs How artist.
• The ammunition graphics came from a really cool icons archive, also in the iconsarchive website. The author page is http://www.iconarchive.com/artist/julie-and-mark.html and the particular icons set is this one http://www.iconarchive.com/show/star-trek-DSN-icons-by-julie-and-mark.html.
• The asteroids graphics came from here http://trac.assembla.com/pragman/browser/Portfolio/Asteroids/sprites/ASTEROIDS.png?rev=10
• The sounds came from soudible, each sound page follows: http://soundbible.com/538-Blast.html, http://soundbible.com/1636-Power-Up-Ray.html, http://soundbible.com/1087-Laser.html, http://soundbible.com/472-Laser-Blasts.html. As with iconarchive, soudible only hosts the files. To find out the author, you should look at the particular sound page.

If you find bugs or that something is missing, or strange, post as a comment please. I just found out I forgot to put two required files in the rar archive (which is now fixed). So, if anything, write a comment please.

Updage: I found some bugs after I wrote this post. So if you find a bug, maybe re-downloading the package (which I just updated) may help. But comment anyway =).

Here are some screen shots:

Simple Space Ship Game in TCL/TK

Tags

asteroids, games, programming, space ship, tcl, tk

As I mentioned in my last post, I just started learning TCL and TK.

Well, yesterday I decided I would see if I could put a image of a space ship in a black baground, and make that image be controled by the arrow keys. After one hour or two I did that. And I thought “well, this was really easy; maybe I can get it to shot if I press F too”. Then I went on, got the image of a small missle, and made it move from the ship to the top of the screen if I press F. After that, I found asteroids images and put them rolling and moving in the screen and made a space ship game for shooting asteroids.

I started making (learning how to) the game 7 or 8 pm yesterday and finished 9 am today (yes, over night).

And it was really simple. It’s worth pointing out that the code is pretty much a bunch of stuff on top of eachother: not a well tought design. It works because the space ship game is small and simple.

If you want to play the game, you can get Active TCL from here, and then install it. After installing it, do these things:

1. Get the game source code here.
2. Save the game source code in your computer, name it prog.tcl (or anything, but I will assume you named it prog.tcl, and put it in some folder, X).
3. Save these images in X, with the indicated names:
   1. http://i50.tinypic.com/21mzq07.gif – asts.gif
   2. http://i49.tinypic.com/256e1cw.gif - missle_1_1.gif
   3. http://i45.tinypic.com/2ptc7c0.gif – ship.gif
4. To run the game, install Active TCL.
5. Open cmd.exe on your windows machine.
6. Go to the folder X.
7. Run from the command line, in folder X, “tclsh prog.tcl”
8. Have fun.

On linux, install TCL from your package manager, follow step 1 to 3 and run the game by following step 7.

The game is really primitive. There are no sounds, no explosion effets, nothing fancy. But it is very cool =).

Here are some pictures.

Getting into TCL TK

Tags

tcl, tk, weakly typed

I’ve, these days, just started learning TCL and TK. I’ve always heard it’s a simple way to build GUI, and that both the TCL language and TK were easy to learn.

The people who told me that were right.

A part of it which I think many people would have a problem with is its type system.

The language is weakly typed, and before people starting to jump on me for saying such a thing, let me explain what I mean by that.

In TCL, you’re supposed to program by considering that everything is a string. Internally, that’s not how it works for performance reasons, but every value have a string representation, can be converted back and forth to strings, and will be so whenever needed. When you add 1 and 13, you should see these two as two strings which get parsed by the command which performs the addition operation, and then added internally, and then converted back to you as a string. Again, it’s unlikely to happen that way for performance reasons, but it’s given to you the illusion that this is how things are getting done.

The conceptual model of TCL is (together with some other stuff) that everything is a string.

It’s a little bit like in lisp, in which you have the illusion that your program is a lisp list. Which is not true, although the implementation gives you the illusion of that. Internally, many lisp implementations will interpret your code in strange ways, or compile to some other format (C, JVM Byte Code, CLR’s CLI, some internal byte code format the implementation uses, …).

In TCL, part of your code gets “bytecode compiled”, but part also remains interpreted.

Because, conceptually, you have the illusion that everything is a string, that’s how you should program (there is no other way): all your data are strings. That’s your only data type! Which means the string format is what says what “data type” you’re dealing with: “abc 12 d” is a list, also is a text, but not an integer; “1241″ is an integer, but “12314121441312415145677872″ is not an integer (sizes), and both are lists (of one element). This means that performing list operations on integers are fine because there are no lists or integers. The operations on lists only suppose the string has a list format. Thus, “conversions” (or “looking at the value from another perspective”) happens all the time (of course that, conceptually, there are no conversions; everything is string).

Which is why I say it’s weakly typed.

It’s also dynamically typed, because the various “data types” are not attached to any particular variable. A variable that used to hold what is an integer string may hold a list string.

However, notice that since there is only one data type (the string), all your variables are of type string, and that’s never gonna change. So, in that sense you could say that TCL is statically typed. However, it’s a useless categorization in my opinion.

To talk about typing, looking at the function types would be useful (maybe mandatory), but I won’t do that in here.

One of the things that you can do in TCL is use the value of a variable as a procedure to call. And any value can name a procedure: “procedure”, “function”, “abc”, “strip”, “10″, “12.31″, “do times”, “a+1-2″. You can then store the name of a procedure in a variable, and call it later. It’d just work, because to call a procedure, all you do is start a command with a string whose value names the procedure. If my variable v holds the value of “puts”, and “puts” names a procedure, calling the value of v is fine.

This implies that you can decide, very easily, in runtime, which procedure to call. This leads to a lot of dynamicity. For example, a simple Rock-Paper-Scissors game can be implemented by making three procedures: rock, paper, scissors, which takes a string, and put out the right output message based on the value of that string (e.g. if the rock procedure takes the scissors argument, then it’d print “win”). The game now is basically reading a word, then another, then calling the first on the second.

You can define 10 to name a procedure, and still use it as a number because the command to perform arithmetic doesn’t see a procedure or procedure name: it sees a string. You could then call 10, add 10, get the first element of the list 10, get the substring of 10 from the first up to the last, and so forth.

It’s not necessary to mention how fun it is to play around with languages like that. It looks like total disaster, but it doesn’t seem to lead to disastrous situations in practice; on the contrary. Only time will tell though.

TCL has a bunch of useful built ins. And it’d be interesting if I could show you some programs exemplifying that, but I will leave this to TK, which is what I come to now.

I got into TCL because of TK. I wanted to build GUI apps, and heard that TCL with TK formed an easy to use combination. Sounded good to me. After two days of studying TCL, I thought “this language is actually easy to learn and use, it seems, let me go to the TK side, and learn how to build GUI; if something appears that I have to go back, then I will”. So I started learning a little bit of TK.

I never built a GUI before, and I always thought it was a “hard” thing to do because I’ve looked at some GUI code in the past (from some examples written using C and xstep, and some examples from a QT book I started reading, using QT and C++).

It turns out that TK feels a lot declarative. I’d say more than HTML and CSS, because of the wider amount of options in TK. In HTML/CSS it happens a lot that you build a “widget” out other elements (menus out of lists, for example). This happens in TK too, of course, but you have a much broader range of widgets to start with. Also, laying out your widgets on the window is not like a “struggle with floats or positioning”, you actually can tell “sort of” where you want it to go, and it will go there (it’s actually hard to believe how simple it is).

It’s declarative because you don’t so much say what are the steps to build the GUI (although you can surely see it that way), but you say what you want to be true about your GUI with the provided commands. TK then will just take care from there.

This makes building GUI a lot nice.

So, it has been something like 4 or 5 days since I’ve started learning TCL/TK, and I wrote an app for me. A program which filters the contents of directory by a pattern I specify, and shows me the result in a listing. I used to do that using grep and ls, or find but opening the file later is not that “easy” that way (mostly because I usually don’t have a rule for selecting which file to open after filtering; mostly if I filter music or videos, and there is also the case when I filter, but am unsure on how many files the filter will give me back; opening is really easy if the filter gives only one file name back).

So, a 140 lines of TCL/TK code did the job, and it was much better than I expected; although it has its problems.

The code to build the GUI is less than 40 lines long. It’s a simple GUI, but it’s much smaller than what I expected.

Here is the code: http://pastie.org/pastes/4554713/text

Here is a photo of the program.

Dilter in the context menu, also openned on the side.

The program is intended to use as something you open by right clicking a directory in windows explorer (yes, I use windows), and using it from there. The program does the files filtering in real time (each keystroke will update the list, which is nice). It can be made to work on linux by changing one line, which is the one which opens the file for you when you double click its item.

Updates on RegEX Parser/Matcher

Tags

cpp, regex, scheme, update, upgrade

Some days ago I coded a regex matcher and parser in C++, SML and Scheme. And I posted the code here. The program simply parsed and matched a regex pattern with an input string. It didn’t do any sort of fancy compilation from regex to some automaton, but the algorithms were really simple and really cool.

The first versions lacked some operations: intersection, xor, complement, optional. Now, these operations were added to the C++ and Scheme version. I have nothing against the SML version. Back then I had just finished a SML book, so I was really wanting to code in SML. Not so much right now. Maybe later, I will write the upgraded SML version.

Here are the newer proto.cpp and proto.scm. Check out the older post to find out more about this whole thing.

• http://pastie.org/4645252 – proto.cpp (updated version — the old one had a bug in the xor for match() code, which was making it behave like a logical and).
• http://pastie.org/4459178 - proto.scm

The syntax is explained at the top of these files.

By the way, proto.h remains the same. You can get it from the old post.

DFA to C Compiler

Tags

automata, c, chicken, compiler, dfa, scheme

Just recently I thought I could use C very nicely to implement DFA. Using labels and goto statements do model states and arrows seemed really interesting. And I started writing some code to see how it’d go. Well, I liked it. Here is an example of it being done.

http://pastie.org/4445700

I didn’t run (I didn’t even compiled) this code (just wrote right now), but I am quite confident that it works and it does only accepts strings that are composed of 0 or more “110″. As labels model states, naming labels as you’d do with state is a good practice (to explicitly indicate the current state of computation). It turns out that this is very clear. At least to me (some people can’t like goto, no matter what).

However, there is a lot of code in there which have nothing to do with the DFA specification at all: the function definition, the labels, the switch statement, strings, pointer arithmetic, dereferencing, and so forth. Besides, the action of the switch statement on 0 is what determines if a state is final or not.

Which is all fine, except for the fact that it doesn’t quite map to the way I (and we?) think about this sort of stuff.

I’d much rather write this:

@start:
  1 => 1

1:
  1 => 11

11:
  0 => start

Which I think is much better (the ‘@’ before start indicates that start names an accept (final) state).

This is quite different from C, but the ideas map very easily. So I thought I’d make a compiler that take that sort of description and generates a function like that one.

It turns out this compiler is extremely easy to do. I’ve done it. It took me 400 lines of scheme code, and I may have over-complicated it (revisions would be really appreciated). Here is the C code it generates for the above DFA description:

http://pastie.org/4445758

It still doesn’t have a good UI (you have to hard-code the input file name in the source code, for example). Even though, it’s simple to use. It will spit out errors or the program, not both though. The “UI” is pretty much the last 10 lines of the program. So just go ahead and change it to do what you want it to do.

Here is the scheme source file.

http://pastie.org/4453770

This next link is an older version of the source, which I left here because it’s extremely different from the new (above) one.

http://pastie.org/4452949

It was made to run on chicken scheme (of course).

Here is a little explanation on this “DFA specification language”.

• The general format is <state name>, followed by “:”, then followed by transition rules, which are triples <input> “=>” <output>.
• <state name> maybe any valid C identifier, but they may start with numbers: a sequence of one or more of any of letter, digit or “_”.
• <input> is a special keyword (“newline”, “space”, “tab”, “any” or “else”) or a single character. “any” and “else” means the same thing. And the other special keywords are for matching the characters ‘\n’, ‘\t’ or ‘ ‘.
• If <input> is “any” or “else”, then it means that its output will be used in case  an input character doesn’t match any other input defined in the current state definition. “any” or “else” may repeat (the last one will be the effective one), or may not appear at all (which is the same as having written “else => reject”). “any” or “else” need not to come at the last transition rule (as you’ve probably already concluded).
• <output> is either a <state name> or a special keyword: “accept” or “reject”. If “accept” is found, it means the DFA will accept the input, regardless of what comes next. If “reject” is found, it means the DFA will reject the input, regardless of what comes next.
• An exception to the general format is the general format prepended by a “@”, which means that the state being defined is an accept one. Which means that if there is no more input and the machine is currently on this accept state, then it will accept the input; otherwise, it’ll reject the input.
• A state definition is either a general format or an exceptional general format (the above).
• A DFA is defined by defining a bunch of states.
• The start state is the first state.
• The alphabet is the set of values all char can hold. Notice that there isn’t syntax, though, for specifying all these values in this language.

As mentioned in the last point right above, this language doesn’t let you specify all the characters of the alphabet as inputs (there is no syntax for that). Basically, if you can put it into the file, then it’s going to be used (the algorithm simply takes the non-space-ish character that is supposed to be the input and put it between single quotes in the C output).

If the source program is valid, the output of the compiler will be the definition of a C function, which takes a string and validated it according to the DFA specification.

Here are some additional features of the compiler:

• The error messages seem quite nice (only time will tell though).
• It can spot unreachable and undefined (but used) states.

I haven’t tested it so much, but so far, it didn’t generate wrong C programs out of a considered valid DFA definition. I fear though that the “error catcher” is not so good.

It’s yet just a prototype. Also, I also made this purely out of “just wanna code this because it’s fun”. I guess this could be useful if you need validators, but using generic regex libraries would make your program too slow (which is not, as far as I know, the situation most people are in). It looks useful, but that’s not why I made it.

Future ideas are to make a finite state transducer. Also, a program which takes a list of words and make a DFA specification which matches one of the words in the list. A program which can generate combinations of DFA (through unions, intersections, complement, etc.).

Simple Regular Expressions Parser and Matcher

Tags

cpp, matt, matt might, programming, regex, regular expressions, scheme

Recently, I’ve found two blog posts on http://matt.might.net/ (Parsing regular expressions with recursive descent and A regular expression matcher in Scheme using derivatives), which talk about parsing and matching regular expressions. I found it very interesting (I didn’t know that matching regular expressions could be done so simply), and decided to implement the ideas in C++ and in Scheme (edit: now also in SML).

1. proto.scm – http://pastie.org/4248239 – the scheme implementation (use  through regex-march; check last line to see how it can be used).
2. proto.h – http://pastie.org/4245765 - header file for the C++ implementation and C++ programs that use the implementation (declares RegExParser and RegEx).
3. proto.cpp – http://pastie.org/4248245 – the C++ implementation.
4. proto.sml – http://pastie.org/pastes/4248242/text – the SML implementation.

The three implementations  are very primitive, and have many problems:

1. They do not support “full commonly desired regular expression features”, which means that lots of the things people are used to in regex tools are not available here.
2. For the available features, the syntax is a little different (the grammar is specified on the top of proto.scm).
3. The code is primitive, and it was built using simple abstractions that may not or may scale well, I can’t tell (I believe it’s scalable though).
4. I haven’t tested them extensively yet. It’s likely to have many other problems.
5. I am not a C++, SML or Scheme expert.

Feel free to try them out, and improve. The name “proto” of the files is to indicate prototype: these are not final, finished, ready-to-use implementations.

The resulting program is useful, and with little effort, range and complement of characters can be added. With these two additions, the implementation could be used in many practical applications. Anyway, even though the code is not usable, it’s very interesting because the techniques for matching and parsing are very simple and easy to understand.

“Problems”

Well, it turns out that I read the two articles slopily, which lead to confusion in writing the algorithms. Now, everything should be fine. The problems I was having are gone, hopefully. It, though, shows that reading is very important =).

Updates

Check out this update post about this code.

Torture for Computers (Better Than Hitting the Keyboard)

#include <stdio.h>
#include <stdlib.h>

int main()
{
  for(;;) putchar(rand()%23+'a');
  return 0;
}

Arrays and Pointers, C

Tags

arrays, c, pointers

I’ve been programming in C for some years now. Mostly doing stuff just because I think is fun, but also doing “serious” code from time to time. And only now (today) that I came to understand what arrays are (I hope), and the differences between an arrays and a pointers.

There has always been a confusion inside the head of many programmers as to what C arrays are, and many of them just say “array are actually pointers”. I used to do a little different and say  “arrays are actually constant pointers which can be used a little differently (in initialization for example)”. It turns out that I was wrong, and whoever tells that an array is actually a pointer is also wrong.

I am going to argue here that saying “arrays are actually pointers” makes as much sense as saying that “doubles are actually pointers” or any other non-pointer type for what matters.

Before going on, it’s useful to remember what arrays are for. Arrays are collections of values (they’re also continuous in memory, and some other things). They are to give you a vector-like structure, in which you have a sequence of items of same type that are indexed numerically. Sure in some occasions, you may want to use arrays for different purposes. But let’s keep this higher level idea in mind.

Arrays are continuous blocks of memory, containing elements of same size. The size of an array is the size of an element times the number of elements in the array. Given that it’s continuous, and since it’s in memory, then if you have the address of its first element and the index of an item in the array, then you can, with a constant number of operations, which is another characteristic of a vector-like data structure, access the element of this array that has that index (read this paragraph again).

Now, let doublevar be the name of a variable of type double, intvar the name of a variable of type int and arrvar the name of a variable of type array of N int. When you type, in your source code, doublevar, what do you think is a good value for it to result in? A good one would be the actual double value stored in that variable. Analogously for intvar, right? Correct. But what about when you type arrvar in your source code? Well, having that expression resulting in the “actual value of this vector-like structure” doesn’t make much sense. It does, depending on how you look at it, but asking for the value of a vector-like structure, as a whole, isn’t much useful because what you often wanna do with the individual elements.

And here is where most confusion about arrays and pointers come to place.

When you type arrvar, one of the convenient things to have it return is a pointer to its first element, because then, you can access any of its element by having only its index. And more! You can have that behavior without actually copying the array or depending on its size (you can also, since all you have is a pointer, re-interpret that array to be of other array type [e.g. instead of being array of N int, being an array of N*sizeof(int) char] given that you are consistent with the sizes). So it’s a very flexible thing to return. Since arrays are continuous, then if you know the pointer to its first element (i.e. its beginning), and the index of the element that you want, and the type of the elements in the array, then simple pointer arithmetic on that given pointer is enough to get the element at that index. This is why an expression naming an array returns a pointer to the first element of that array: it’s convenient. That could have been the behavior for integers (i.e. when your typed intvar, it returned the address of intvar, and not the actual intvar). It isn’t just because it is not convenient.

So, the value of an array is a pointer to its first element, but that’s not the value the array variable holds. The array variable holds the array (bunch of objects, sequentially arranged in memory, etc.), but when an array is requested for its value, a pointer to its first element is calculated, and it’s what is given back.

But here is the actual killing part. If arrays were actually pointers, you would actually have an address stored somewhere (because that is what pointers are to keep: addresses), and that address would refer to the first element of the array. Then typing arrvar in your program would just return the value of that address stored somewhere. The mistake here is “stored address”. There is no stored address with arrays, but if an array were actually a pointer to its first element, then there is a stored pointer implied, and there isn’t.

And that is why saying “arrays are actually pointers” makes as much sense as saying “doubles are actually just pointers”. The address of a double, or of an array, is not stored anywhere. Conveniently generated assembly code “knows”, without storing any address in memory, where the memory block corresponding to an automatic array (as well as to an auto double or int) is.

Here is the interesting thing. The array type, in C, is not a first class data type. Among other things, this implies that, first, you cannot pass arrays as arguments to functions; second, you cannot return an array from a function; third, you cannot use an array as a rvalue (in the sense that you have no choice but to use a pointer to its first element in the context of an rvalue); fourth, you cannot assign to the array, but you can assign to its elements.

As a final note, although arrval evaluates to an int*, &arrval is not a int**, but an int(*)[N]. The address of operator doesn’t ask for the value of the object it operates on, thus the value of the array is never requested in that operation.

By the way, this is a good place to point out that some THING has many aspects. For example, it has its meaning, its value, its type, its syntax, the type of its value etc. The arrvar case is a very good case showing that what arrvar is (an array of N integers) is different from what its value is (a pointer to integer), and its type is different from the type of its value. Doing sizeof(arrvar) (yes, I like putting paranthesis around sizeof arguments) is likely to reflect the fact that the type of arrvar is different from the type of the value of arrvar.

I guess much of the confusion regarding C arrays come from the fact that in many cases, they behave like “the elephant”: you can only look at parts of it, but not it as a whole. In the elephant story, the reason was because the elephant was too big. In C, the reason is because the standard says so.

Google “C For Smarties”, which is a series of articles by Chris Torek, which covers much more than what I said here; and also about other C topics too. He is much more precise, and I belive his texts are simpler. Those articles are freely available on his website.