PDA

View Full Version : Programming is fun




Hans Kamp
Apr 2, 2013, 07:39 AM
A few days ago I decided to test my graphical and mathematical skills and decided to make an analogue clock (later on a digital clock).

A friend of mine is a professional programmer and was eager to see me and together we decided to spice up my analogue clock.

It is quite tricky but exactly because of that also challenging. The longer I work on that clock, the more features I want to add to it.

First I got the system date. I broke it up in hours, minutes and seconds. The position (angle) of the hands has to be calculated. The angle of the hour hand depends on the current hour, but also on the minutes that passed since the whole hour. If you want to display 1:30 the hour hand must be exactly between one and two, and not yet pointing to one. The minute hand must be exactly halfway of the clock. But I also decided to make the angle of the minute hand depend on the last whole minute and how many seconds that are passed.

To make the hand of the same length, you must also calculate the sine and the cosine of the angle.

This topic is not to discuss a problem, but to express the fun I have with graphical programing and the mathematical knowledge that I have to use it.

Who of you have done similar to the above?

The next challenge is to make a normal calculator, maybe followed by a scientific calculater or an easy game like Minesweeper or Solitaire game (a card game).



robvas
Apr 2, 2013, 09:10 AM
One of the first programs I wrote that was somewhat complicated was a Doom level viewer - after reading the unofficial Doom specs (http://ruinworld.sourceforge.net/notes/dmsp1666.html) it was pretty simple to get all the linedefs that make up the walls for a level. I drew them on the screen in 640x480 VGA mode, and it blew my mind seeing the map on the screen - since I of course recognized it from playing the game so much.

It was just simple overhead 2D view, I later made another program that got all the texture data out, but at the time I would have had no idea how to draw the level in 3D with textures.

I later tried the same thing with Quake but didn't get anywhere, but I was able to almost get the models (enemies etc) to draw right. It's pretty exciting getting something on the screen, especially when it's something that's 'magic' like a video game.

notjustjay
Apr 2, 2013, 10:25 AM
You know that old phrase -- "any sufficiently advanced technology is indistinguishable from magic".

I think that saying applies to the wielder of the technology too -- it makes you look like quite the magician!

Sometimes what can look really amazing is actually pretty simple once broken down into its constituent steps. This doesn't take away anything from the effort required to make it work, but it is one of the skills of a programmer to determine what smaller steps make up the whole of what you are trying to achieve.

I remember being in grade 9 and seeing a program written by a grade 12 student that would display a "window" into a 3-D starfield and let you rotate your point of view, zoom in, zoom out, etc. (This was in the early 90's, when 3D gaming was just starting to arrive, e.g. Doom). I was awed by this amazing program! It wasn't until a few years later when I actually took some trigonometry courses, that I realized how relatively straightforward it would be to write a program to do the calculations and project/plot the point.

Programming is not only fun, it amazes people who don't program when they see what you can do :D

ArtOfWarfare
Apr 2, 2013, 11:59 AM
I wrote a pong game that lets you spin the paddle around + it plays MIDI notes and recolors the colliding objects every time the ball collides with anything. That was fun.

Someday here I should take a game all the way through to competition and actually release it rather than just play around with the different APIs...

whooleytoo
Apr 2, 2013, 12:31 PM
Once for a Computer Graphics assignment, we were given the option of writing anything we liked that showed an understanding of graphical transforms (moving, scaling, rotating). It was the most popular project we ever did. Some people did simulations of cars driving around a race-course, others had speedboats pulling a skier across the water. I made a mini game where you could grab stars out of the sky as they swooped about.

The lecturer was freaking out, as we were ignoring far more important projects just because this one was so much fun. Usually we had so much work we just devoted enough time to get a pass and moved on to the next assignment in the queue.

I guess the thing about graphical programming is it gives (fairly) immediate and obvious feedback with relatively little work.

larswik
Apr 2, 2013, 03:43 PM
Console based blackjack game a few years ago now. One thing I would suggest, which has been hard for me is to first spend most of your time figuring out what you want to build before you write any code. You mentioned as you got started you discovered more features you want to add to it. If you have a clear vision of what you want to do before you start coding can be easier.

But, I know what it is like. You get an idea and you just start coding and then it evolves. There are some programs I had to write 2 times! once because I added toms of features as I went along and added tons more code then I needed. So I went back and rewrote it so it is more efficient.

But it is fun to program. I really regret now into my 40's that I did not pick computer science as a major when I start college in 1990. Imagine where I would be today.

Hans Kamp
Apr 2, 2013, 03:46 PM
I expanded my clock with an analogue 24 hours system. The second and the minute hand have the same position as a normal 12 hours clock. The hour hand will go twice as slow. This means that:
- on a normal analogue clock you see the same at 10:40 (10:40am) in the morning as at 22:40 (10:40pm) in the evening;
- on an analogue 24 hours clock you see a different picture at 10:40 than at 22:40.

You can switch:
- Cmd-1 for a 12 hour analogue clock;
- Cmd-2 for a 24 hour analogue clock;
- Cmd-D for a digital clock.

Such a 24 hour clock looks like:

http://www.universal-radio.com/catalog/clocks/3110.jpg

ArtOfWarfare
Apr 2, 2013, 10:28 PM
Console based blackjack game a few years ago now. One thing I would suggest, which has been hard for me is to first spend most of your time figuring out what you want to build before you write any code. You mentioned as you got started you discovered more features you want to add to it. If you have a clear vision of what you want to do before you start coding can be easier.

But, I know what it is like. You get an idea and you just start coding and then it evolves. There are some programs I had to write 2 times! once because I added toms of features as I went along and added tons more code then I needed. So I went back and rewrote it so it is more efficient.

This is an issue with your code design. If you're dividing up your code properly, adding new features that you hadn't planned on from the start shouldn't be very difficult.

larswik
Apr 3, 2013, 01:05 AM
This is an issue with your code design. If you're dividing up your code properly, adding new features that you hadn't planned on from the start shouldn't be very difficult.

Any project should be planned out first then coding is simpler. But I understand wanting to dig into a new project and how much fun that is as I do it all the time.

As I am learning still I always find new ways of doing things that need less code and is more efficient. For a while I converted NSNumbers or NSStrings to int's to perform math functions. Then I found a method that allowed me to pass in a string to do the same thing. So I went back and rewrote the code.

This happens all the time as I learn more and more. You use the tools you know at the time and as you discover new tools your skills expand and you discover new ways of approaching new problems, and rewriting old code in more efficient ways. Or so I have discovered and I grow.

Hans Kamp
Apr 3, 2013, 01:49 AM
I have the same experience, Larswik.

Especially when I want to add new features to my clock, I find out that I have done things in a clumsy, inefficient way and there are more lines of code than actually needed.

Sometimes I see the same code several times. Then I think: "This should be done more efficiently." I recode it. Of course I also retest it, because of a chance of regression bugs (by recoding, things that worked before may stop working suddenly).

Sometimes things work, yes, but it could be visually more appealing. Then I try to chance that. My clock just consisted of lines (12 for marking the numbers 1 to 12) and three more lines denoting the hour, the minute, and the second hand. The friend, a professional programmer, browsed through the Xcode IDE (he is new to it, and I try to tell him the basics) and the NSGradient object makes it visually more appealing. The background of the clock and the markings 1 to 12 have some gradient effects and the second hand also has a gradient.

The digits of the digital mode consist of 7 segments. These are just light green lines when lit, and very dark green (close to black) when unlit on a black baground. But a segment is actually not a line (unless on old LED calculators of Texas Instruments) but it is a polygon actually, consisting of 5 or 6 points. I may work on it.

I can also choose to make the digital display differently like on modern digital watches. That is a gray display and very dark gray (close to black) segments. Then you have the feel of looking at a LCD display of a watch.

http://www.promotionalpromo.com/Upfiles/Prod_r/SLAZENGER_BIG_DISPLAY_LCD_WATCH_20097071836.jpg

larswik
Apr 4, 2013, 03:29 PM
Yep, I discovered the same things as I was learning. It is a disadvantage learning from books and help with the forums. I learned C from a book and then decided to take a programming class at my local city college. That really opened up my eyes because I learned to communicate with other programmers and the things I struggled with in the book and skipped over like Data Structures at that time I had to learn. It helped to understand the lingo better so I could describe my problems correctly.

As for your redundant code I did the same thing. So I create a Class for things I used often and called it my BoilerPlateCode Class.

The one useful thing that I picked up from a book I read about cleaning up your code is to keep your methods or functions simple. If you have one big method that fetches data from a folder, then it creates buttons, then it saves things back to a folder and so on it's to complex. Break all those things in to smaller manageable tasks. That one large method could be 3 or 4 smaller methods that performs simple tasks. It's easier to read and work with, not to mention trouble shooting.

ArtOfWarfare
Apr 4, 2013, 04:20 PM
The one useful thing that I picked up from a book I read about cleaning up your code is to keep your methods or functions simple. If you have one big method that fetches data from a folder, then it creates buttons, then it saves things back to a folder and so on it's to complex. Break all those things in to smaller manageable tasks. That one large method could be 3 or 4 smaller methods that performs simple tasks. It's easier to read and work with, not to mention trouble shooting.

And then after you've made those smaller functions, write some function tests for them so the moment they break you know and you can fix them.

Sydde
Apr 6, 2013, 12:02 PM
My first analog clock was written as a desk accessory for Mac OS 6, because I prefer analog and there was no such clock. I created a WDEF for it so that it could have a unique window style (octagonal) and used a quarter-circle table of sine values to minimize processing overhead (this was on a Mac Plus).

I was kind of poor/miserly at the time, I had no dev tools, so it was written in machine language. Pretty satisfying to get a decent looking 4E75 for my efforts.

Hans Kamp
Apr 6, 2013, 01:50 PM
I think that would be very hard, to write a clock program in machine or assembly language. Especially calculating the sine and cosime for the angles and the algorithm to draw a line from one point to the other.

I have added some stuff to the clock: I went pretty far with it. The features of my clock are now:
- analogue 12 hours clock;
- digital clock;
- analogue 24 hours clock;
- analogue 10 hours clock as intended at the eind of the 18th century in France (dividing 1 hour in 100 minutes and 1 minutes in 100 seconds);
- anticlockwise clock.

The clock is visually appealing now, but the digital feature needs more love, that is: has to be beautified. You just see bright and dark green lines making digits (like a 7 segments display would) but it should look more like the digits in a digital watch.

To say something about the programming languages I learned: I started with BASIC on the Philips P2000 and on the Commodore 64. Later on Turbo C and Turbo Pascal on MS-DOS machines later on for Windows 3.0, 3.1 and OS/2 Warp. I tried to learn COMAL, COBAL, APL, assembly language for the 6502 and the 6809 microprocessor and the MC680000 and new processors in the MC68000 series.