SDL, now what?

Ok, so I want to go from quick and dirty tech demo I copy/pasted from a website to something I understand. The website I got it from has several tutorials that actually spell out the data types pertinent to manipulating pixels. That's cool, but I wonder if SDL has primitives (boxes, circles, triangles, etc) so that not everything is so manual. Actually it would be slick to make my own functions for primitives.

Here are the next steps as I see them.
1) Get a screen up (640 x 480) that is a solid color.
2) Get a screen up that alternates from red to blue to green and back (every X milliseconds or by keypress or something).
3) Figure out how coordinates work and make half the screen red and half the screen green.
4) Make a tiled pattern (this is working towards the Wumpus graphics output) and figure out how to address the screen on a tile by tile basis - like tell it that tile x:3 y:5 should be blue - the function should figure out which pixels that tile is and just change that one tile.
5) By this point it should be a matter of taking the code that can address a grid of tiles and then be able to define what those tiles are (a solid color or picture) and call it the game board.

cast and shift

I have a minority of users I support that are the programmers/techs in the lab. They're the genesis of the various programming-related support I do that has increasingly been things I can handle myself and not have to automatically pitch to a programmer here.


The data acquisition system has a clock that only resets when you cycle the power. I don't remember how many bits the clock is (EDIT: 40 bits) but it will roll over after about a month of being on (and deity help you if that happens during a recording). Anyways, the actual time recorded in the file isn't this clock value because a "start" time is noted and considered to be 0 and all subsequent acquisitions are subtracted against the start value to get the correct relative time. The SDK that can access data on the fly doesn't have access to that information and so it returns the actual value of the timer. Someone wrote in wanting to know if the non-adjusted times were kept in the file, so I modified my file reader to pitch the clock values of the data at me. It was tricky and here's why.

The file format keeps the time of each data block in two variables representing the upper 8 bits and one more variable representing the lower 32 bits (5 bytes total). This was apparently to save space and not use two 32 bit variables. The high byte is stored in an unsigned short, and the other 4 bytes is in an unsigned int. To get this into one variable the following is done:

long int timestamp = ((long int)datablock.upperbyte << 32) + (long int)datablock.lower4bytes;

I take my one byte and cast it to a bigger variable that can hold 5 bytes and then shift that byte to the left 32 bits (4 bytes). Then I add to that my lower 4 bytes. The 5 bytes are recombined.

It's a minor annoyance but it's the first time I did any shifting and I figured I should make a note of it.

I think we have a winner

http://www.friedspace.com/cprogramming/sdlbasic.php


The C code linked on that page makes a whole mess of pretty colors. Straight SDL, no OpenGL. I think I can get a good handle on this and make it work for my nefarious purposes.

SDL

I got SDL installed and it seems to play nice with XCode. The basic "pop up a window/Hello world" program it defaults to works but a few warnings about things not in my user directory pop up. I didn't spend a lot of time messing with it. I'm still not comfortable with XCode when doing non-strictly-C stuff. The basic SDL project has a handful of framework files and some Cocoa/ObjC stuff that has to be there (described as "glue code") which somewhat irks me because I hate not knowing what things are doing. GTK was pretty straightforward compared to this.

Next I guess I'll try to find a good tutorial source.

misc

I used a bit of C programming a work yesterday. There is a C/C++ SDK for accessing the data coming into the system on the fly and someone was saying one of the functions for returning the currently selected (in the UI) channel wasn't working. I was able to make a very small (~12 line) program to test that function myself. Turns out it doesn't work in some situations, but it's a known limitation that doesn't have a workaround. I wouldn't have been able to do that even a few months ago - not because it was difficult code (it's just a few lines and a function that returns an int) but because it requires linking to a library which up until recently I wasn't sure how to do. I'm still a bit shaky and I let the IDE do the hard part, but it's still more advanced than what I could do before.

QSort followup

Props to Matt for pointing out that stringarray[i] is the same as saying *(stringarray+i).

There is another point I needed to make about some confusion I was having, but I figured it out and now I don't remember why I was confused.

another project idea

I have more ideas than time/energy to do them.

It would be cool to make a "Life" clone. I've somewhat worked out in my head how to do it, but the edge cases (literally, the cases of the cells around the edges) don't work in my head as I'd want them to. I'll draw it out sometime this week.

I've come up with a roadmap of sorts to Wumpus but it seems useless to write it out without even picking a graphics library to work with. I'm very tempted to just use OpenGL since there is a mountain of tutorials. SDL is a close second but it seems that OpenGL+SDL is a very common cross-platform method with SDL handling input/timing/audio and OpenGL handling video.

You know what? How about this. Put Wumpus away for a few weeks and just see if I can install and compile a few OpenGL versions of "hello world" and see how I feel about it.