Pitcher's Duel

10:20am: GUI Comparison

All of these kits were easily integrated into my own main loop, not requiring use of their own. Each of them also allowed me to set up my own display in pygame.display and plug it into the GUI. None of them are documented to my satisfaction. ;(

Starting with the least:

Mike Leonhard's GUI is one of two that implements a scrolling widget, but otherwise only implements a text entry widget and a button. It does handle wrapped text in labels. The biggest knock on this kit is that it overrides the keyboard repeat, and getting the keystroke entry to work is troublesome. The kit has not been maintained in two years, and Mike has moved on to other things, based on his web site.

Poutine, by Shandy Brown, separates itself from the others in that it is sprite-based. The widgets are sprites, located and drawn in the same fashion as other sprites in the game. The event loop does need to handle the various input events separately, rather than handing them off en-mass to a GUI event handler; each widget-sprite handles its own inputs. The range of widgets provided is very limited, including only buttons and text input.

The PGU GUI, part of Phil's pyGame Utilities, is a fairly comprehensive kit, providing most of the features my sample wanted. It does not provide a scrolling widget, but it does provide fairly sophisticated text rendering functions, including the ability to display html. It also includes a menu system (unique among these GUIs), dialogue boxes, and a 'toolbox' feature which selects between multiple options. This GUI is the most attractive of the set, also. Some features are not completely implemented, such as the ability to disable widgets.

The Ocemp GUI is the most feature rich of the GUIs I reviewed. The only features my sample wanted that it did not provide were image maps and multi-line edit, and none of the other kits provided those either. It provides a scrolling widget. The documentation provided in the code is as good as any, and the author is promising a usage guide document. The most serious limitation I found is the drab grey blocky appearance, and that may be a matter of my not understanding how to manipulate the styles.

I have had opportunity to correspond with both Marcus von Appen (Ocemp) and Phil Hassey (PGU) in doing these evaluations, and found each of these gentlemen to be helpful and interested in furthering use of their libraries.

For more detail on each of the four GUIs and source code for the sample pages, see my prior posts.  If you are evaluating GUIs for a Pygame game, please do install the Ocemp and PGU libraries, and download/copy and run my sample scripts for each, to see for yourself how they behave. 

David

10:02pm: Phil's pyGame Utilities GUI

The PGU toolkit has a fair range of widgets, but lacked a progress bar, toggle buttons, image maps and the edit box. To display the GUI widget responses, I used the text.write tool from the PGU toolkit. The log gets trimmed to keep it within displayable length.

The documentation was seriously lacking, consisting primarily of a series of 10 tutorials. None of these tutorials covered the Container layout tool, which is the most straightforward way to layout a page (using pixel coordinates). There were doc strings for most of the classes, but not for many or most methods.

The check boxes and radio buttons used a different status tracking style than Ocemp, in that it required a Group be instantiated and passed to the button initializers; the status for all buttons in the group is stored in the group, and CHANGE signal handlers are connected to the Group, rather than on the button directly. The widgets have a 'disabled' attribute, but it apparently only affects the tab-order access, not mouse sensitivity, and does not affect the appearance of the button. I could not find a way to disable a button completely.

The signal system is similar to that used by Ocemp, and excludes any event data, so the same criticism applies here. The widget constructors take a font parameter, which is a pygame font, so using differing fonts for different elements was fairly straightforward. The overall look of the GUIs produced by the default theme is attractive, with rounded visuals and bright colors.

If any of the above is inaccurate, I would be happy to receive specific
corrections, and I can revise this post to incorporate additional
insight into PGU GUI behavior.

10:17pm: Pygame GUI Comparison

Pitcher's Duel approaches a re-release of the batting demo, and I face the distinct possibility of being able to call the batter swing interface 'good enough', and move on to the next phase of the project. That phase will probably be choosing a GUI package, though a networking package is in the queue, and some small jobs remain updating the pitcher graphics code, and unifying all the anatomy drawing.

In choosing a GUI package, I plan to implement a simple demo interface in each of the candidate packages, and post, in this blog, the necessary code to implement, as well as screenshots of the resultant look. In my first look at each, I hope to avoid implementing any widgets, preferring to just use the best available widget for each part of the demo, and a 'not implementable' note where the GUI provides no similar widget. I may do a second pass later, enhancing some demos by creating new widgets.

The demo interface is pictured in the attached image:
Each widget click will result in a line being added to the editable text box, in addition to the immediate state change of the widget. The editable text box will collect result indicators, as well as demonstrating the text edit capability. The progress bar indicates the filling of the edit box, in a line count sense, assuming 30 lines = 100%. Buttons will have both toggle (stay-down) and instant-return types, and buttons and check boxes will be inactivatable ('grey'able). The single line text input will append the text to the edit box. The image map tracks whether it is clicked, and where in the widget the click happens. The spinner (clock like feature) is not part of the GUI, but represents the native game display running concurrently with the GUI.

This demo omits any menuing system, partly because I don't anticipate using one in Pitcher's Duel, partly because I suspect they are a low priority in game interfaces (how common are they?) in general, and because most GUI libraries do not seem to implement them.

The libraries must support main-loop sharing, such that they can be integrated into an application that already has a significant main-loop; in general, the library should have a 'poll' method/function that can be called from the main loop with or without event data.

The libraries I expect to compare include:

PyUI2
Mike Leonhard's GUI
OcempGUI
PGU , Phil's pyGame Utilities
Poutine (depending on how much framework is required)

Faces and Features does not seem to have an edit-box, which would disqualify it for this comparison.

Do you know of others?

UPDATE: added spinner and image map

10:16pm: Ocemp GUI

This library is relatively complete, with a range of widget types. The only feature I could not represent at all was the image map, and the textbox was implemented as a scrolling-list box since there is no multiline text input box in the GUI. The plan was to have that box be editable, as well as displaying a log of actions.

The API exposes a 'signals' interface for triggering client behaviour through callbacks, but the specific event location (mouse pos) is not included in the signal, so there is no way for an image map callback to receive the location data. There is a 'notify' method on each class which gets the whole event and could be overridden for an image map widget, but that would require subclassing. For now, at least, I am trying to compare libraries using 'out of the box' capabilities.

The introductory documentation is scant; I relied on the numerous simple examples and the docStrings. The examples are nicely simple, which is good, but leave essential (even for beginners) features undescribed. A toggle button or checkbox, for example, is only useful if you can query the set/not-set state, but accessing that state is not clearly described anywhere, and took code reading and experimentation to worry it out. OK, you could use the checkbox signal to maintain an external tracking variable, without knowing how the state is maintained internally, but that seems un-robust.

The design included using larger fonts for the title and subtitles, as well as a uniformly white background. These are probably possible using the library, but my half-hour of reading and experimenting did not reveal a way. The style portions of the library are the most weakly documented parts, and all of the examples use the default grey monotype style.

If any of the above is inaccurate, I would be happy to receive specific corrections, and I can revise this post to incorporate additional insight into Ocemp GUI behavior.

10:16pm: Ocemp GUI Source code

# As part of the Pitcher's Duel Project, I am conducting a comparative
# analysis of pygame GUI modules, and publishing the results on my blog.
# The comparison consists of implementing the same sample interface on
# each of the various GUIs.  
#
# This code implements the interface using the Ocemp GUI library.  For 
# details on this library, see:
# http://ocemp.sourceforge.net/guidoc.html
#
# The module author is: Marcus von Appen
#
# This source code is the work of David Keeney, dkeeney at travelbyroad dot net

#Import Modules
import pygame
from pygame.locals import *
import time
import math

# import gui stuff
from ocempgui.widgets import *
from ocempgui.widgets.components import TextListItem
from ocempgui.widgets.Constants import *

screenSize = (642, 429)

# define the necessary callback functions.
#  these are connected to signals within their respective
#  widgets, and invoked by the gui
#
def logAction(ed, text):
    """ add the text to the 'edit' window (callback function)"""
    ed.items.append(TextListItem(text))
     
def logButtonAction(ed, btn, text):
    """ add the button status to the 'edit' window (callback function)"""
    if not btn.active:
        text += ' SET'
    else:
        text += ' UNSET'
    #text += str(btn.active)
    ed.items.append(TextListItem(text))
     
def logTextAction(ed, txtWidget):
    """ add the text to the 'edit' window (callback function)"""
    text = txtWidget.text
    ed.items.append(TextListItem(text))
     
def logSlider(ed, slider):
    """ add the slider position to the 'edit' window (callback function)"""
    #text = str(slider.get_coords_from_value())
    text = 'Slider is at ' + str(int(slider.value)) + ' %'
    ed.items.append(TextListItem(text))

def progBar(pb, list):
    """ update progress bar for len of list (callback function)"""
    prog = len(list) / 20.0 * 100
    if prog > 100: prog = 100
    pb.set_value(prog)

# the body of the program is here
#
def main():
    """this function is called when the program starts.
       it initializes everything it needs, then runs in
       a loop until the function returns."""

    #Initialize Everything
    pygame.init()
    screen = pygame.display.set_mode(screenSize)
    pygame.display.set_caption('GUI Test - Ocemp')

    # create GUI object
    gui = Renderer()
    gui.screen = screen

    # create page label
    lbl = Label('Pygame GUI Test Page - Ocemp')
    lbl.position = 29, 13
    gui.add_widget(lbl)

    # create progress bar label
    lbl4 = Label('Progress Bar')
    lbl4.position = 356, 355
    gui.add_widget(lbl4)
    # progress bar
    pb = ProgressBar()
    pb.position = 354, 376
    gui.add_widget(pb)

    # create edit box
    ed = ScrolledList(250, 320)
    ed.scrolling = SCROLL_ALWAYS
    ed.items.append(TextListItem('top line of input'))
    ed.items.append(TextListItem('second line of input'))
    ed.position = 367, 19
    gui.add_widget(ed)
    progBar(pb, ed.items) # update progress bar for above two items
    ed.connect_signal (SIG_LISTCHANGE, progBar, pb, ed.items)

    # create checkbuttons and add to gui
    cb1 = CheckButton ('Check Box #1')
    cb1.position = 52, 40
    cb1.connect_signal (SIG_CLICKED, logButtonAction, ed, cb1, 'Check Box #1 clicked')
    gui.add_widget(cb1)
    cb2 = CheckButton ('Check Box #2')
    cb2.position = 52, 70
    cb2.connect_signal (SIG_CLICKED, logButtonAction, ed, cb2, 'Check Box #2 clicked')
    gui.add_widget(cb2)
    cb3 = CheckButton ('Check Box #3')
    cb3.position = 52, 98
    cb3.connect_signal (SIG_CLICKED, logButtonAction, ed, cb3, 'Check Box #3 clicked')
    gui.add_widget(cb3)

    # create radio buttons, put in table, and add to gui
    rbTab = Table(3,1)
    rbTab.position = 210, 40
    rb1 = RadioButton('Radio Button #1', None)
    rb1.connect_signal (SIG_CLICKED, logButtonAction, ed, rb1, 'Radio Button #1 clicked')
    rbTab.add_child(0, 0, rb1)
    rb2 = RadioButton('Radio Button #2', rb1)
    rb2.connect_signal (SIG_CLICKED, logButtonAction, ed, rb2, 'Radio Button #2 clicked')
    rbTab.add_child(1, 0, rb2)
    rb3 = RadioButton('Radio Button #3', rb1)
    rb3.connect_signal (SIG_CLICKED, logButtonAction, ed, rb3, 'Radio Button #3 clicked')
    rbTab.add_child(2, 0, rb3)
    gui.add_widget(rbTab)

    # create txt box label
    lbl2 = Label('Text Box')
    lbl2.position = 31, 130
    gui.add_widget(lbl2)
    # create text box
    en = Entry()
    en.position = 31, 155
    en.size = 250, 21
    en.connect_signal (SIG_INPUT, logTextAction, ed, en)
    gui.add_widget(en)

    # create slider label
    lbl3 = Label('Slider')
    lbl3.position = 31, 190
    gui.add_widget(lbl3)
    # create slider
    sl = HScale(0, 100, 1)
    sl.position = 31, 215
    sl.size = 200, 20
    sl.connect_signal (SIG_MOUSEUP, logSlider, ed, sl)
    gui.add_widget(sl)

    # add buttons, both regular and toggle
    btnTab = Table(2, 3)
    btnTab.position = 30, 250
    btnTab.spacing = 10
    btn1 = Button('Button 1')
    btn1.connect_signal (SIG_CLICKED, logAction, ed, 'Button 1 clicked')
    btnTab.add_child(0, 0, btn1)
    btn2 = Button('Button 2')
    btn2.connect_signal (SIG_CLICKED, logAction, ed, 'Button 2 clicked')
    btnTab.add_child(0, 1, btn2)
    btn3 = Button('Button 3')
    btn3.connect_signal (SIG_CLICKED, logAction, ed, 'Button 3 clicked')
    btnTab.add_child(0, 2, btn3)

    btnA = ToggleButton('Button A')
    btnA.connect_signal (SIG_CLICKED, logButtonAction, ed, btnA, 'Button A clicked')
    btnTab.add_child(1, 0, btnA)
    btnB = ToggleButton('Button B')
    btnB.connect_signal (SIG_CLICKED, logButtonAction, ed, btnB, 'Button B clicked')
    btnTab.add_child(1, 1, btnB)
    btnC = ToggleButton('Button C')
    btnC.connect_signal (SIG_CLICKED, logButtonAction, ed, btnC, 'Button C clicked')
    btnTab.add_child(1, 2, btnC)
    gui.add_widget(btnTab)

    # create 'not implemented' label for image map
    lbl4 = Label('Image Map Not Implementable')
    lbl4.position = 31, 340
    gui.add_widget(lbl4)

    # make some insensitive
    btn2.sensitive = False
    cb3.sensitive = False

    #Main Loop
    while 1:

        #Handle Input Events
        for event in pygame.event.get():
            if event.type == QUIT:
                return
            elif event.type == KEYDOWN and event.key == K_ESCAPE:
                return

            # pass event to gui
            gui.distribute_events((event))
                
        # clear background, and draw clock-spinner
        screen.fill((250, 250, 250))
        radius = 30
        spinPos = 240, 362
        sp2 = spinPos[0]+1, spinPos[1]
        progressAngle = int(time.time() % 15 * 24 - 90) #60
        pygame.draw.circle(screen, (180, 180, 180), spinPos, radius, 0)
        for angle in range(-90, progressAngle):
            a = angle*math.pi/180
            tgt = radius*math.cos(a)+spinPos[0], \
                  radius*math.sin(a)+spinPos[1]
            pygame.draw.line(screen, (254,254,254), spinPos, tgt, 2)
        pygame.draw.circle(screen, (0,0,0), spinPos, radius, 2)
        pygame.draw.circle(screen, (0,0,0), spinPos, radius+1, 3)
        pygame.draw.circle(screen, (0,0,0), sp2, radius, 2)
        pygame.draw.circle(screen, (0,0,0), sp2, radius+1, 3)
        pygame.draw.line(screen, (0,0,0), spinPos, tgt, 2)
        tgt = spinPos[0], spinPos[1]-radius
        pygame.draw.line(screen, (0,0,0), spinPos, tgt, 2)
        
        # Draw GUI
        gui.update()
        gui.draw(gui.screen)

        pygame.display.flip()


main()

12:14pm: iUpLog
I am moving this weblog over to the iUpLog host.

They boast an impressive set of features in their free accounts, including
categories, so I can categorize python posts seperately from baseball posts, and
aggregators can take one without the other.

They are just out of beta, and I have seen incompatibilities with my work browser, but
the feature set wins me anyway.

So look to Pitchers Duel iUpLog for more.

Thanks to Livejournal for their service all year

David

3:05pm: .. on further thought
The COR is actually the ratio of velocities, rather than the ratio of KE, but the KE is proportional to the square of the velocity, so you can get there from here.

And since I decided that the COR (or square of COR) is the ratio of the KEs, I can use a modified conservation of energy rule, KE1 = COR^2 * KE0, in lieu of the straight KE1 = KE0, and simplify the above
quite a bit.

I sometimes dont understand what I am thinking until I write it out, and when I do the writing in a public blog, the public can watch the struggle. ;-P

9:26am: Momentum and Kinetic Energy
Collision detection is done now, and preliminary testing is done. But moving on to determining resultant velocity for the ball and bat has tripped me up.

The bat/ball collision is neither completely elastic nor completely inelastic. Those are the two cases that are completely understood and thus calculable without 'heuristics'.

For the elastic case, kinetic energy as well as momentum are conserved, and given known movement vectors,
the resultant velocities can be determined by solving two momentum equations (one per dimension, momentum is a directional quantity) and one KE equation (energy is conserved).

For the inelastic case, momentum is conserved, but not KE; however the two outcome velocities are identical, since the two would attach to each other. This case can be solved using just the momentum equations.

I have known quantities:
initial bat velocity (direction and speed)
initial ball velocity (direction and speed)
final ball direction
initial momentum and KE can be determined for bat and ball
final total momentum is known (equal to initial total momentum)
Coefficient of restitution (COR) for bat/ball combo

unknown:
final ball speed
final bat direction
final bat speed
final total KE

This problem, I do not have a pure solution for.

The approach I am tentatively taking is to:
1) calculate ball speed using elastic computations
2) de-rate above speed using COR
3) reduce total KE using COR
4) calculate bat velocity using elastic computations and assumed ball velocity and total KE

The elastic computation model is not a trivial one to implement, involving solutions to quadratic equations, and will probably need an iterative numerical solution, rather than a symbolic one. Ugh.

The COR is the ratio of KE final to KE initial. It can vary with impact velocity for a particular ball, but is sometimes assumed to be constant.

1:44pm: joystick
Yesterday, I found a few minutes (dreary day, overall, despite being Mardi Gras) to work on the joystick input to the batter demo, and it works fairly smoothly. The collision detection is still incomplete, so the batter interface remains difficult to evaluate fully; bat/ball coordination is hard to judge when the ball can pass right through the bat.

One consequence of abandoning the mouse for batter input is that now the rest of the interface should deprecate the mouse, too, in favor of the joystick. I think a joystick-event-to-mouse-event convertor may well serve us in adapting the joystick to the GUI. The mouse would then still be available, as an alternative to the joystick for GUIing.

7:48am: input
I have been mulling over the mouse problem, and have decided to abandon the mouse as an input device. Using mouse strokes mapped to bat strokes was an important part of my original concept of the game, so I leave it with difficulty, but the limitations are just too severe; I cannot rely on the mouse not skipping during the bat swing.

The input device will now be a joystick. How many gamers do not have joysticks? I am still mulling over how exactly the joystick motion will be mapped to bat motion. The simplest option is to just use rightward motion of the stick to compel progress by the bat, and up/down motion to control the vertical position of the swing. The other alternative is to require the joystick to emulate the bat motion, left briefly (off the shoulder) down a bit (to the strike zone), and then right (across the plate). So the joystick would have to move in an arc, timed appropriately. This could be awkward to learn, probably a bad idea.

More thought is required.

1:29pm: 'Spyre'
I fixed the 'FrameRateDisplay' object in Spyre, yesterday. That may be the last of the bugs in that library, that I know about. It may be time for the big '1.0' release.

I am still testing the getAbsPos method of the engine, so I may find problems there, yet.

My simpler tests have all passed, but it is not giving me pleasing values when used in the batter model. So I am writing fancier tests...

8:48am: Batter Model
As I was writing the previous post, I thought it would be nice to add an interface widget to track the 'height' of the swing along the edge of the strike zone, using an index mark. In the early part of the swing (the first 70%), the vertical position of the bat is difficult to see, as the bat is mostly vertical or pointed at the catcher. It doesn't sweep out over the plate until late in the swing, and is thus not extremely useful for hand/eye control purposes. The proposed index mark would make beginner play easier, and could be switched off for competition.

8:27am: Batter Model
The Batter Model is progressing nicely. The demo script will swing the bat through the full stroke, in what seems to be reasonable speed, with vertical coverage of the whole strike zone. Just what I was looking for.

However.

The mouse is proving to have limits as an input device for this, as it reacts poorly to being moved too quickly, in some cases, seeming to back-skip. I will continue to work with this, as the mouse is in principal a good input device, providing two modulating degrees of control.

I still need to do quite a bit of tweaking to get the batter responsiveness down to what my minds-eye expects, but I hope to get an interactive demo online by the end of the mnth (yes, that is February). I also have the rest of the interface to implement, including keyboard controls, as well as integreting the already completed pitcher model into the demo, and writing the bat/ball collision detection. What fun is a batter demo without pitches?

The controls are to be like:

mouse left/right motion => progress of leg step, body rotation, arm and bat swing.
mouse up/down motion => controls the vertical position of the bat through the strike zone
left/right arrows => body lean of batter
up/down arrows => knee flex of batter to help handle very low or very high pitches
'b' => bunt (not to be in demo)

Most of the action is in the mouse control, and hopefully is simple enough to learn and use, while remaining a matter of 'skill' rather than luck.

Your comments are welcome.

7:29am: Red/blue stereoscopy
Loafing around the internet yesterday, I came across some pages on creating those red/blue type stereographic displays from dual images. It turns out to be fairly straightforward to do this in OpenGL, using color filters and multiple drawing passes.

So the stereoscopic module within SPyRE (and pduel as a client) will have that as an alternate mode.

1:07pm: Py2Exe notes
I finally got py2exe working this last weekend, in packing up my pitcher demo. It was easier than I expected, actually, what guidance I needed in resolving problems was available on the web. The biggest problem really was a local foobar where I kept saving test code in a different directory than where I was testing, and wondered why my changes weren't reflected in test results. duh.

Here are my notes, for whomever may benefit:

add these two lines to the top of the script:
import sys
sys.path.insert( 0, '' )

This allows the script to find the manually added packages below. Py2exe includes
only the created library archive as the path, so the script needs to modify at runtime.

The setup.py file is ultra simple:
=======================
from distutils.core import setup
import py2exe

setup(console=['pitchdemo.py'])
========================

run it like:
python setup.exe py2exe excludes=OpenGL

This creates a 'dist' folder and a 'build' folder and copy the opengl and numarray directories from 'site-packages' into the 'dist' folder. The 'build' folder does not seem to be useful for anything.

You can remove many of the files and subdirs from these for distribution economy, but it will work as-is. Google on 'py2exe pyopengl' for advice to handle this.

Copy the basic font file 'freesansbold.ttf' from the pygame directory to the 'dist' dir, if you use the default font in pygame. Otherwise you will get 'segmentation fault' errors on running.

Run the .exe file from the dist subdir. It should work. You can distribute by just zipping up the entire directory contents. The recipient just unzips into a new directory and executes 'pitchdemo.py'.

The next release, I will go the next step with a self-extracting installer.

8:56am: Artist needed
If you looked at the demo, or at screenshots, you probably observed that the pitcher graphics are crude. We need a 3D artist to redraw the anatomy and make it look right.

If you are an artist with 3D tools, I need your assistance. This is an open-source freeware project, so we cannot pay, but we can provide credit in the website and in the product.

See sourceforge.net job posting link for details, or contact me.

Thanks,
David

8:49am: Pitcher Demo online
The pitcher animation aspect of the game is progressed enough to put a demonstration online. The file release area of the sourceforge pages now includes a pitcher demo. It just cycles repeatedly through an assortment of pitches; after each pitch, it outlines the strike zone and shows red/green where the ball passed. The interface has a dozen different pre-configured viewpoints, and each one can be zoomed.
The pitch can be left- or right- handed, on user request, and can run at full speed or 1/3 speed. There is a stereo- video display option, but you need edimensional LCD stereo glasses to view it.

Take a look.

http://sourceforge.net/project/showfiles.php?group_id=110483

9:04am: Progress
I decided against taking la.py out of SPyRE, largely because it includes some not-usually-part-of-a-matrix-package methods that are used by the demos ('bound' as a vector method, for example, to trim a vector to a given magnitude). Since I don't know of any bugs in the la module, it didnt seem worthwhile to switch over to CG classes. I am using the CG classes in new work, since they have a more thorough set of methods implemented, so if a conflict arises between CG in the script and la in the library, I can revisit this decision.

The stereoscopic and spyre modules both work smoothly now, so they have been bundled up and uploaded as Spyre.0.55 on sourceforge. However, I did not update the docs, and they need work (I have ink notes in my notebook that need to be edited into the html pages), so I expect to work on that tonight and rebundle/reupload (as Spyre.0.56) before I announce the upload via newsgroup and sourceforge 'news'.

The pitching demo works well now, as a choose-your-mode stereoscopic and monoscopic demo. A little more polishing this week, and I will be uploading that as its own release (pduel???). Then I can start soliciting artist assistance for refining the look. The pitcher model now is a cobbling together of cylinders, disks and spheres to be vaguely humanoid. It needs some anatomical modeling using meshes.

David

Your comments are, as always, welcome.

11:12am: Progress?
The latest version of the SPyRE library has been tested against the full set of demo files. I may change the included matrix and vector library out to use the CGKit modules instead, in which I will retest all. When I have tested and passed the stereoscopic module, I will package it all up and upload it. This will be version 0.55.

Pduel is coming along as well. A demo of the pitcher throwing a variety of pitches is done, with interactive control of viewing position, zoom, etc... That will be publicly available soon, too, for those of you who are following. In trying to get the pitcher demo working in stereoscopic mode, I discovered the problem described in the prior post. So that needs to be resolved before I continue.

David

11:06am: PyOpenGL quirkyness
This code sequence was failing on an AssertionException

glMatrixMode(GL_MODELVIEW)
assert(glGetIntegerv(GL_MATRIXMODE) == GL_MODELVIEW)


The value is set _the line before_ the value is tested, and the test fails!!

I was tired last night when this started happening, so I just shut down for the night. I will look at it further later today when I am rested. It is puzzling, though, even to my rested mind this morning.

Any ideas?

David

9:45am: Pitcher's Duel
There has been some progress on Pitcher's Duel, since my return from vacation. The pitcher's model has been converted from a stick figure (absolute coordinates) to a matrix-arithmetic-based solid model. There are a few pieces missing from the solid model, yet, and a few fixes to be made to the Spyre engine before I can release a demo of the pitcher model, but it may be on the website as soon as a week from now.

9:33am: long time
The weekend before Thanksgiving, I went to Boston. During my visit, I went on a park tour of Fenway Park. They were in the midst of a construction project there, adding sprinklers to the field and redoing the whole sod area.

Fenway is definately a hitter's park. The right foul line is the shortest in MLB, at 320 feet (IIRC). That is a little deceptive, as the outfield wall runs from there almost parallel to the foul line. A 320-350 foot homerun would have to be hit very near to the foul pole. The other foul line is fairly short also, ending at the 'green monster'. I thought it was interesting that the 'green monster' is very near the street, and the seats above the green monster are actually cantilevered out over the street; you can drive under them. A close outfield fence, scant foul areas, and a paint job designed to make the pitch easy to see; this is a hitter's park.

After the park redesigned the upper stands, to add a club level and raise the press box, some techie from MIT (across the river) observed that long hits weren't carrying very well. He had some studens, I guess, model the stadium changes, and determined that the additional height was creating a vortex in the outfield pulling hits down, reducing the hit distance a few feet. With its proximity to many educational and research institutions, this may be the most studied ballpark around.

later.

11:01am: www.planetpython.org
Today, this listing of SPyRE appeared on the www.planetpython.org website:
-----------
David Keeney: SPyRE [SPyRE is a lightweight OpenGL graphics engine, written entirely in Python, and derived from zoe by Erik Max Francis. Its primary focus is rapid prototyping and experimentation, so it only supports the barest essentials, with focus on wire frames. Special emphasis is placed on particle systems (where non-interacting particles follow simple rules). SPyRE is zoe converted to use PyGame instead of GLUT.]
-----------

Now, any mention of SPyRE online is good, and the planetpython.org is a very widely read site, so this is a good thing. But I did not write that description, and it is rather outdated. I believe it is excerpted from the SPyRE sourceforge index page, and I need to update that, for more accurate reporting in the future. It now goes beyond wire-framing, and the particle-systems stuff is all inherited from zoe. I suspect most users of OpenGL are interested in solid lighted/shaded surfaces, and SPyRE does support those. There are even demos in the package to show that ability off.

Anyway, badger me if I dont get the documentation updated within the next few days.

David

2:57pm: Baseball
The playoffs have been good baseball. Watching my re-adopted team, the Astros, against the Cardinals has been fun. But while I watch, I cannot avoid comparing the full game with the simulation I am building. In particular, the richness of baserunning is completely missing from PD. So are the spectacular catches, such as Edmunds' over the shoulder catches. There is no way to represent, within Pitcher's Duel, someone like Carlos Beltran, who can intimidate his way into a walk, steal two bases, induce a bad throw and score on the error. PD can represent spectacular batting; after that batter is on base, he is as ordinary as any baserunner.

Thoughts?

2:36pm: Spyre -> Simple Pythonic Rendering Engine
Well, it is about two weeks later than I had hoped, but it is out. The zoePG rendering engine is now called SPyRE. I never understood what 'zoe' meant, exactly, and 'zoePG' meant even less. Now it has an acronymic name.

The current version (0.5) includes lighting, depth cuing, perspective and ortho projections, and an additional interface (pedestrian) that maintains the eye at fixed height above a surface, while supporting keyboard commands to move the eye around the scene. There are additional demos, too, to demonstrate lighting effects.

Just follow the 'My Webpage' link to the website, and then the 'zoePG' or 'spyre' link to the files page.