Register FAQ / Rules Forum Spy Search Today's Posts Mark Forums Read
 MacRumors Forums Programming is fun

 Apr 2, 2013, 08:39 AM #1 Hans Kamp macrumors member   Join Date: Mar 2013 Location: Enschede, Netherlands Programming is fun 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). 0
 Apr 2, 2013, 10:10 AM #2 robvas macrumors 68000   Join Date: Mar 2009 Location: USA One of the first programs I wrote that was somewhat complicated was a Doom level viewer - after reading the unofficial Doom specs 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. 0
 Apr 2, 2013, 11:25 AM #3 notjustjay macrumors 603     Join Date: Sep 2003 Location: Canada, eh? 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 __________________ . 0
 Apr 2, 2013, 12:59 PM #4 ArtOfWarfare macrumors 601     Join Date: Nov 2007 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... 1
 Apr 2, 2013, 01:31 PM #5 whooleytoo macrumors 603     Join Date: Aug 2002 Location: Cork, Ireland. 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. __________________ Mac <- Macintosh <- McIntosh apples <- John McIntosh <- McIntosh surname <- "Mac an toshach" <- "Son of the Chief" 0
 Apr 2, 2013, 04:43 PM #6 larswik macrumors 65816   Join Date: Sep 2006 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. __________________ I know more than yesterday. Lars 0
 Apr 2, 2013, 04:46 PM #7 Hans Kamp Thread Starter macrumors member   Join Date: Mar 2013 Location: Enschede, Netherlands 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: Last edited by Hans Kamp; Apr 2, 2013 at 05:02 PM. 0
Apr 2, 2013, 11:28 PM   #8
ArtOfWarfare
macrumors 601

Join Date: Nov 2007
Quote:
 Originally Posted by larswik 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.
__________________
Battery Status - On the Mac App Store
The only app that'll estimate when your wireless devices will need their batteries changed.
Including the ones paired with other Macs on your network.
0
Apr 3, 2013, 02:05 AM   #9
larswik
macrumors 65816

Join Date: Sep 2006
Quote:
 Originally Posted by ArtOfWarfare 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.
__________________
I know more than yesterday.
Lars
0
 Apr 3, 2013, 02:49 AM #10 Hans Kamp Thread Starter macrumors member   Join Date: Mar 2013 Location: Enschede, Netherlands 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. Last edited by Hans Kamp; Apr 3, 2013 at 03:42 AM. 0
 Apr 4, 2013, 04:29 PM #11 larswik macrumors 65816   Join Date: Sep 2006 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. __________________ I know more than yesterday. Lars 0
Apr 4, 2013, 05:20 PM   #12
ArtOfWarfare
macrumors 601

Join Date: Nov 2007
Quote:
 Originally Posted by larswik 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.
__________________
Battery Status - On the Mac App Store
The only app that'll estimate when your wireless devices will need their batteries changed.
Including the ones paired with other Macs on your network.
0
 Apr 6, 2013, 01:02 PM #13 Sydde macrumors 68000     Join Date: Aug 2009 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. __________________ Mr. Paul, sir, I thought you should be advised, there seems to be a zombie tribble clinging to your head, for it is scarfing your brain 0
 Apr 6, 2013, 02:50 PM #14 Hans Kamp Thread Starter macrumors member   Join Date: Mar 2013 Location: Enschede, Netherlands 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. Last edited by Hans Kamp; Apr 6, 2013 at 02:55 PM. 0

 MacRumors Forums