Topic: It's about freakin' time !!!

[James]

grumble grumble grumble....

The good news is that it apears that the 24 bit dxf file is being written properly. It's just not being read back in the right way.

James. 

[James]

I fixed it. 

James. 

[James]

If you need me, I'll be in the bath tub. 

James. 

[meandean]

  Well, at least you're getting feedback... I also noticed that if you save a frame set to a dxf subdirectory, the files have no extension.
 
  Not to open a can of worms , but what (if any) third party dxf viewer are you using to verify interoperability of LB files (palette or 24bit)? I downloaded a couple of freeware CAD viewers, one called eDrawings by Solid Works; it properly loads the sample dxf files that come with LB- menu_keys, view_keys, they open OK, but LB generated stuff comes up black, and I get mixed results with other programs such as Paint Shop Pro.

[James]

Well, I fixed what I could find.

http://akrobiz.com/laserboy/code/LaserBoy_2009_07_08.zip

I think it's all done now. Yep. It's perfect.

(Yeah right!) 

James. 

[James]

Nope.

My plan is to represent the data; the whole data; and nothing but the data.

I'm not even using commas.

I'm thinking about only reading the first letter of the words

frame
palette
table

to know what must come next on that same line and how to interpret the numerical values that will follow it.

a frame can be 2D or 3D; rgb, table or palette; short, unit or real.

a palette or a table is currently stored in rgb; which is the token for three separate unsigned char. Since there is no "blanking bit" in this format, the literal -1 is stored when a point is blank.

In the future I want to add the hex format that would store colors as 0xRRGGBB; a single, 24 bit hexadecimal number. Again, I would use the literal -1 to designate a blank vertex.

A palette can also have a name; this would be the last token on the line. Only 8 characters will be read. This will be matched with the named palette set loaded in LaserBoy.

LaserBoy will be able to read more text variation that it will write. It can write short and unit. It will also read real; the universe at any size.

James. 

CORRECTION:

A frame can be xy or xyz; rgb, table or palette; short, unit or real.

It's a bad idea to use any numbers in word tags; espesially as the leading character!

James. 

[BlinkenLights]

my favorite numbers are lower case79 and capitol 23

[James]

Note to Dean:

There is no difference in the dxf output between a 2D and a 3D frame!

If a frame is 2D, all of the z coordinate information is written as 0.00.

James. 

[meandean]

  More confusion... When rendering IN.ild to dxf, most frames appear entirely screwed up in Paint Shop Pro 4, yet spot checks of imported plots from LaserWave (2 & 3D) to dxf looked OK.

[James]

Freaky. 

On another note, I've just cleaned up a bunch of dumb junk!

The txt reader still isn't quite working, but its development has exposed some structural issues that have been wrong since the beginning of time! 

UPDATE:

Still not working! 

........... but I've got a picture now! 

James. 

[BlinkenLights]

guess your finally figurng it out and making progress eh...

[James]

I figured out all of the ifstream reading stuff.

I can now read full color frames in from txt.

The next thing to do is read in palettes and tables and relate them to the appropriate frames.

I am a lot more satisfied about sorting out a bunch of old, outdated ideas and getting a better grip on some file IO issues.

Once I get this fixed up I am going to rewrite all the wave file IO.

I think I'm starting to get the hang of this "C++" thing. 

James. 

[James]

It's still not done, but things are coming together quite nicely.

It's amazing how much I have learned about getting file IO perfect, when I can actually read (in plain text) the files that I am reading and writing!

There are a lot of nice features about ASCII text files that you don't get with pure binary.

The first, most obvious thing is that they are human readable and writable in a plain text editor!

But other advantages include the fact that the position of individual datum is not absolute from the beginning of the file. It is relative to the last datum and it is delimited by one or more spaces.

So,

a line containing {x y z r g b}

is just as valid as

a line containing {x            y  z          r               g b}

The only stipulation is that all datum of an individual record must be on the same line of text.

Not only does this reduce the risk of errors due to improper, absolute information position, but it also adds the stopgap of "resetting" the data reader to the beginning of a new record for every new line of text AND knowing to ignore extra junk at the end of each line.

Another interesting advantage is that only a handful of different ASCII characters (the digits, [space], [newline], +, -, ., and some lower case letters) are in use! This means that it will zip very effectively.

Once LaserBoy can read and write color laser vector art in plain ASCII text, it will be trivial for even beginner programmers to write simple applications to generate frames! They won't need to do anything more than print out a table of numbers! It could even be done in an Excel spread sheet with macros!

This should make the creation of abstract (math generated) frames much more accessible to laser artists.

Wouldn't it be nice to see laserists trading formulae for color frames instead of the raw, calculated data?

If this format is examined and accepted into use by the greater laserist community, it could be one of the more important developments to come along in a few years.

At the very least, you will finally be able to actually see the data with your own human eyes and brain!

James. 

[BlinkenLights]

um.. what?

[Fanny Pack]

I think you missed the XML train.