Subject:
|
Re: Ldglite must be faster
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 5 Sep 2002 16:32:34 GMT
|
Viewed:
|
1028 times
|
| |
|
|
In lugnet.cad, Anders Isaksson wrote:
> "Steve Bliss" <partsref@yahoo.com> skrev i meddelandet
> news:s5q9nuc5pr24nbvmrsvitiffojjuu1r2up@4ax.com...
> > In lugnet.cad, Anders Isaksson wrote:
> >
> > > Another (Windows) wish: I would very much like to see a .dll (with some
> > > standardized interface) implementing LDRAW rendering on a supplied dc - • then
> > > it would be sooo easy to build all those little helper programs, adding
> > > functionality around the basic rendering engine.
> >
> > Yah, I second this. I've wanted one of these for years. Even better
> > (for me) would be an ActiveX custom control. I *think* one DLL could
> > support both approaches.
>
> Just fix a DLL and it can be embedded into an ActiveX for anyone who thinks
> he really needs it... (An ActiveX control is just a DLL with a standardized
> (slow) interface).
An ActiveX control would be very useful for "all those little helper
programs", where the programmer really doesn't want to worry about all
the standard Windows grunge. Especially if the ActiveX control could
add value over a disconnected dll/dc rendering setup (such as adding a
"PartDrop" event to allow the programmer to respond to parts being
WM_COPYDATA'ed onto the control). But basically, it's a different
mindset.
Getting a DLL going first would be good; an ActiveX could be developed
later, perhaps.
> Or, for that matter, it could be a separate process (LDRAW Graphics Server),
> which might be easier to port to other systems. Then I can send WM_COPYDATA
> messages to it :-))
Hmm, I think you just exceeded my knowledge level. How would that work?
That is, how would having a separate process empower handling
WM_COPYDATA messages? By "separate process", do you mean making a COM
object? For VB use, that would nearly be as good as an ActiveX control.
And probably more useful, in general.
Getting a bit more specific, it seems like the most basic, and perhaps
only, call to a DLL would be to render some LDraw code. Something like:
RenderLDraw(hDC, sLDrawCode, sWorkDir)
Where:
hDC is your average everyday device context (it's been awhile since I
played with this stuff - you mentioned dc, I'm assuming device
context is the best handle to pass off)
sLDrawCode is string (of whatever flavor) containing a bit of LDraw
command code
sWorkDir is the working directory (used to search for files).
This interface reduces the number of parameters while retaining (or all)
of the rendering control (color, position, view angle, scale). It also
gives the calling program the ability to easily render either a file
(pass "1 <color> <position> <viewpoint> <file>" as sLDrawCode) or code
that only exists in memory.
To render step-by-step, I think we'd want a different interface, one or
two calls like:
RenderFirstStep(hDC, sLDrawCode, sWorkDir)
RenderNextStep(hDC)
Where either RenderFirstStep would return a handle to be used for future
calls to RenderNextStep, or both functions would return a value to
indicate either more steps remain or rendering is complete.
If the function of RenderFirstStep and RenderNextStep could be
rationally combined into a single RenderLDrawStep function, that would
be good. :)
My final thought is that it would be good if the DLL could produce one
or more structures populated with the heightmap and/or the ... ummm ...
part-map(?).
A 'part-map' would be a record of which part (actually, source line from
the sLDrawCode parameter) is rendered at each pixel. This could be used
for hit-testing, to allow the client program to support (some) mouse
interaction.
Part-maps and heightmaps could be written to additional DC's, or
returned in some other manner...
This could be done by adding parameters to the RenderLDraw() function,
or providing a separate function/interface with the additional
parameters.
Steve
|
|
Message has 2 Replies:
 | | Re: Ldglite must be faster
|
| "Steve Bliss" <partsref@yahoo.com> skrev i meddelandet news:utvenuov1aga5rp...4ax.com... (...) Server), (...) WM_COPYDATA (...) It shouldn't use WM_COPYDATA, that was just a joke. No, I meant: Just another program which gets commands through Windows (...) (22 years ago, 5-Sep-02, to lugnet.cad)
| | | Ldraw DLL - Was: Ldglite must be faster
|
| (...) I'm not sure why, but this popped into my head last night. I think perhaps it may not be all that hard to do. The basic ingredients are already there in the winOffScreenStart() function of ldglite. I'd just have to convert it to use the hDC (...) (22 years ago, 1-Oct-02, to lugnet.cad)
|
Message is in Reply To:
| | Re: Ldglite must be faster
|
| "Steve Bliss" <partsref@yahoo.com> skrev i meddelandet news:s5q9nuc5pr24nbv...4ax.com... (...) then (...) Just fix a DLL and it can be embedded into an ActiveX for anyone who thinks he really needs it... (An ActiveX control is just a DLL with a (...) (22 years ago, 3-Sep-02, to lugnet.cad)
|
39 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
