Showing posts with label language. Show all posts
Showing posts with label language. Show all posts

Thursday, February 6, 2014

Book Review #22


Book #22 Programming Linux Games
John R. Hall

Programming Linux Games is an old, old book. In fact, it's obsolete. The reason is that SDL has evolved toward a better set, and some of the functions are deprecated. In addition, it uses plain old C language, that although a great language to use, it has been superceeded by C++, and Java, among other languages. Still, there's enough similarities between this book and current SDL that it's a great introduction to the process of SDL programming.

One of my most frustrating endeavor is finding the proper answer to my question regarding any graphic library: "How do you draw a point on screen?"

That one very simple question is frequently unanswered in great many graphical programming book. I know that's silly, but there you go. This book answers the question right away: Using surface.

"Each SDL_Surface structure contains a pixels member. This is a void * to the raw image, and we can write to it directly if we know the type of pixel that the surface is set up for."

And upon those two sentences, I bought the whole book!

It's a good book, marred only by the fact that it's so old, it's obsolete. However, reading this book followed by reading SDL man pages is infinitely preferable to just going straight on without guidance. The explanations are solid, and adapting the code to newer system is not a problem.

FYI, the ever popular PyGame extension for Python uses SDL for the base. SDL is a good graphic library to learn, especially if you're really interested in harnessing the speed and efficiency of C language.

For those of you still stuck with C programming, give this book a read. You just may like what you see.

Thursday, December 12, 2013

Book Review 14


Book #14 Getting Started with Processing
Casey Reas and Ben Fry

First of all, I love the Processing language. It's fun, portable, and easy to learn. I abhor the name. Why? Because every time I google it, I never found it! Really, I think Proce55ing is better because when I google that, it goes right to the site!

So, having actually learned the language, why did I pick up the book? Because I love the language and I want as many people to use it as possible. The book is interesting because it is the first "Getting Started" book from O'Reilly that I found. And I found out that hand-drawn sketches makes perfectly usable illustrations, even when it can best served with computer graphic or CAD.

I find the book features just the right amount of personal touches for the artist in me, and yet not skimp on the technical side for the scientist in me. A rare treat that is yet to be duplicated from other "Getting Started" books.

The only complaint that I have is that the subject matter is too brief. It touches on other Processing usage, such as Arduino. However, I think that extra projects such as Arduino is best left to other "Getting Started" book. You can put a mention there, of course, but let's not dwell upon them.

All in all, a good book marred only by trying to be comprehensive in a small book. Highly recommended.

Friday, November 29, 2013

Petit Computer Journal #27

Boolean Operator Division

Have you ever wondered just how difficult it is to do division using nothing but NOT,AND,OR,XOR? Well, so do I. It turns out I also need ADD,SUB, and CMP. Also, Shift command. Still, these are easily within the domain of any assembly language programming.


  1. CLS
  2. A=RND(255):B=RND(15)
  3. ?A,B
  4. C=0:D=128:E=B*D
  5. FOR I=1 TO 8
  6. IF A-E>=0 THEN A=A-E:C=C+D
  7. ?A,B,C,D,E
  8. D=D/2:E=E/2
  9. NEXT I
  10. ?C,A
  11. FOR I=0 TO 8
  12. VSYNC 1:I=BTRIG():NEXT
  13. GOTO @DIV2


A contains the number to be divided. B contains the number that divides. This computes C=A/B and A=A%B. A pretty nifty code that fits single screen challenge. Notice, that you can also do it this way (untested) on line 6:


  1. A=A-E:IF A<0 THEN A=A+E ELSE C=C+D

This way, due to the calculation in Assembly language where the register holds the resulting value of the calculation.



Sunday, August 18, 2013

Raspberry Pi Journal #8

Too Many Failures

In order to learn something new, you must first admit that you are stupid. After all, if you are smart, then you already know whatever it is you're learning.

Raspberry Pi has gone so far, and it's a relatively stable system, now. Furthermore, with NOOBS, installing the operating system is as easy as selecting item from a menu. Unfortunately, that's not all there is.

I know the Foundation has decided on Scratch for beginners, and Python for everybody else. I will not question their decision. However, I am used to having BASIC programming language to teach beginners.

My view is strengthened by the fact that Nintendo DSi/3DS has an app called Petit Computer. I happen to think that it is the perfect system to learn computer programming: Portable, cheap, convenient, and relatively powerful. There are numerous games exists to stand as template for what to do. That is all you need to learn computer game programming, and the one I recommend to everybody.

Enter Python. Even assuming that people have no problem learning the keywords, there exists certain conventions that will trip up people. The fact that Python tutorials use lists concept quite a lot, and no compatibility in BASIC, will certainly trip up a lot of people. It certainly tripped me, and I'm used to doing Perl and Lisp. I have experience in dealing with recursive lists, but is that something you want to teach to beginners? I don't think so.

Then there is a reliance upon libraries. Some of these, are in fact, rather shallow. By that I mean if you just spend a little bit more time explaining the algorithm behind the scene, you could've taught people on how to roll your own. Alas, that knowledge is kept secret. I, for one, know that depending upon libraries will hurt you long term. I depended upon Linux OS to process my procedures. What happened when I moved to Windows? Yup, big fail.

The problem is, I have no satisfactory BASIC language for Raspberry Pi. BBC Basic is too old. SDL Basic seems buggy and underpowered. Doesn't seem to have array. BASIC256? I forgot what it was, but I'll do a wait and see. Will visit it later, maybe sometime next year.

Somebody in the forum suggested that Python is the new BASIC. I'm still investigating it, but so far, there's nothing to suggest that Python can be friendly to beginners. That is, if you do it right, and not insists upon using efficient, high-level construct in Python.

Perl has a friendly attitude: There's more than one way to do it. Since different people do it different, Perl has the reputation of being "write only". I admit that learning to program differently is not a skill other people can master easily. But you can learn to do great things with Perl easy, just as so long you don't have to deal with other people's program!

Python, on the other hand, has the attitude of: There can only be one way to do it: the right way! In theory, it sounds great. In practice, there is always somebody who did it the boneheaded way, anyway. While my Python skill has improved tremendously, there is the odd occasion when I'm stumped in reading somebody's Python program. Pseudocode-like? I don't think so.

Personally, I prefer Processing, which is a bad name due to the difficulty of searching it using search engine. "Processing" is a very common word! I like the language, though. There are two problems associated with Raspberry Pi. (1) It's not officially supported. (2) It runs very slow when it does run.

I can't vouch for non-supported slow poke as good introduction for beginner!

So that left us with Python. I don't like it, but assuming I stay away from more advance techniques, I guess it's workable. I will continue to study the language and we'll see what happens.

Another failure is my attempt to back up my SD card. Yes, it's still not backed up. Would you believe that I run into "Out-of-Space" error? Both cards are formatted blanks. How come I don't have enough space? My guess is that I need to either partition the card slightly less than 14 GB. Maybe 10 GB. That way, it gives a leeway for other stuff.

Then again, my flashdrive has "File too big" error when it reaches 4GB. Another guess is that FAT32 maxed out at 4GB. So, when saving images, I need to compress it to less than 4GB. Needless, to say, I'm not happy!

I will not repartition my SD card without back up. I will get a 32 GB card, and see if I can back up into that, then I will repartition that card into 4GB chunk partition. Then, I will write the script to back up with compression. Hopefully, that will work just fine.

I found out that there is no swap partition, though. There's NOOBS partition, boot partition, and main partition. There is something about 2 MB, but I don't know what it is. Never mind. My next card will have 4 GB partitions all around. I hope that I have enough space for /usr/bin. I'll be installing quite a bit of software. My Robo3D printer just came in, and I'll be hooking it up to Raspberry Pi, for sure!