Topic: 0.3 Revisions

[Agent C]

Revisions Revisions everywhere.

The major task in 0.3 is to rewrite my classes to use Java's LinkedList collection data structure.  I'm using arrays of points and arrays of segments, and that's suboptimal.  I'm also going to attempt to implement OpenGLs display lists for segments, as this may greatly improve performance.  Each point currently has an x,y,z,r,g,b.  I'm going to add x,y,z,pitch,roll,yaw to each segment so that they may be individually moved.  I'll get a performance improvement after the switch to LinkedList over arrays because I can use the .iterator() method on segments when animating instead of for looping through an array.  Here is a summary of the classes as of version 0.3 - comments welcomed

class Laserpoint
  x,y,z,r,g,b

class Lasersegment
  LinkedList Laserpoint
  x,y,z,pitch,roll,yaw,pointcount

class Laserframe
  LinkedList Lasersegment
  pointcount, segmentcount

[James]

LinkedList, huh?

That's going to have some overhead!

Don't you think?

James. 

[Fanny Pack]

I would expect that unless you are needed to do insertions that arrays would be faster.  That's typically how it works... but with Java I am not sure.

The improvements I got from going to GDI to DirectX were insanely good so I would expect that you will see some nice improvements when going to the OpenGL display lists.

Good luck and please report back how the linked lists improve or degrade performance.  As a programmer, I am curious.

[James]

pitch,roll,yaw

That's neat.

I have no idea where you're going with that!

This should be fun. 

James. 

[Agent C]

In my schema the segments can be a complete entity - like a laser sprite if you will.  I want to be able to transform a sprite or an instance of sprite individually with x,y,z transforms and pitch,roll, yaw rotates.  These transforms will happen entirely in the OpenGL hardware if geometry engines exist (which they do on all modern hardware). 

I'm picking the linked list as opposed to array list just based on the documentation that says linked lists perform better when you don't need high performance random access to the collection but instead will use the collection data sequentially.  Everything is currently written with plain ole arrays, so I'll do a little pilot experiment to determine if things work, worse, or if there is no decernable difference.  Your thoughts are well considered, as Java is known to sacrifice true performance for some lofty notion of I don't know what.

BTW, all this OpenGL talk got me thinking about my SGI Octane - it has an ADAT lightpipe connection on it...ponder ponder. :

***

After some more literature searching it appears that until you get up to millions of elements ArrayLists beat LinkedLists no matter what.  Thanks for the tip.

[James]

One thing I would say about a Linked list is that it beats an array for being something that can be taken apart and put back together in a different order; without having to move any of the data, as it sits in the RAM.

When it comes to arrays, you pretty much have to make a new one that is a copy of the information built in a different order.

I use The C++ STL vector class in LaserBoy for all of my "list" needs.

It also has a lot of overhead, but it has been a SUPER powerful tool for me to model my ideas.

I have a color and a 3D-short that come together in a multiple inheritance to become a point. A segment is the inheritance of a vector of <points>. A frame is a segment with some more ideas added to it. A frame set is inherited from a vector of <frames>. A segment can have a palette (by index) or be true color. A palette is a vector of <color>. A vector of <palette> is the palette set. The frame set and the palette set get inherited together into the same class that is pretty much the vector data memory model of LaserBoy, to this is added some application level functions and finally a kind-of GUI wrapper.

James. 

PS. It's pretty awesome to be able to have this level of conversation about laser software development! 

[Agent C]

OK I kicked the idea of ArrayLists for now.  I will let you know if I pick it back up.  Everything is already written in arrays, my arrays are not resized often, and the preliminary tests didn't seem any faster.  GL display lists are in the works.  I rewrote my auto-interpolation code - it was adding laserpoints into segments which got turned into gl points then into appropriate signal voltages.  This was bad for a number of reasons - the main one to me being that if I wanted to change point 10 in a segment, point 10 was no longer the point I thought it was.  I just moved that code to right before the signal voltages are being generated, this way it automagically works on blanking.  I also added a flag for it so it can be turned off during abstract generation when you want the scanners to move in a less controlled way (at your own risk type of thing).  Lastly - segment to segment blanking works!  Pics to follow later tonight.

After GL lists, MIDI, then I start back on the UI and overall program structure.

[James]

You are taking such a different (and original) approach to this whole thing!

You keep throwing ideas out there... like you've been thinking about it for a long time... but it's stuff I would never have associated with any kind of a solution...

I am really looking forward to seeing what you come up with and I'm also really glad that you are here on this forum, sharing your ideas!

James. 

[Agent C]

By the way, we have teapot.
I'll let you know how it translates to laser - my guess is not very well since it's not a perfect silhoutte.