So this begs the question from the newbie: Doesn't this mean that
zooming is a dynamic?
Any transformation of the image post initial rendering means that the
image is Dynamic: Zoom, Pan, add elements, change elements, etc...)
I have been reading up on the Holongate stuff, and it seems to be a
bridge between Batik (it is included) and the Draw2D structure of SWT
(replacing Java2D?). So it is, essentially, an Adapter between SWT
and Batik.
I still need to see how much have the Holongate guys done to implement
batik under SWT, but so far my readings tell me that they have not
solved the SWT-AWT issue on Mac OS X.
Some interesting reading in the Eclipse bugsite:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=47716
https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384
I wonder about building the game using traditional graphics... then
work to rip that out (or Adapter pattern it) and replace it with SVG
in the Second Time Through. But I'd rather spend the time learning
and evaluating up front, then focus on mastering one technology.
By doing this, thus, you would be disregarding all that SVG can bring
to the table. You have pointed some of these benefits yourself, like
layering, object manipulation, transformations, event handling, etc...
And in the second Time Thorough you would be practically remaking your
app.
Then maybe I can beg your advice based on my overall goals?
- Deployable as Java (run anywhere).
- All graphics engine done in SVG. I am really attracted to the XML
backend for various reasons:
- ease of creation/editting of maps
- small transfer size of images for maps, overlays, etc
during a network game.
- XML is validatable, so I can have a map validator tool
for end users.
- Tree structure of XML data should allow for 'layers' in
the graphics of the program. Turning on and off grid lines
on the map, for instance.
Now, disappointingly, Java doesn't seem to support SVG natively, so
there seems to be little to no real resource for a learner out there
when starting to center an application around this technology. :(
What books and sites do cover seem to be either approaching SVG from a
Web-designer's angle, or is written to a developer's level so it
leaves me struggling. Holongate's site is this way, and in a lot of
ways, as is the Batik site. But I am making headway by messing up and
going through the JavaDocs. Currently, I am trying to build an SWT
JSVGCanvas example as a proof of concept, giving me a base
understanding how things tie/depend together.
About documentation, you have that right. It is still an evolving
technology, that has no easy entry point. I would recommend that your
SVG learning you do it based on the web-developer focus, so that you
can understand how SVG works. (Requires some understanding of
JavaScript). Once you understand how SVG works, the Batik Framework
will make more sense. Good resources fro web-based samples are:
http://www.svgfaq.com/JSGeneral.asp
http://www.carto.net/papers/svg/
I am studying SWT/JFace in order to maximize the app's
acceptance/audience, and also to cut down on development time as it
seems that it clears up a lot of problems with Swing, not to mention
making a lot of things easier/cleaner to code. And... because a few
Real Programmers recommended this direction since I have no legacy
application code married to Swing. But at this point, as the entire
project is still in the design phase, right now is a great time to be
switching or choosing technologies.
Since you are developing a game, the end user is a lot more lenient
about user-interface disparities. Almost every game i know of from a
mayor game vendor has its own user interface that does not comply at
all to the underling OS.
My own perspective of using SWT-JFace would be to cut down on
development time and make use of a higher level of abstraction to the
Model-View-Controller methodology. SWT brings the added value of native
look and feel and faster gui rendering since it uses native widgets,
but as mentioned before, I consider this should not impact your design
decisions, unless your game will be highly processor intensive, and
then you should question if SVG would be a good fit, since SVG also is
very processor intensive by itself.
In your case, what I understand, is that basically you would like to
benefit from the assets that a RCP can bring to the table so that you
can focus on your particular problem, instead of the nuances of the
underlying programming environment (in this case java). Both RCP
options out there give that to you:
- Robust windowing environment and event management.
- Set of widgets that only require for you to provide the data and the
model. (JFace of Netbeans widgets)
- Modularized development (plugins or cluster modules)
- Simplified deployment options
- Help systems
- Automatic Updating
- Workspace-filesystem managing
etc...
So basically the big question is: Which will work for you?
Considering that you are not married yet to any specific platform, I
would recommend NetBeans for your project, based on the following:
- Batik relies on Swing-Java2D to work, so your application visual area
will be rendered in Swing, regardless of the underlying platform.
- Deployment: NetBeans has included a JNLP deployment option that
creates and signs all your jars, for WebStart deployment.
- GUI Building: the new GUI builder (Matisse)
- Now, the cons of Netbeans RCP are:
- less documentation, smaller active community.
- Relies purely on Swing, but does a terrific job of isolating the
developer from the pains of core Swing development.
- Still in Beta stage (v5.0)
Now, do not take me wrong, if Eclipse did not have the SWT-AWT problem,
I would go with it, simply because my job as a developer would be
simpler based on the fact that there is a lot more documentation. But,
also, I have been impressed with what the folks at NetBeans have done
with this new release (both of the IDE and the RCP).
Some good reading for NetBeans RCP:
http://www.planetnetbeans.org/
http://wiki.java.net/bin/view/Netbeans/NetBeansDeveloperFAQ
Hope I have not confused you further,
Regards,
Andres.
So, any advice on technologies to investigate and read up on, I would
whole-heartedly appreciate. You guys are the experts, so showing me
something I am not yet aware of will be well received. :)
John
BlackRookSix of OpenWarSim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
