 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've become interested in porting POV-Ray to AmigaOS 3.1+ but I'm a bit
concerned that I'll be either break some legalities or be re-inventing
the wheel because somebody else is doing it. If not, is there any
dissent if I port POV-Ray 3.5 unofficially to the AmigaOS and link this
to my main page?
The following link is not linked off the main site:
http://<broken link>/amiga/povray.shtml
--
Respectfully, "Leave it to the coward to make a religion
Dan P of his cowardice by preaching humility."
- George Bernard Shaw
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'll be either break some legalities or be re-inventing
> the wheel
Probably both would not be a problem, but the best remains
checking povlegal.doc and google :-)
> The following link is not linked off the main site:
> http://<broken link>/amiga/povray.shtml
The status shows you're currently fixing the code to work
with gcc/g++ 3.3. Could you mention precisely what you have/had
to fix ? Since the source code of POV-Ray 3.6 will be released
within a few weeks and that it is know to compile with gcc 3.3.x
and 3.4.0 on various platforms, it'd be worth waiting a bit longer
before tweaking a two-years-old code.
As mentioned on the www.povray.org/beta page, the UNIX
source distribution will be beta-tested, most likely starting this
month. If you are willing to test it, I'd be glad to see what the
reworked build system could give on the AmigaOS :-)
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet wrote:
>> I'll be either break some legalities or be re-inventing the wheel
>
> Probably both would not be a problem, but the best remains
> checking povlegal.doc and google :-)
Absolutely -- didn't seem that anyone else was interested (this scares
me, actually, because AmigaOS 4 is coming out and it looks da bomb) and
povlegal.doc will be my bible for a while (to whom do I pray, though?)
>> The following link is not linked off the main site:
>> http://<broken link>/amiga/povray.shtml
>
> The status shows you're currently fixing the code to work
> with gcc/g++ 3.3. Could you mention precisely what you have/had
> to fix ? Since the source code of POV-Ray 3.6 will be released
> within a few weeks and that it is know to compile with gcc 3.3.x
> and 3.4.0 on various platforms, it'd be worth waiting a bit longer
> before tweaking a two-years-old code.
> As mentioned on the www.povray.org/beta page, the UNIX
> source distribution will be beta-tested, most likely starting this
> month. If you are willing to test it, I'd be glad to see what the
> reworked build system could give on the AmigaOS :-)
> - NC
Instead of messing around with the configure, I just started to build
the Makefile from scratch (I wanted to understand how the files
interrelated and, as a way to do that, I rolled up my sleeves and dug
into the code -- sometimes I'm not lazy enough, maybe, for my own good).
I didn't realize that it was made for gcc (actually, I should have; I
was thinking, when I was driving home salivating about getting to work
on it, that the "configure" script should have been a clue). I was also
compiling with g++, not gcc; didn't even think to change that, if that
was what was up.
Aside from a lot of warnings that arose because of implicit casting from
a double to a long or int (which I resolved using (int) floor() just
because I'm very, very strict about treating warnings as errors) I found
that, in the file "povmsgid.cpp", the enumerations were assigned to
static strings surrounded by single quotes, which is something I have
never seen before -- first, I thought enums had to assign to ints, and
second, I thought single quotes were for characters, not strings). The
compiler agreed on both counts and gave me quite a lashing about
what-for about it. So, I created a PERL script to grab each of those
strings and generate a file with defines called "povtypes.h" and made
those defines with unique IDs starting from 1000. Then, I went to
"povmsgid.cpp" and got rid of those double-quotes and dealt with the
strings like '****' by making it 'AAAA' and 'NULL' by making it 'NuLL'.
When that compiled, I started tracing the include hierarchy and building
the Makefile. Sore fingers later, and a lot of clean-compiles and
thank-Gods later, I still waswondering what the "goal" of those defines
was and if there is something fundamental that I'm missing about the
whole affair that is going to bite me in the cheeks later.
So, it looks like, from what you are saying, I should just unpack the
thing and enter in the goodies to make the configure script work
properly with an AmigaOS entry. Probably the best thing to do, but my
goal was just on getting it to work first and dig in and understand it
and then prettify later and stress-test it with the provided test suite.
After it is running on command-line, it just seems silly not to start
building a GUI around it, like Windows or Mac has. I mean, this /is/
that Amiga after all.
Here's a screen-shot of my directory listing so far:
http://<broken link>/images/amipovfiles.jpg
Since, aside from those warnings, that really seems to be the only thing
it complained about, would someone venture to clue-me-in on what happens
with povmsgid.cpp? Is there some program in-between that turns those
happy 'strings' into numbers?
I'm really excited -- 3.5 on the Amiga will do great things for the
Amiga and excite a lot of new POV-Ray users. I just want to make sure
I'm Kosher in this pickle. In fact, I'm willing to put in the effort to
coordinate an official version with you guys if you think I'm sane
enough to help with it. I dream of seeing povray.programming.amiga happen...
--
Respectfully, "Leave it to the coward to make a religion
Dan P of his cowardice by preaching humility."
- George Bernard Shaw
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Nicolas Calimet wrote:
<snip />
>> The status shows you're currently fixing the code to work
>> with gcc/g++ 3.3. Could you mention precisely what you have/had
>> to fix ? Since the source code of POV-Ray 3.6 will be released
At first, I thought to think myself an idiot, but then I thought and
thought and realize -- it wasn't obvious and I was lucky to figure it
out. When I ran "sh configure", it failed because it couldn't find a
"/tmp" directory. It occurred to me how the AmigaOS uses the assign
command and did this:
mkdir tmp
assign tmp: tmp
sh configure
It is configuring now rather happily. g++ is notoriously slow on the
Amiga, so I'm going to let it run for a while. That's not the fault of
the Amiga but, instead, the build for the OS. The emulator I'm running
is running full-speed and runs many programs faster than Windows XP. I
have an Amiga 3000T coming soon to do testing on a real Amiga.
Pending compile...
--
Respectfully, "Leave it to the coward to make a religion
Dan P of his cowardice by preaching humility."
- George Bernard Shaw
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P wrote:
> <snip />
> It is configuring now rather happily. g++ is notoriously slow on the
> Amiga, so I'm going to let it run for a while. That's not the fault of
> the Amiga but, instead, the build for the OS. The emulator I'm running
> is running full-speed and runs many programs faster than Windows XP. I
> have an Amiga 3000T coming soon to do testing on a real Amiga.
>
> Pending compile...
So far so good. Now I have to compile all those "POV-Ray Absolutely
Needs these Libraries" libraries. I have a good feeling about this...
--
Respectfully, "Leave it to the coward to make a religion
Dan P of his cowardice by preaching humility."
- George Bernard Shaw
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P wrote:
> Dan P wrote:
>
>> <snip />
>
>
>> It is configuring now rather happily. g++ is notoriously slow on the
>> Amiga, so I'm going to let it run for a while. That's not the fault of
>> the Amiga but, instead, the build for the OS. The emulator I'm running
>> is running full-speed and runs many programs faster than Windows XP. I
>> have an Amiga 3000T coming soon to do testing on a real Amiga.
>>
>> Pending compile...
>
>
> So far so good. Now I have to compile all those "POV-Ray Absolutely
> Needs these Libraries" libraries. I have a good feeling about this...
Installed libjpeg6b -- successful
Still requires tiffio.h -- the documentation does not note that this is
a required library. I'll download it, but this is something you might
want to note in the README.
Using tiff library from http://www.libtiff.org/build.html#Other
--
Respectfully, "Leave it to the coward to make a religion
Dan P of his cowardice by preaching humility."
- George Bernard Shaw
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Milestone! After porting libtiff to the Amiga (I'm thinking of
contributing it to Geek Gadgets) and removing the version number from
the output for the PNG library (must have an old library that did not
include the function -- will look into it) and setting the define to say
that there is no X Display (this isn't X-Windows!), I've managed to
successfully compile and install POV-Ray 3.5 on the Amiga! I have yet to
run the tests, but this m68k executable should work. When I get my
3000T, I'll make sure to run tests on a native platform.
Next step: Make an icon, have it spawn a shell that lets the user just
type 'povray' without having to do any special setup, package the proper
files using lharc, and link it to the web-site. Then, I'm ambitious
enough to learn programming Intuition to port over the interface from
Windows/Mac to the platform. Seems like it is a great way to learn it
since it is really just a text editor with some special menus and a
window display that captures the output and displays it progressively.
If an when I get to a point where you are thinking me serious enough to
do an official distribution, know in advance that I'm willing to do what
it takes to bring POV-Ray 3.5 officially to the Amiga. I have a dream:
to see povray.programming.amiga be a newsgroup where the ten or so
people who use it find a home :-) With the other effort, AmiZilla, Amiga
just might come back. It should. It is the operating system we all
actually want today. I'm going to bet the last Amiga team said something
similar.
Here is the latest screenshot:
http://<broken link>/images/amipovray2.gif
I haven't actually compiled a scene yet (I'm so excited to get to this
point!) There are lots of warnings in the code, so I'm a little worried
about some of it. I'll feel a lot better when it passes all the tests.
PS: I used the actual 'configure' script to compile this, so yes:
gcc/g++ works! There were minor Amiga-specific tweaks I had to made, but
nothing that a more seasoned Amiga programmer would even notice.
--
Respectfully, "Leave it to the coward to make a religion
Dan P of his cowardice by preaching humility."
- George Bernard Shaw
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bah. It looks like it is trying to free an invalid memory block on my
test file. It could be a bug in the linked ixemul library, but
intuitively, I doubt it. Looks like I have some tracing to do. That's
okay; things that are easy aren't worth doing. If there is anything this
effort may yield to the team, it is at least a different perspective on
the code that might help make it more stable.
Screenshot:
http://<broken link>/images/amipovray3.gif
Those warnings bug me, so I'm going to fix them. As a rule, I use
floor() and cast it to an int when I'm going from a double to an
integer. I think that is the default behavior anyway so I'm going to add
the necessary code to make it compile cleanly (at least, on this platform).
--
Respectfully, "Leave it to the coward to make a religion
Dan P of his cowardice by preaching humility."
- George Bernard Shaw
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40bebe43$1@news.povray.org> , Dan P <dan### [at] yahoo com>
wrote:
> Those warnings bug me, so I'm going to fix them. As a rule, I use
> floor() and cast it to an int when I'm going from a double to an
> integer. I think that is the default behavior anyway so I'm going to add
> the necessary code to make it compile cleanly (at least, on this platform).
Argh! Don't do something like that, it is plain wrong! If you compiler
issues nonsensical warnings, the right thing to do is to disable them, not
to destroy your source code!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40B### [at] yahoocom> , Dan P <dan### [at] yahoocom>
wrote:
> Aside from a lot of warnings that arose because of implicit casting from
> a double to a long or int (which I resolved using (int) floor() just
> because I'm very, very strict about treating warnings as errors)
You should really learn to know the difference between a warning and an
error. A warning is not an error and as such, it is very likely the machine
informing you about something possibly unintentional is wrong.
> I found
> that, in the file "povmsgid.cpp", the enumerations were assigned to
> static strings surrounded by single quotes, which is something I have
> never seen before --
Get a book about C or C++ programming...
> first, I thought enums had to assign to ints, and
> second, I thought single quotes were for characters, not strings). The
> compiler agreed on both counts and gave me quite a lashing about
> what-for about it. So, I created a PERL script to grab each of those
> strings and generate a file with defines called "povtypes.h" and made
> those defines with unique IDs starting from 1000. Then, I went to
> "povmsgid.cpp" and got rid of those double-quotes and dealt with the
> strings like '****' by making it 'AAAA' and 'NULL' by making it 'NuLL'.
> When that compiled, I started tracing the include hierarchy and building
> the Makefile. Sore fingers later, and a lot of clean-compiles and
> thank-Gods later, I still waswondering what the "goal" of those defines
> was and if there is something fundamental that I'm missing about the
> whole affair that is going to bite me in the cheeks later.
Argh - lkjxfsliaejkisddjhfsuikufdfkljhfkljapsdauojsdl - my brain hurts when
I even read about somebody doing pure nonsense this!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
