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.

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.

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.

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.