 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfr de> wrote:
> I feel a bit queasy about the syntax though, it doesn't
> look right for SDL (or most other languages I know).
I guess that's mainly because it is an unconventional approach.
> #writeb(fOut, "int16be", someVal1, someVal2)
>
> -> my favourite
Not mine, because it would have introduced a whole different branch for the
parser.
> #write(fOut, "int16be", someVal1, someVal2)
That's plain crap, and I guess you know that ;)
> #writeb(fOut, "%hu%hu", someVal1, someVal2) or
Ugly to parse.
> #write(fOut, (int16be) someVal1, (int16be) someVal2)
>
> -> with active suspension of disbelief you can pretend
> it's a cast to select from overloaded #write's ;)
Why the hassle of adding the parentheses? It would happen to make parsing quite
cumbersome, at no real benefit - aside from looking more like Java or the like.
*This* is something that would go against all conventions of SDL: There is not a
single keyword anywhere else that needs to be enclosed in parentheses.
Lining up keywords separated only by spaces is not uncommon for POV.
So, what's the benefit of any of those proposals?
I can name one benefit of the (unparenthesized) prefix approach I went for: It
was darn easy to integrate. No hassle with additional state variables. No
duplication of huge code blocks.
And I think it's as good as any other approach, regarding usability.
I think all your proposals are tinted by the way other languages do it. But POV
SDL is POV SDL and nothing else.
> Also, maybe it should be uint instead of int in case
> you wish to add signed integers later?
Happened already.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
>
> The 3.7 being as it is, I think a 3.6.2 would be obsolete even before it sees
> the light of day.
>
Ah, but would it have been obsolete say, two years ago? :-) (I think 3.7 was
still in it's beta stage back then?) But all is well, of course. And I do
understand the reality of the time constraints that the POV-team volunteers
have. No squawking from my end; I *greatly* appreciate the efforts that have
been put into 3.7.
As Thomas says, that's life...
Looking forward to your DF3 integration!
Hey, while you're at it...
How about native import for DXF and OBJ files? Maybe???? (That would be on my
own wish-list.) I figure it shouldn't take you more than a couple of days...
;-)
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> Looking forward to your DF3 integration!
Hey, for now it's just writing binary data, which *can* be used to generate
DF3...
> How about native import for DXF and OBJ files? Maybe???? (That would be on my
> own wish-list.) I figure it shouldn't take you more than a couple of days...
> ;-)
Should be darn simple indeed (as far as OBJ goes), as long as it enforces
certain constraints (e.g. triangles only, or braindead automatic
triangulation). After all, the structure is strikingly close to the mesh2
object.
As a matter of fact, it's on my own wish-list as well.
Still, there are a few things to put some brains into:
- What SDL syntax?
- How do you handle materials?
- How about groups?
And then, someone would have to implement the whole smash... someone not
currently busy with radiosity speed and subsurface scattering, ideally... ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It would be easy enough to fit binary file access into the current SDL
>> framework.
>>
>> FOPEN_DIRECTIVE:
>> #fopen IDENTIFIER "filename" OPEN_TYPE [FILE_MODE]
>> OPEN_TYPE:
>> read | write | append
>> FILE_MODE
>> standard | binary
>
> That alone wouldn't quite do the job: How is POV to know whether to write
> a
> particular value as a byte, 16-bit or 32-bit integer?
>
> So when invoking #write, the parameters would have to be marked
> accordingly
> anyway; and in that case the FILE_MODE isn't required at all.
Obviously the standard for binary files is 8 bit bytes.
POV supports encoding and decoding byte values with the
chr(N) and asc(S) functions in ASCII mode.
You can already write byte values as #write(handle,chr(N)).
In binary mode undeclared_identifiers and strings in a #read could just be
treated as 1 byte string chars instead of trying to determine the type from
the
file content, or trying to find enclosing quotes. Float and vector handling
could be left as-is, or produce a warning.
There is no handling for integer types in POV SDL, everything is really a
float,
or a string. Still, it might be fun to read in some ASCII art text file and
try to
render something based on it, or other such stuff. In particular it's a
bummer
having a big CSV file where the strings aren't enclosed in quotes, or some
other "defect". It would be nice to be able to directly use such stuff in
POV.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> schreef in bericht
news:web.49ca59866dca0b64c1f399840@news.povray.org...
>
> The 3.7 being as it is, I think a 3.6.2 would be obsolete even before it
> sees
> the light of day.
>
Yes, as things are developing now (with a deep bow to you) 3.6 is only
worthwhile for the Megapov things.
How are ideas, by the way, to integrate *those* into 3.7?
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Attwood wrote:
> FOPEN_DIRECTIVE:
> #fopen IDENTIFIER "filename" OPEN_TYPE [FILE_MODE]
> OPEN_TYPE:
> read | write | append
> FILE_MODE
> standard | binary
This I like hugely.
Clipka wrote:
> That alone wouldn't quite do the job: How is POV to know whether to write
> a particular value as a byte, 16-bit or 32-bit integer?
Personally I think it's far cleaner to just be able to write raw bytes (in an
8bit clean stream), and not support 16 or 32 bit values. Once you have raw
bytes, you can trivially write a macro to write big endian 16 bit values. Or
little endian. Or 64 bit values. Or anything.
Tim Attwood wrote:
> Obviously the standard for binary files is 8 bit bytes.
>
> POV supports encoding and decoding byte values with the
> chr(N) and asc(S) functions in ASCII mode.
>
> You can already write byte values as #write(handle,chr(N)).
And this seems like the perfect way to write bytes to a binary stream.
Doesn't work on the Mac OS X beta of 3.7 now - NULLs get swallowed, and anything
over 0x7f gets written as a space. And the global_settings{ charset ... }
directive doesn't really seem to do much in this version either.
So my ideal solution would be to add the "binary" flag to a file open command,
and then fix write( ..., chr() ) to actually write bytes cleanly. I could write
a DF3 file once that was done with ease.
But I'm not doing the work, so I'll gratefully accept whatever actually gets
done. :-)
Cheers,
Edouard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > The 3.7 being as it is, I think a 3.6.2 would be obsolete even before it
> > sees the light of day.
>
> Yes, as things are developing now (with a deep bow to you) 3.6 is only
> worthwhile for the Megapov things.
>
> How are ideas, by the way, to integrate *those* into 3.7?
The only thing in Megapov I can't do without is the AOI pattern.
Oh, and "no_radiosity". Umm, and bicubic Interpolation is nice. And glows.
Uhhhh, and the user_defined camera.
But mainly AOI.
Cheers,
Edouard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> POV supports encoding and decoding byte values with the
> chr(N) and asc(S) functions in ASCII mode.
It does indeed, but...
> You can already write byte values as #write(handle,chr(N)).
.... no, you can't. Not reliably, that is. Ever tried? There's no way to get POV
to #write a 0x00. Or a 0x0D on windows machines. Or any value > 0x7F, as it
seems.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> Yes, as things are developing now (with a deep bow to you) 3.6 is only
> worthwhile for the Megapov things.
>
> How are ideas, by the way, to integrate *those* into 3.7?
How are ideas, by the way, to develop a 3.7-based Megapov version?
I guess the main point is that Megapov currently is a collection of 3.6 patches.
To integrate them into 3.7 requires a rewrite, so it's not just a copy-and-paste
job.
Maybe that is why, of all things, HDR images was one of the first Megapov
features to find its way into 3.7 POV: It's mostly about reading & writing an
image file format, which is, so to speak, "located comparatively far from 3.7
architectural changes": Image file handling has traditionally been done via
libraries, and POV 3.7 didn't modify those.
Other things, like the mechanics sim, are probably beyond POV ambitions ("Damn
it Jim, I'm a renderer, not a physics simulaition!").
The two things that would be ranking highest on my personal
to-be-integrated-in-3.7 list are probably the "#set" directive and the aoi
pattern.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Edouard" <pov### [at] edouardinfo> wrote:
> The only thing in Megapov I can't do without is the AOI pattern.
Yeah, that's really a gap in POV.
> Oh, and "no_radiosity".
Parts of the necessary code already exist in POV 3.7, so intention to integrate
it must have been there. Unfinished work though (started by someone else, not
me).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
