Done?

We will be demo-ing our work for the class in a little under 3 hours. Currently emulated is: the cpu, the graphics, and the controllers. Most of this seems to be, finally, working correctly.

Since, we aren't emulating MMCs we can't run games that date after the NES' launch. Furthermore, since there is no sound emulation, games that attempt to synchronize execution with the sound unit will simply not work. This unfortunately includes Mario... A fix would be to implement sound... an easier one would be to fake the interrupts. Neither of these are going to get done by 3 pm today.

However, we will be demoing several "fully" working ROMs: Ice Hockey, Arkanoid, Donkey Kong and Hydlide.

NES BIt Manipulation...

... is a pain!

In order to draw a sprite the nes creates a 4-bit value which it uses to index a color in a pallete. These 4-bits (conveniently) come from disparate locations in memory. The lower two bits come from a "pattern table" however they are 8 bytes apart. The upper two bits come from the "sprite table".

Simply, I must access three seperate locations in memory, selectively make them fit together, look up a color, and then plot to draw one pixel. I can't wait until this is done...

Refactoring

As previously alluded to. I am no longer presently working on Unicon. About a week after I received that part-time job, I found out about an opening for a Software Engineer with the Physical Science Laboratory here on campus. Not-so-long-story made short: I got the job. So, now I am programming Decision Making Processes (A.I.) for The Man. Unfortunately, I can't go into detail here.

However, I am currently still taking 2 classes at the university. One of those is Advanced Software Engineering, for which we must work in groups to complete a semester project. Myself and two other intrepid individuals convinced the teacher to permit us to begin work on an Object Oriented NES emulator.

Work is progressing, the CPU is being emulated by someone who is not me, and is supposedly nearly done.

I, on one hand, am working on the PPU (Picture Processing Unit), specifically the area of sprite loading, and displaying (as opposed to backgrounds/scrolling).

Unfortunately, I won't be doing much work on this until the end of spring break; 2 weeks away.

More to follow.

Unicon, OpenGL and Compilers

So, I'm only on the Unicon project as a volunteer right now (IE I'm not actually doing anything). However, before downgrading myself (more on that later) I noticed a number of interesting parallels between computer graphics optimizations and compiler optimizations.

One big thing that the Unicon 3D graphics facilities does is create a display list of everything that you have commited to the scene. Everytime something changes (the camera moves, some animation occurs, new objects are placed in the scene) this display list is processed from front to back; automatically redrawing the scene for you.

It's convient and definitely not something that OpenGL does for you. However, calls placed to GLBegin() and GLEnd() (which are analogous to C's scoping facilities: '{' and '}') aren't, to the best of my knowledge, free. Hence, good programmers try to draw all of their triangles/quads/lines/etc at once. The afforementioned Unicon display list is obviously temporaly ordered. This likely creates instances where numerous display list elements could be combined together inside of one set of GLBegin and GLEnd.

Unfortunately, textures, materials, recursive drawing routines, et cetera make the problem unsolvable by simply combining list elements that use identical drawing primitives. It finds itself relatively analogous to the out-of-order-execution problem that Intel tried to hoist on compiler writers with the IA-64 (Itanium) architecture.

I really wish that my compiler course had covered optimizations, we only covered correctness, and a little bit of context sensitive error reporting.

An Update

I actually finished the program that I was working on for school back in late december, I just got distracted and never wrote about it. It does have a few bugs, and it doesn't do bump-mapping, but it does do everything else I set out to do.

If anyone actually wants to see pictures, say so, and I'll upload some.

At present, I am working for one of the professors at New Mexico State University. His pet project is a programming language called Unicon, a superset of Icon. I'm going to be helping to improve the OpenGL support in Unicon. It does do OpenGL but its functionality is terribly limited, and rediculously slow.

However, before I can get to mucking around with how Unicon implements OpenGL I need to learn Unicon (and thus Icon). I need to get Unicon running on my system and make a few test programs. I want to make something that will fully flex all of Unicon's present functionality. I'm thinking about a 3D model viewer.

I've been hired to work on this for 10 hours a week on this, so I should be able to make some decent progress.

Almost Done

I didn't do any programming last week, and I forgot to update after I finished programming two weeks ago. I've made some decent progress.

Currently the program can:

-Dynamically load numerous data files, and display them all.
-A simple grid has been added to make determining where you are looking on the x-axis simpler.
-The graphs can have segments of any length and color.
-Musical texture is presently implemented with translucency.
-The frame-rate has been locked so the program will run at the same speed on multiple computers.
-To make the graph easier to understand the program can load and play MP3 files. While doing so a blue line moves through the graph in time with the music.

The program can not:

-Remove a graph once it has been loaded.
-Rotate the graph based on the orientation of the camera. IE "Up" is not relative, it is a fixed direction.
-Display bump-maps or anything that could really help with depicting musical texture.
-The resolution can't be changed, it is fixed at 1280 x 800 (in both windowed and fullscreen mode)
-Display a help screen of any kind.

There are probably an uncountable number of bugs. I'm also sure that it's extremely slow.

I don't think I'll get the bump-mapping implemented. I intend to do the others if I can. Finally, I'd like to add in some mouse-controls, but those can wait. The teacher also asked that I find a way to print "key words" from song lyrics on the screen. That should be fairly easy to do.

My group members screwed up their data-files or else I'd post some pictures.

Moving Forward - 前に進む事

We had our first milestone today. That makes the project sound a lot bigger than it is, but I can't think of anything else to call the review session that we did. I've decided to call the program that we presented to the teacher version 1, because it actually does what the original specifications where.

To review, we are trying to create a 3D image that will depict the sounds in a piece of music. In the case or rev 1 it was Miles Davis' "Bitches Brew". In the case of rev 2 it will be The Beatles' "I Am The Walrus".

For Bitches Brew the program read in a intensity and pitch values from a text file. Those values where representative of the pitch and intensity of the trumpet at 0.5 second intervals.


This is the graph of the first 64 seconds of Bitches Brew. The x axis is time, the y axis is pitch, and the z axis is intensity.



For "I Am The Walrus" I am going to try to add the following items:

-Display multiple graphs at the same time.
-Allow the data file to specify its own time increments.
-Allow the data file to specify color.
-Allow the data file to specify texture.

The last two items are meant to depict the musical concepts of the same name. Color will be done, of course, with color. Texture is a bit different. For now I'm just going to use the alpha channel to depict texture. However, the ultimate goal is to implement bump-mapping.

I guess I better get to work.

A First! - 初めてだ！

Today I received my first nebulous request for change! My other group members aren't programers, they are self-proclaimed media-artists. Anyway, I received the following picture attached to an email that said:

"While thinking about saving the data, it seems that like in the attached image, reality and the graph may differ. I think that it would be better if we where correct the graph to this."



The left hand problem is the same as the right hand one and they both exist. However, it is a problem present with the data given to me, not with the program. Essentially rapid changes in the music that occur between our sampling points will be left out. There's nothing that can be done except to increase the number of data samples over a given period.

That's not entirely true. I could allow the data file to also specify the time of a given sample. Presently it assumes that each line is a fixed chronological distance from its neighbors. This wouldn't be too difficult to implement, I just don't know that I'll have the time to fix it in 3 days. I am a student.

Of course I guess if I was crazy the data file could hold data for elements like curves, spikes and plateaus. Or maybe the user could use my program to directly manipulate the data. It sounds interesting to me, but I have no idea where the programming for something like that would even start.

We'll meet this week and see if we can find a solution that leaves everyone happy, or at least me not having to do much work.

The State of Things - 今の状況

Revision 1 of my graphing program is complete.

The X-axis extends to the right and is representative of time. Y proceeds up and is pitch. Z is headed down out of the screen and is the intensity.



Currently the program:
*reads from a fixed data fill in the same directory as the executable
*allows translation with the arrow-keys and page-up, page-down.
*allows rotation with a,c,d,s,x,z

Currently I want to:
*label the axis
*add in mouse control
*lock the speed of scrolling, and rotating so that it can be used on other computers
*print out various information at the top of the screen
*allow the user to select new graph-data-files while the program is running