Posted by Yuri Zhivago on March 13, 2000 at 21:08:40:
In reply to: TRueView suggestions posted by Eepē on March 12, 2000 at 23:59:40:
> First, do you have an email address I can contact you through, Yuri? Having
> to use this forum for this is annoying.
Sorry. If you saw my domain name you might understand my reluctance to
give out my e-mail address. I have no problem communicating through this
forum; that way, everyone can benefit from our discussions.
> Anyway, I have some suggestions for moving around that I think would make it
> easier. These are based off Active World's and use page up/down to look
> up/down (tilt cam) and numberpad +/- keys to move up/down. Next/previous room
> keys can be mapped to [ and ] to compensate.
"Easier" is relative to one's experience. You would like a user interface
that is closer to one with which you are already familiar. Being unfamiliar
with Active Worlds myself, I find the TRueView interface to be quite functional.
Perhaps someone else might be interested in "improving" the user interface -
I'm certainly not saying that this is the best UI ever. And please don't think
I'm blowing you off - I don't see TRueView as a "product" that will have many
versions that get released. It is a tool, a stepping-stone to a full-blown
editor. There is quite a bit of code that I pulled out before releasing it,
because that code was both ugly and imperfect; however, be aware that another
iteration of TRueView (TRueEdit) can select surfaces, modify their textures,
modify their height, etc. I also have another tool that is not quite ready
for "prime time," that being TRueMesh, which allows you to look at individual
meshes, Moveables, and Items, including all of their animations, played once
or continuously, viewed from any angle or distance. Because I think that
finishing these tools will help further the progress toward a real level
editor, I am reluctant to spend time on TRueView, fixing bugs or "improving"
the code. I released the source code so that others can do this sort of thing.
I'm busily working on other tools.
By the way, (this is probably not the message to put this into, but) for
those of you who are interested in the FloorData, TRueView's level dump
function ($) not only dumps all the level data, it parses the FloorData for
you as well. The FloorData parser works fine on TR1 and TR2, but doesn't
have all of the TR3 extensions, and doesn't really address TR4 specifically
at all. Just an FYI (that should probably be in a note of its own, along
with the other things I forgot to mention in the ReadMe file).
> Also, being able to hold multiple direction keys down (like for moving
> diagonally and up at the same time) would be more convienent than having to
> only go one direction at a time and having to lift one's finger off of and
> repress a new direction key to get moving again.
I agree in principle. Aside from the reasons I list above, there is another
reason that this particular request will not be fulfilled by me - I am trying
to write this code to be portable, so that MacOS users (and, potentially,
Linux or BeOS or ??? users) might stand a chance of being able to port the code
to their platform(s). One tenet of portable code is the avoidance of
OS-specific calls, at which I have almost succeeded with TRueView (the FPS
calculation uses a Windows timer). The keyboard I/O is handled by GLUT, which
simply reads the keyboard just like the BIOS does - one key at a time. Because
of this, GLUT cannot reasonably detect a two-key combination (other than SHIFT-*
or CTRL-* or ALT-*). Programs that do this must make Windows calls directly,
which I am not inclined to do. Again, perhaps someone else will pick up on
this and make a full-blown Windows UI. That is not my goal.
> Since TRueView can't recognize portal linking (as per the readme), how about
> a visibility limit (perhaps even with fogging) option to compensate for not
> having to render the entire level?
Now there's a thought. Cutting down on what's rendered has been a real
pain. Using the portal data is only useful if the camera is entirely within
the level (as Lara is guaranteed to be); if you stray outside of the rooms'
bounding boxes (even slightly, such as going to rooftop-level in WALL.TR2),
the portals lose their meaning and one must find another means to limit what
is drawn (or draw the whole level). Using OpenGL's fogging cuts down on what
is rendered, but not on the per-polygon operations. Perhaps a simple distance
test, coupled with fogging, _would_ be a good way to go... I'll put that on
the list of improvements to include in future projects (and who knows, maybe
there _will_ be another version of TRueView, if enough things change...)
Yuri Zhivago