Showing posts with label 22. Show all posts
Showing posts with label 22. 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.

Monday, January 20, 2014

Cooking Journal #22


Cooking #22 Dehydrator






Yep, got myself a dehydrator. It works fine. What you see there is a bunch of kale leaves being dried. Kale chips are rather popular, don't you know? So, I dried them. It works well enough, I suppose, but what happens is that I have to rotate the tray every so often. The end result is great, though. So, this technique is certainly doable.

I'm unsure about contamination. My thinking is that the warmth will cause bacteria to multiply rapidly. So, I don't know. Perhaps if you maintain a septic kitchen it's alright. For me, though, this dehydrator is going back out.

Got to admit, though, those dried kale chips were terrific!


Friday, October 25, 2013

Petit Computer Journal #22


5. Loop with Player input + background process


Last post, we were dealing with idle loop and how we process the button inputs and the corresponding code handlers. This time, I'm going to show you a clearer form to handle player input.

One of the most asked question is how to move the player sprite UDLR, and shoot. I'm going to show you how you should structure your code and divide it into two parts:


  1. Process Input
  2. Act on Input


While we are processing input, we want it very, very quick. This means that we do not act on any of the input at all. We simply store the information and that's it.

Later on, depending on the variables set, we can process the data. I'm using an extra variable to determine whether or not the player is shooting, and whether or not the bullet is being shot.

This is a very simple structure. If you can use array for directions, then I suggest that you use it. Even loading array using DATA statements is preferable to hand-coding it, like I'm doing here. Even though it doesn't take much time at all, copying and pasting, using array is the neater and better solution. Easier to maintain, too.

We'll take a look at multi-threading process next.



  1. ACLS
  2. SPSET 1,68,0,0,0,0
  3. SPOFS 1,128,96
  4. SPSET 10,40,0,0,0,0
  5. SPANIM 10,2,6
  6. SPOFS 10,-50,-50


  7. @INIT
  8. PD=0:'PD=PLAYER DIRECTION. 0=STOP.1234=UDLR
  9. BB=0

  10. @LOOP
  11. ' PROCESS INPUT
  12. VSYNC 1:TX=TCHX:TY=TCHY:TS=TCHST:TT=TCHTIME
  13. B=BUTTON(0)
  14. SPREAD(1),PX,PY

  15. IF (B AND 1) THEN PD=1
  16. IF (B AND 2) THEN PD=2
  17. IF (B AND 4) THEN PD=3
  18. IF (B AND 8) THEN PD=4
  19. IF (B AND 16) THEN PA=1 ELSE PA=0:'PLAYER ACTION: SHOOT

  20. 'ACT ON INPUT
  21. 'THIS SECTION IS THE IDLE SECTION
  22. IF (SPCHK(1) AND 1) GOTO @LOOP ELSE GOSUB @PMOVE
  23. IF (SPCHK(10) AND 1) THEN BB=1 ELSE BB=0

  24. IF !BB THEN SPOFS 10,-50,-50
  25. IF PA AND !BB THEN GOSUB @PSHOOT:PD=0
  26. GOTO @LOOP

  27. @PMOVE
  28. IF PD>4 OR PD<0 THEN PD=0
  29. ON PD GOTO @MSTOP,@MUP,@MDOWN,@MLEFT,@MRIGHT
  30. @MSTOP
  31. SPCHR 1,68
  32. SPANIM 1,1,0
  33. RETURN
  34. @MUP
  35. SPCHR 1,76
  36. SPANIM 1,4,15
  37. SPOFS 1,PX,PY-16,60
  38. RETURN
  39. @MDOWN
  40. SPCHR 1,68
  41. SPANIM 1,4,15
  42. SPOFS 1,PX,PY+16,60
  43. RETURN
  44. @MLEFT
  45. SPCHR 1,72
  46. SPANIM 1,4,15
  47. SPOFS 1,PX-16,PY,60
  48. RETURN
  49. @MRIGHT
  50. SPCHR 1,64
  51. SPANIM 1,4,15
  52. SPOFS 1,PX+16,PY,60
  53. RETURN

  54. @PSHOOT
  55. IF PD>4 OR PD<0 THEN RETURN
  56. ON PD GOTO @PSTOP,@PUP,@PDOWN,@PLEFT,@PRIGHT
  57. @PSTOP
  58. GOTO @PDOWN
  59. RETURN
  60. @PUP
  61. SPCHR 10,46
  62. SPOFS 10,PX,PY,0
  63. SPOFS 10,PX,PY-160,160
  64. RETURN
  65. @PDOWN
  66. SPCHR 10,42
  67. SPOFS 10,PX,PY,0
  68. SPOFS 10,PX,PY+160,160
  69. RETURN
  70. @PLEFT
  71. SPCHR 10,44
  72. SPOFS 10,PX,PY,0
  73. SPOFS 10,PX-160,PY,160
  74. RETURN
  75. @PRIGHT
  76. SPCHR 10,40
  77. SPOFS 10,PX,PY,0
  78. SPOFS 10,PX+160,PY,160
  79. RETURN


Monday, September 16, 2013

Raspberry Pi Journal #22


Constructing ToDo Files  


I'm rather busy. In fact, I'm so busy that I'm constructing a master ToDo list, and it's rather long. So, I cast about ways to automate the process. Well, Linux to the rescue. It has sophisticated shell commands that allows me to sort the different stages on my list. This is an example of my master todo list, called "MasterTask.txt"

TASK: Petit Computer
Petit Computer Picross Dec 2012 hold
Petit Computer Journal #N WITCH start
Petit Computer Journal #N Virtual Keyboard todo
Petit Computer Journal #N Turtle Graphic

TASK: Raspi Journal
Raspi Journal: ebook - calibre - done
Raspi Journal: Log Frequency List
Raspi Journal: ToDo List
Raspi Journal: webcam, motion: Deer camera on the cheap todo
Raspi Journal: SD Back Up #3 Success with TAR
Raspi Journal: SD Back Up #4 A little thing called rsync
Raspi Journal: Can a Raspberry Pi be used to create a backup of itself?
Raspi Journal: SD wear leveling

TASK: Book Reading
Raspberry Pi for Beginner done
Programming Linux Games
Algorithm in C++
Modernist Cuisine at Home

So, as you can see, the format is simple. There is "TASK:" in the beginning of a line, representing a header. A single line per task, and a status word at the end of the line. They are:

start - the project has been started
todo - the project has been scheduled
hold - the project has been put on hold
wait - the project is waiting for a missing part
done - the project has been completed
skip - the project has been cancelled

What's the difference between started and scheduled? Sometimes, the project needs some materials to be purchased. While I'm gathering materials for the project, it will not be scheduled. Only once all the materials has been gathered will the project status be changed to "todo"

So, what I want to do is to create several files:
TaskToday.txt - contains all the "start" and "todo" projects
TaskHold.txt - contains all the "wait" and "hold" projects
TaskDone.txt - contains all the "done" and "skip" projects
TaskLog.txt - a running log of all projects done.
TaskNext.txt - The updated MasterTask.txt minus all the finished projects

Looks to be comprehensive, right? Usually, in C programming, I would need quite a lot of lines of code in order to achieve those tasks. I need a less lines if I'm using one of those "convenient" scripting language, such as Perl. I'm wondering just how difficult it is to do the whole thing using bash shell. In fact, here is the script that I'm using.

#!/bin/bash

cat MasterTask.txt | grep -e ^TASK -e 'todo *' -e 'start *' > TaskToday.txt
cat MasterTask.txt | grep -e ^TASK -e 'hold *' -e 'wait *' > TaskHold.txt
cat MasterTask.txt | grep -e ^TASK -e 'done *' -e 'skip *' > TaskDone.txt
cat MasterTask.txt | grep -v -e 'done *' -e 'skip *' > TaskNext.txt

#CycleLog
date >> TaskLog.txt
cat TaskDone.txt >> TaskLog.txt
#cp TaskNext.txt MasterTask.txt

And that's it! Pretty much all one-liner. Let's explain this a little bit. I'm using the commands "cat", "grep", "date", and "cp". That's it. You can figure out what the options are from the "man" command. "man cat", "man grep", "man date", "man cp".

So, the first line, basically says: Type out the contents of MasterTask.txt and pipe it to "grep" which will take all the lines that is
1. Starts with "TASK" or
2. Ends with "todo" or
3. Ends with "start".
Then pipe those lines into a file called TaskToday.txt. Same thing with the next two lines with "hold/wait" and "done/skip"

The fourth line says to pipe the all the lines, *except* the ones that ends with "done/skip"

The "-e" option simulates egrep, except as I understand it, egrep is deprecated.

The Cycle Log part is simply appending the current date to TaskLog.txt, then piping out the content of "TaskDone.txt", appending it to TaskLog.txt. That's about it.

The last line is commented out, since I like to do it manually while testing the script. It simply replaced MasterTask.txt with TaskNext.txt. In other words, take out all the "done/skip" tasks from MasterTask.txt. It's that simple!