QSort part 3

Ok so I'll take this line by line.


char *sources[] = {"this", "is", "a", "program", "for", "testing"};


The first line about defining and initializing the variables "sources". "sources" is a pointer to an array of characters. I think that's the best way to say it. It's not a pointer to a character array, it's a pointer to an array of pointers that hold the location of character arrays. The syntax of initializing the variable with the {} is something K&R pointed out. I'm not sure if there is another way of doing it - there likely isn't a way to do it on the fly without some malloc action.

Anyways, this establishes the data we're working with.

It's important to note here that the value of "sources" itself is the address of where the character arrays start in memory, and saying something like "sources[3]" is the address of where the characters that make of "program" start. I think.



The function "printarray()" takes in two arguments: the address of the array of strings and how many elements are in the string. Since the address of the array is an address of something that holds an address I have to declare it to be a pointer to a pointer "char **stringarray". That's one of the toughest parts of C. You have to know exactly what you're giving a function and tell it exactly what to expect. I'm still working in my head about why I don't have to dereference the array variable in the printf() function. It works but I don't know why and that's breaking the rules a bit.



This is probably my favorite function ever because I get to cast and dereference all at once. The qsort() function prototype has an argument that's a pointer to a function that takes void pointers, so here is my function that takes void pointers where I cast them to what they really are - pointers to pointers - and then dereference them to pass them to strcmp(). This is why I'm kind of thrown by why I have to dereference the local variable that holds the address here but not in my function that prints out the strings.

So, the rest is in the secret sauce that qsort() uses. The prototype for qsort() is:

void qsort(void *base, size_t nel, size_t width, int (*compar)(const void *, const void *));

*base is the address of my array of data so I just pass it "sources". size_t nel is the number of elements in the array (which is hard coded to six - I could make this more flexible). size_t width the size of the elements and I'm just passing it "sizeof(char *)" since remember the array is REALLY an array of pointers to characters, and the characters actually AT the location of where the array elements point to is what we're really sorting. I'm not sure if that was a complete sentence. The last argument takes a pointer to a function that takes two void pointers as arguments. I call qsort() as follows:

qsort(sources, 6, sizeof(char *), compare);

And it works fine. The only mystery (which I might be able to hash out if I draw it out) is why my function for printing out the words works. I suspect it has to do with what I call "array synonyms". Like how "sources" is the same as saying "&sources[0]". I'm passing the function an address to an variable that holds the address of the start of an array of addresses.... why does printf() behave? Needs testing.

Qsort Part 2

This took me about an hour to bang out - and that's WITH heavily referencing some similar programs I found in various tutorials (that were varying degrees of helpful).

Making QSort properly sort an array of strings requires a wide range of familiarity of C's tools (pointer voodoo, how strings and arrays behave, function pointers, casting) but to a greater degree it requires understanding what you're really saying when you tell a function what to expect.

I don't have time to go into it but I have a few pages of notes I'll transcribe tomorrow. This was a fantastic exercise.

QSort

Instead of tackling a new project I decided to go back to the K&R book and see if any of the stuff that was once over my head makes sense.

QSort scared me when it came up in the book. I took a stab at writing a program that used QSort to sort a string alphabetically and after some heavy pondering over my code vs code in a tutorial I finally figured it out. I'll try to make a writeup this evening.

Spoiler alert: there is a line where I cast a void pointer to a const char pointer to a pointer and then dereference it all in the same statement.

momentum

I've lost a lot of momentum because of how discouraged I got with the monotony of the GTK book chapter I'm on and to a lesser extent the trouble it is to do GTK programming right now.

As things stand I have to either be at my Windows box OR run Ubuntu in VirtualBox on the laptop. OSX doesn't have a decent or complete GTK port.

Do I abandon GTK after getting this far? No. I have some ideas for simple programs I can use at work to help me automate testing.

Do I look for a new library or framework to learn? That's the question. I fell flat on my face trying to find a 2d graphics library to hack out a 2d tile engine for the Wumpus game. I somewhat grudgingly decided to use Cairo when the time came but I swear that nobody uses Cairo and there is very little web traffic of Cairo users.

What about more hardcore CS stuff? Maybe. I'd have to find a really good resource.

What about OOP? I should get familiar with that at some point although it would just put me right back at the spot I am now at some point.

SDL? OpenGL? Processing.org?

The progress I've made the past year was driven by the file reading program and it got me really far. Now that I've accomplished what I set out to do it's critical I find another big seemingly impossible task to tackle.

mister jones

I didn't get much programming done over the weekend, but I did learn how to properly play an F chord. It sort of happened on accident after I started practicing playing the C chord with a different (likely proper) fingering. It's easy now to transition from C to F.

Inspiration

I think I've said this before, but my metric of a good game is if it inspires me to create. Doom inspired me to make maps. Quake had some of the first really user friendly mod tools. Neverwinter Nights had its own very intricate mod tools for creating quests and dialog and all that.

I'm several hours into Portal 2 and I keep getting completely blown away by the gameplay and writing. I play through Portal probably once every two months. I'm not sure I'll do the same for Portal 2 since it's longer and more story oriented (lots of dialog to wait through). I wonder if there will be SDK tools for Portal 2?

More ideas

I guess if I'm not programming tonight I might as well write out some ideas.

It's my opinion that a keen sense of observation has taken a back seat to running, jumping, shooting, and commanding Zerglings in today's games. Crysis introduced near photo-realistic graphics nearly four years ago and engines have only advanced since then. It's only served to give us prettier jungle scenes to shoot AK-47s in.

Give me a game of exploration and uncovering of secrets with the realism of the modern engine. Replace the generic "make a lever" Havok engine puzzle with something deeper.

I dunno. Morrowind, Oblivion, and the Fallout series accomplish this to some degree. Part of the game is just exploring the landscape. I like that.

fingers hurt

I didn't do any programming today, but I did finally learn the change-up and bridge to Ants Marching on guitar.

thinking more

Ok, I thought about it more.

g_signal_connect_swapped(instance, detailed_signal, c_handler, data)
The instance on which the signal is emitted and data will be swapped when calling the handler.

g_signal_connect_swapped (G_OBJECT (button), "clicked", G_CALLBACK (gtk_widget_destroy), (gpointer) button);

In the case of a button, G_OBJECT(button) is the instance, and the data is the (gpointer)button.

So this is... swapped when calling the handler?

The handler prototype is:

void gtk_widget_destroy (GtkWidget *widget);

So... typically (I think) the first argument passed to the callback function would be the instance, and what this is saying is that instead of the instance the data is passed which conveniently sort of matches what the function wants (a pointer).

EDIT: ok if you just use the normal g_signal_connect the function prototype for handling "clicked" is:

void user_function (GtkButton *button, gpointer user_data)

so I think that g_signal_connect_swapped is just a way to get around the function prototype for "clicked" and pass things the way you want them passed to a function. You can just as easily do a normal g_signal_connect with a user_function called and THEN call gtk_widget_destroy.

signal confusion

Signals and events in GDK/GTK/X are one of those things that you can have a superficial knowledge about and get away with it. It's also one of those things you could spent weeks (months, even) getting really well versed with. I don't mean the specific signals emitted for all the objects (buttons, windows, other widgets), I mean the order in which they come and how they flow through the system and the handlers.

Like I said, you can get away with a superficial knowledge. You press a button and it emits a pressed signal and you have a function that's looking out for this and had been connected in the code with the g_signal_connect function. Easy enough - from the API here:

g_signal_connect(instance, detailed_signal, c_handler, data)

The handler will be called before the default handler of the signal.

instance :the instance to connect to.
detailed_signal :a string of the form "signal-name::detail".
c_handler :the GCallback to connect.
data :data to pass to c_handler calls.
Returns :the handler id

So.... let's say I have a pointer to a button called "button", a signal called "clicked", a function called "do_something", and for now we don't have any extra data so we'll pass NULL at the end.

g_signal_connect(G_OBJECT (button), "clicked", G_CALLBACK (do_something), NULL);

GTK is cast heavy and it's NOT always obvious when I need to cast to G_OBJECT or G_CALLBACK and I think once I left them out and it still compiled and ran. Hmm..

Ok so the point of this is that there is an often used (in this book) different method of connecting a signal to a function. From the API again:

g_signal_connect_swapped(instance, detailed_signal, c_handler, data)
The instance on which the signal is emitted and data will be swapped when calling the handler.

instance :the instance to connect to.
detailed_signal :a string of the form "signal-name::detail".
c_handler :the GCallback to connect.
data :data to pass to c_handler calls.
Returns :the handler id

Here is the connect swapped in action:

g_signal_connect_swapped (G_OBJECT (button), "clicked", G_CALLBACK (gtk_widget_destroy), (gpointer) button);

So it LOOKS like I'm skipping the need to have a function that destroys the widget by passing the widget a signal directly? gtk_widget_destroy is a function.

It says "the instance on which the signal is emitted and data will be swapped when calling the handler". I'm having a tough time parsing that sentence. What is the instance? The thing emitting the signal? If so then why does it say "on which" instead of "from which", or is this one of those times I need to know the signals system better because maybe signals are emitted on things instead of from thing?

Woof. For real.

Well, the point is that I don't understand why it works but it's a decent enough shortcut for now to avoid needing a new function.

Maybe the swapping passes (gpointer)button to gtk_widget_destroy()?

the grind

It's getting really hard to find time to sit and DO something.

I'm getting up in the mornings at around 6am and Ana is out the door at 7. Between 7 am 8 I should be programming but it's lazytime usually.

This looks interesting: http://processingjs.org/

little progress

This weekend has mostly been wedding planning and taking care of chores. Bleh.

Maybe

Cairo, maybe.

http://cairographics.org/samples/image/

So I have this map data and player/NPC/mob data. I pass this to my drawing function that uses Cairo.

In my drawing function I have a pre-defined tile set. Probably in .png with alpha channels (so that my player/mobs can be put anywhere). The drawing function sets up a space of map_height * map_width and then scans through the map data going from top left to bottom right. Each tile gets scaled and translated to the appropriate spot and then the display is revealed.

Hm. I might be able to bang out a quick proof of concept.

EDIT: The patterns stuff here: http://zetcode.com/tutorials/cairographicstutorial/shapesfills/

looks interesting..

quick UI sketch

http://i.imgur.com/8qk5x.jpg


Once I learn more about horizontal/vertical dividing and tables in GTK this should be a piece of cake. The only complete mystery is the 2d grid on the top half.

Maybe I can figure out a way to render the game to a .png and make that top half a PNG rendering view?

buttons

http://i.imgur.com/EINiN.png

I've done this exercise before, but I need to rehash old topics to get back in the swing of things. I convinced myself (and more or less verified in the documentation) that the container I'm packing the buttons into keeps track of them (the pointer to the button widgets) such that they can be individually "closed" when you click them and the callback function knows which button to remove from the view.

I never really had a firm grasp on g_signal_connect_swapped but it's a good shortcut to sending kill signals to widgets so I roll with it. The API and internet in general isn't any help here, but I never NEED to use it and I haven't run across anyone else's code that has much of it.

Up next in the book is some detail about the order the buttons are packed in (top to bottom, bottom to top, there are functions for both) and some info on resizing the main window and the consequences of the child widgets. THEN it starts into vertical and horizontal dividers and tables. This is especially important since the way I want to lay out the Wumpus UI will require both.

Wumpus planning 4

I got some good advice on how to divvy up the program responsibilities.

Let's say I started with the map data structure. Would I define it in a header file, or in a separate .c file? I rather imagine I'd put it in a header file. I don't have a particular preference, really.

I got some decent practice dealing with keeping functions in different .c files (really the trick is in the main .c file including the function prototype) and being able to see variables (extern) from .c file to .c file. I don't have all the trickier cases hashed out but I haven't had any real problems yet.

I'll try to stick to the Model/View/Controller paradigm that Matt tuned me into. I wonder how that would have helped me with the .plx reader? It certainly would have helped to keep the file reading functions away from the display functions. In fact the reader could have just done the right thing and dumped the data to allocated memory for whatever visualization function to deal with later.

I think this is a good plan, but the specifics of what goes where need to be nailed down. The map itself (static, non-moving parts anyways) will go in one function, and the player, bat, and Wumpus can go in another structure. A few posts ago I had them all in the same structure, but the map structure is going to get a bit more involved because I want it to contain pointers to the rooms it connects to (instead of assuming linearity). Saying "check if the room the player form this struct is has a swamp against the room in this struct" should be easy enough. I dunno - might think on that a bit more.

In the meantime I for real need to get banging on GTK a bit more so that I can get a UI going.

Wumpus planning 3

Ok, so I have a map structure.

The program would flow like this (very high level):

1) Initialize map data
2) Draw map
3) Give player feedback (unless 100% done graphically)
4) Wait for input (up/down/left/right/fire arrow/quit/restart)
5) Update map data structures (set player location flags, etc)
6) Re-run the Draw Map function

So, the data in the array drives what's drawn. It's easy for my naiveté to get in the way and want to drive it with the graphics itself (check for pixel colors or something) because that's what I used to do as a kid. Live in data-space so that the drawing method can be as agnostic as possible.

I would love to do this with GTK to handle the keyboard events and some kind of graphics element. Imagine a square grid of tiles and then below that a text box that updates the player on what's happening or gives instructions on what to do. If I wanted to get some widget practice I could even add in arrow buttons to drive the movement.

Wumpus planning 2

It's easy to represent a grid with a 2d array. You can even use a 1d array as long as you know when the next row is supposed to be (assuming an 8x8 grid array[63], elements 0-7 are row 1, 8-15 row 2, etc).

I've been trying to think of how to dynamically generate the grids. The first iteration is going to be hard coded most likely.

Mleh. Some of my most productive coding has been in the early morning (around 5-8am) oddly enough. Ana is on spring break so I haven't been awake at that time in almost two weeks. Coding in the evenings is almost impossible right now because I'm too tired from work or I've taken work home with me.

The first thing I'm going to do is come up with a level storage concept. Lets keep with the 8x8 level size. Each of the 64 elements needs to have the following defined:

1) Does it have pit or Wumpus clues in it?
2) Does it have a Wumpus, pit, or bat?
3) Does the player start here?

This could be solved with a 64 element array of structs.

struct room {
int Wumpus;
int Bat;
int Pit;
int Moss; // the pit clue
int Blood; // the Wumpus clue
int Player; //tells the future graphics device to render the player here
}

The level setup would init all of those to 0 (for false) and then make another pass that places the Wumpus, bat, and pit (and the clues, too) and then puts the player start somewhere far enough away from each (or not).

If I was feeling sassy I'd make it even more complicated by adding variables to define which rooms each room connects to - that way I could have rooms with tunnels. For example - lets say I'm in a room with exits to the North, South, East, and West. In the Wumpus game I played it was common to have one exit connect to another, like the North exit would loop around to the East such that going North or East would put you right back in the same spot.

Here's a screenshot of that: http://www.giantbomb.com/hunt-the-wumpus/61-13729/

But for now I'm not feeling sassy. I'm feeling depressed because I don't have time to code and I can't find a sensible 2d graphics option.

The horrible irony is that we never had problems with graphics back in the QBasic/Pascal days! We were rendering sprites defined by text files back then!

My kingdom for a 486 with a VGA card.

Wumpus planning

Since I'm struggling with the graphics element I've decided to work on the game logic part. I also spent the afternoon reviewing some old GTK stuff just to make sure I could pick it up again where I left off.

The game is played on a square grid. The player, the Wumpus, a pit, and a bat live on the grid. The player moves about the grid one space at a time. If he inhabits the same space as the Wumpus he gets eaten. If the player inhabits the same space as the bat he will be transported (by the bat) to a random space. If the player inhabits the same space as a pit he will die.

The Wumpus and the Pit leave clues. Spaces around the pit are "swampy" or colored green. Spaces around the Wumpus are "bloody" or colored red. The caveat (and this varies from implementation to implementation) is that not ALL the spaces surrounding the Wumpus/pit are specially colored.

To win the game you must kill the Wumpus with an arrow. Once you determine (via the clues) where the Wumpus is, you fire an arrow in the direction (up/down/left/right) that the Wumpus is relative to you. In the game I played I think that if you missed the Wumpus would move but the old clues would remain (and new clues would be added, making it more complex). Some games I think missing means the Wumpus knows where you are and eats you.

tag

I wish I could tag my posts. I can't find a post I made about GTK callback function prototypes that I need to check to make sure I'm not doing something dumb here.

2d

Man, I'm having a tough time convincing myself that Cairo is the way to go. There is a lower level "pixbuf" way of doing things in GTK, and Cairo seems to primarily do vector graphics (lines, curves, etc). I think it has some ability to load images but it doesn't seem to be what it's FOR.

Mleh.