#VP3.04b and DCTV
6 messages in this thread
Clint,
Can you help me with a problem that I defies my abilities to figure when
outputting DCTV format files from VistaPro 3.04b. I've been using DCTV for a
couple of months now and I keep running into what seems to be an erratic bug
when I try to save DCTV images from VP. Often but not alwys the pallet used by
VP is changed during the save producing a mottled but unusable image when I try
to load into another program. The View image displays perfectly on my composit
monitor, and If I use a screen grabber I am able to obtain a usable file.
However I am limited when trying to run a script to obtain animation images for
DCTV. The only work around that I have been abel to discover for script work
is to save DCTV images in IFF24, but then the whole advantage of small fast
anims is lost. To bedevil me even more I have a 200 frame DCTV animation
produced by a script file in VP that displays perfectly. I have tried every
conbination of resolution, bit depth,image size, etc., that I can think of in
the graphics panel (always HIRES). What am I missing here?
I am running this on an
A2000/'030+882FPU-CSADerringer33mhz8MB/2MBchip/4MB16bitFAST/ECS.
Any advice you can send my way would be greatly appreciated.
Kapryan Kennedy Wandering in the Wilderness
On Autopilot
Kapryan:
The save_iff code doesn't make any distinction for dctv, it just saves as
many planes as the image has. One possibility is that the save_iff code does
pad lines out to even byte values after compression, but this is per IFF spec.
Other than that, the image which is saved is exactly that which is displayed.
Unfortunately, I can't do much in the way of experimenting at the moment, for
several reasons. VP 3.05 (last released version, identical to 3.04b except that
the 'b' was the designator for 'beta' and VRLI got antsy and released it before
I had all of my reports back in. It turned out that there were no more problems
reported, so the rev was bumped to 3.05 for the release.) was written in Manx C
and when I put AmigaDOS 2.1 on my 3000, the Manx C compiler quit working. I
have ported it to SAS, but it is currently in an intermediate state as I am
making the changes/additions for 3.1 so it's not exactly usable right now. (One
of the changes is to use the ASL graphics mode requester in place of portions
of the GrMode requester, so DCTV doesn't even show up as an option at the
moment.) When I get it further along, I'll be glad to send you a beta copy and
we can tweak it until it works right for you, but that may be a month or more
away.
Clint <Chaocity>
Clint,
<The save_iff code doesn't make any distinction for dctv, it just saves as many
planes as the image has. One possibility is that the save_iff code does pad
lines out to even byte values after compression, but this is per IFF spec.> I'm
no technical expert on IFF format but my understanding was that most programs
would treat DCTV files as though they were just hi-res IFF files. That's why
I'm wondering why something is getting lost or changed. One thing I did notice
about this problem I'm having with saved DCTV images is that the actual pallet
of the image, as displayed on my RGB monitor( after reloading into another
program), actually looks different from the color pallet rendered to the RGB
VIEW screen when VP initially works its magic. Instead of being the "mottled
grey-green" they look more like a mottled "beige-brown". Does that help?
BTW, I've been having alot of fun with VP since I upgraded to 3.04b,
installed a CSA '030 derringer in my trusty old A2000, and then hooked up DCTV.
This is a great combination. I hope you always support the DCTV format. Even
though it's not hi-tech and pricey, it's the most economical path to fast
colorful animation that I know of.
<I'll be glad to send you a beta copy and we can tweak it until it works right
for you, but that may be a month or more away.>
Please do. I'd love to work with you on this.
Kapryan Kennedy Wandering in the Wilderness
On Autopilot
Kapryan:
Looking at the code, just about everything with the display is done inside
of DCTV library routines provided by the manufacturer. The image which gets
saved to iff is basically what a bunch of calls to DCTVCvtLine() return and the
colormap is what is in the dctv structure. Unfortunately, I never had much in
the way of documentation, so I made my best guesses and left it to my beta
testers to tell me if I had it right.
I will continue to experiment (I have a couple of ideas of things to try)
and will let you test them out when I have something ready. I don't intend to
drop support for any of the video modes that VistaPro has. I just want to
refine them a bit to make sure everything works on as many machines as
possible.
Clint <Chaocity>
Clint,
Thanks for looking into this for me. I will continue to fiddle with what I
have to see if I can isolate the problem. I'll let you know if I do. I suspect
that I may have some sort of hardware/software multitasking problem.
Glad to hear that you will continue to support DCTV. I'm curious to see
some of the improvements that are planned. Suggestion: How about a panel to
generate forground rocks and boulders or even some random gravel in a manner
simular to TREES and GRASS?
Thanks again.
Kapryan Kennedy Wandering in the Wilderness
On Autopilot
Kapryan:
The Fractal Dimension sort of governs the roughness of close up landscape.
I will be experimenting with better grass and the possibility of rock-like
objects while working on 4.0. 3.1 addresses the major complaints about the
graphics panel and the ASL requester with a few additions like reflective
water. 4.0 will have more major changes in it, some of which look awesome in
John's early tests.
Clint <Chaocity>