Great minds think alike.

TIL that this guy had proposed an object oriented extension to Forth that almost mirrors the one I designed for Tengoku.  In 1996.  That's 15 years ago now. :)  Anyway it's so close it mirrors some of the semantics - Field , Method , and even { and } (which are sort of being phased out and replaced though by As , With , and the > prefix).

Link to the proposal document:
http://www.forth.org/literature/oopf.html

Also, I just found and will purchase this book: Object-Oriented Forth.  Published in 1987!

http://search.barnesandnoble.com/books/product.aspx?r=1&r=1&IF=N&ISBN=0125635702&cm_mmc=Goodreads-_-k117601-_-j12871747k117601-_-Primary

On the coding front, I cleaned up the source code, and thinking I should probably do a little more.  Going through the hedges with the clippers.  :)  Maybe a bit like Edward Scissorhands.  :)  It's really satisfying.  Besides making it nice and pretty and clean, helps put the different components in perspective.

There is a lot of code and so much of it still shows residual signs of the confused, disorganized thinking process I was going through just to figure out what low level services worked well.  I wish I had known at the beginning what I've accumulated through the process, but that's sort of a self contradicting statement.

I've got a pretty nice set of reliable services now, but there is just such a multitude of more stuff I want to do.  Really made me realize how much progress has been made and continues to be made in the "Outside World".  I'm playing a weird game of catchup.  I want power, but I don't trust the tools that are available.  Maybe now is time to stop "fortifying" for a moment and adopt a new groove of finishing products that add a few new features at a time.

The shmup performs pretty well on an aging 2005 lappy.  3000+ colliding bullets at 60hz with plenty of CPU to spare.  Slowdown doesn't really impact smoothness much anyway though thanks to fixed timestep.  It's implemented using a special module, the BulletMngr, that brings together a Spritebatch and a Collisiongrid and some other things but doesn't use entities because those are too slow for that many moving things.  The majority of the time is spent drawing the bullets.  A clever sprite-generating vertex shader would virtually eliminate any limit on sprite count.  I like having the ability to have tons of sprites.  The game isn't going to expect you to actually dodge 3000 though, exactly. :)

Really annoyed at the laptop though.  It says it supports fragment (pixel) shaders but it actually doesn't!  Witnessed this with 3dMark '06 and firsthand saw the driver spit back "can't link fragment shader" / "fragment shader not supported by HW" etc.   So I can't develop post effects on it. :( The desktop works great though.

Actually, on the shader front, I think I did something that was really cool the other day - I implemented a floating-point framebuffer and an HDR shader that dithers the output, so you eliminate banding and can fake really, really subtle color degradations, especially in the lower luminance levels.  It was very gratifying because here I've got the full spectrum of fidelity - I can do 8-bit pixely sprites (the default texture filtering is GL_NEAREST :) or I can render really smooth, anti-aliased geometry or bitmaps and do extremely smooth post effects with perceptually infinite color range.  Isn't that nice?  I think so.
 
Kind of afraid to just jump in and play with the engine still - it has trained me to think it could break at any moment - I think I'd rather work on the game idea so there is less unknown when I sit down to "implement" (in Forth implementing is ALWAYS experimentation though, ain't that nice ;).  Inevitably I will want to redesign some feature or two or three to suit the game.  But I think I've coded things in a modular enough way (hence putting almost everything, literally, in "modules") that I won't be running back to the starting line, and I have lots of reusable pieces that I really like as they are.