Sunday, April 27, 2008

97k demo program

http://www.shamusyoung.com/twentysidedtale/?p=537

This blog describes a 97k game demo program. He writes that procedural programming helps make the game look good while keeping the usage of space minimal.

Sunday, April 20, 2008

more python information

http://socal-piggies.org/scp

There is a SoCal Python users group and they had a meeting at Disney in LA about how it is used by their animation people.

comp.lang.python

This newsgroup had some information about GUI kits.

They mentioned Qt & PyQt, wxPython, and Tkinter.

Thursday, April 17, 2008

python development continued

I found some links related to Python development with an IDE and a standalone debugger:

http://spyced.blogspot.com/2008/04/python-ides.html

http://prabhuramachandran.blogspot.com

I'm not sure where to start yet. There's idle and scite to keep it simple. Eclipse could be an option too because I've used it for some Java development before. Finally, some one at the first link commented about looking for an ide with a good gui designer. That sounds like it would be useful.

Sunday, April 13, 2008

Python related to computer graphics

I was given some Python related information about computer graphics.

After some more looking around, it turns out 3d buzz has some information about using it for scripting in Houdini and Maya, but it is not free.

Also the python.org site has an article about ILM using the language.

From the article it mentions how some companies developed their own software as an insurance policy for the future because of the possibility of needing custom extensions or improvements.

Basically, it sounds like they gradually used it for their toolset:
"As Python was applied in more ways, it slowly crowded out a plethora of competing technologies for shell scripting and batch control, embedded scripting, component software development, database application development, and so forth. Python's versatility ultimately simplified the developers' toolset and reduced the number of technologies that needed to be deployed to ILM's thousands of production computers. This new, simpler toolset translated directly into an easier to manage and more reliable development and production process."

So it does sound like they used it as a "glue" for their various software assets.

Saturday, April 12, 2008

Code metrics in Visual Studio 2008

MSDN blog entry about code metrics in Visual Studio 2008

Some other blogs have commented about this already. For example, here is an entry from a guy in Russia.

The blogger warns about problems with the lines of code metric. I was just reading Code Complete about the topic. The guideline given there is to limit the number of lines of code per routine to around one screen or one or two pages of program listing, or about 50 to 150 lines. He warns against routines longer than 200 lines and notes that there has been some inconclusive research on the quality of routines less than 200 lines. I've also heard of another guideline that an entire class should be less than 300 lines.

Friday, March 07, 2008

Arduino board


Arduino board


I am interested about electronics and have started playing with an Arduino board to learn more. I am not familiar with the tools to assemble it and ended up playing with very basic things such as a soldering iron, 22 gauge solder, a board holder, magnifier, a clipper, a holder for the soldering iron, a multimeter. Besides the tools, other basics such as figuring out the ratings of capacitors and resistors had to be done. With some help from some other people, the hardware has now passed a simple blinking led test.

rfid for horse riding

High tech for horses

This article describes a system where cameras are aided by rfid tags and sensors to help videotape horse riders.

Snake Robots





This video had some interesting demos of the capabilities of snakebots: climbing poles, looking in boxes, and swimming.

This video was done at CMU, but there are other places working on similar projects as well: NASA, University of Michigan, and University of Washington.

Wednesday, March 05, 2008

Podcast about Blender

http://www.twit.tv/floss25

This podcast looks interesting. The site looks like it has a bunch of other neat stuff as well.

Sunday, March 02, 2008

Ubuntu sound capture

I've started trying out Ubuntu.

This program helped:
http://en.wikipedia.org/wiki/Alsamixer

I am currently using 7.10 and the console program mentioned there still worked.

After getting the gnome sound recorder to work, I went to Audacity and chose Edit -> Preferences . . . ->Audio I/O->Device: ALSA:default



to get it to use the new settings since I had changed them earlier trying to get it to work.

Monday, February 18, 2008

VIA's next-gen Isaiah x86 cpu architecture

http://techreport.com/articles.x/13996

from the article:
"A look at VIA's next-gen Isaiah x86 CPU architecture

An all-new design from a surprising source
by Scott Wasson — 3:29 PM on January 24, 2008

A brand-new x86 processor microarchitecture doesn't come along every day, but today, we have just that."

Note of a Wish List for Blender Game Engine

http://apricot.blender.org/?page_id=14

Some stuff is for humor (GGG button) and much of it is beyond me, but they did remind me about the concept of static code analysis tools. Many years ago I heard of one for C by Parasoft and that it was kind of slow if there was a lot of code to analyze. But I plan to look into this. PC's have gotten faster and certainly the technology should have improved.

Peach Open Movie Renderfarm Note

http://peach.blender.org/index.php/our-renderfarm-and-how-it-works/

This site shares some experience of working on a renderfarm grid owned by Sun. They used Blender on 64 bit machines to do the rendering.

Thursday, February 14, 2008

Robotics store closing

http://www.tinmanrobotics.com/

The robotics store in town is going out of business unfortunately.

Of course, there are still options through the internet. It was nice having a place so close though where people could learn and purchase things about robots.

Friday, February 08, 2008

software skeleton when doing development

Lately I've been spending more time reviewing software development basics than studying graphics. I've heard of building a software "skeleton" and then adding meat to it but am looking for a definition of the concept in specific software development terms. The integration chapter of Code Complete has some information about it. He organizes it under the topic of incremental integration and describes the skeleton as a small, functional system. It is the smallest functional, difficult, critical, or some combination of those qualities that will run. After thoroughly debugging and testing it, new classes may be added a little at a time after they have been tested on their own. This helps make debugging the entire system easier.

The way classes are added is described in the later part of the chapter. For example, there are bottom up, top down, T-shaped methods.

Friday, February 01, 2008

notes for an old programming project

Sometime between 1991 - 1995 I helped a couple other guys with an attempt at programming a game. These are some technical notes about it drawn from my memory of what others said and did and my own recollection.

what went well
  1. Usage of C/C++. This went well to the extent that it didn't get in the way much. An earlier attempt at a different project for the Mac in Pascal encountered problems with memory possibly due to code module restrictions. An attempt was made to use overlays, but as far as I can recall that was unpleasant. Also on the plus side it allowed some low level stuff like some inline assembly and an ISR for the keyboard. Some other language compatible code found was a mode X graphics library by Michael Abrash. The main negative experience I recall was a situation with linking with some C routines that should have been compiled as C++. In terms of code it was all procedural because that's all we knew.
  2. Tool development. This was an interesting aspect of the project. A paint program and brick editor were developed. Some DOS batch scripts were made. The paint program had a zoom feature and its own file format.
  3. Design. The project was not finished so it was not proven, but there were some interesting ideas. It was 2-d platform. Kind of like Prince of Persia. There was going to be some sort of weapon power acquisition by interaction with other characters. For example, a fist was implemented. Abilities could be enhanced temporarily. For example the main character could get better leaping ability. There was a spin move kind of like the Metroid Prime MorphBall. The game would be broken up into worlds and each world would break into a series of screens. Also, there was some sort of scheme for a family of actions.
  4. Prototype. Enough of the program got running to show to people. Thankfully it did not get stuck in the planning stages.
  5. Low overhead. Majority of the work/decisions were done by one guy (not me).
what could have been done differently
  1. Version control. An additional tool that would have been nice is a version control program. A bunch of images were accidentally deleted on a floppy. Some sort of source code and data file management system would have helped avoid the work to restore them.
  2. AI. NPC control was handled basically by a state machine. Looking back something table based and maybe even another tool for creating/editing such a table might have been better.
  3. Data structure. There was a doubly linked list implemented but a singly linked list might have been better. A more generic implementation of the data structure would've been nice.
  4. Unit testing. There was a bug with relative positioning. Maybe a unit test with some sample numbers could've helped avoid it. Some diagnostic information was added but I don't recall the details of it.
Gigaman was a working title for it. It was for the PC. It didn't have sound effects. VGA required. Keyboard control, no other stuff needed.