Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  XIN Tutorial  (Read 3426 times)
0 Members and 1 Guest are viewing this topic.
Offline rafa_es

Junior Member





« Posted 2006-10-02 23:18:22 »

Hi guys, I was looking for  the XIN tutorial in cvs but its not there,

Can anyone confirm if its not there?

Bye
Offline bohdan

Junior Member




Java-positive...


« Reply #1 - Posted 2006-10-02 23:39:17 »

Hmmm... yes, it seems to be deleted. Marvin?

Meantime, you can just get it on web:
https://xith-tk.dev.java.net/source/browse/*checkout*/xith-tk/docs/xin/Attic/xin.pdf?rev=1.5
Offline rafa_es

Junior Member





« Reply #2 - Posted 2006-10-02 23:43:39 »

Hmmm... yes, it seems to be deleted. Marvin?

Meantime, you can just get it on web:
https://xith-tk.dev.java.net/source/browse/*checkout*/xith-tk/docs/xin/Attic/xin.pdf?rev=1.5


Thanks bohdan  Grin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #3 - Posted 2006-10-03 14:32:02 »

Hmmm... yes, it seems to be deleted. Marvin?

Well, I deleted the PDF, since it isn't always current. Please use the OpenOffice document until we release it on xith.org. Exporting it to PDF and committing this everytime Amos or me modified it just increases the repository size.

When Amos added the screenshots he's talking about, we'll release it on xith.org.

@Amos: What do you think about splitting XIN into two parts? Part one just explains the very basics to get started with Xith3D, like the current version does. So the current version (together with the screenshots) could be "XIN - Part I" and the following chapters could be summed up in "XIN - Part II".

Marvin
Offline rafa_es

Junior Member





« Reply #4 - Posted 2006-10-03 15:02:07 »


@Amos: What do you think about splitting XIN into two parts? Part one just explains the very basics to get started with Xith3D, like the current version does. So the current version (together with the screenshots) could be "XIN - Part I" and the following chapters could be summed up in "XIN - Part II".

Marvin

That would be great for the newbies  Grin
Online cylab

JGO Knight


Medals: 34



« Reply #5 - Posted 2006-10-03 15:54:18 »

Btw. I just read the current version. Thumbs up for this nice tutorial!

Splitting it into two parts, maybe "XIN - Getting Started" and "XIN - Advanced Topics", seems like a good idea.

Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #6 - Posted 2006-10-03 15:56:42 »

Btw. I just read the current version. Thumbs up for this nice tutorial!

Splitting it into two parts, maybe "XIN - Getting Started" and "XIN - Advanced Topics", seems like a good idea.

Great idea. But what about making it a little more dramatic by using subtitles Wink

1  
2  
                                                XIN - Part I
                                              Getting Started


and
1  
2  
                                                XIN - Part II
                                               Advanced Topics

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #7 - Posted 2006-10-03 18:18:14 »

Btw. I just read the current version. Thumbs up for this nice tutorial!

Splitting it into two parts, maybe "XIN - Getting Started" and "XIN - Advanced Topics", seems like a good idea.

Great idea. But what about making it a little more dramatic by using subtitles Wink

1  
2  
                                                XIN - Part I
                                              Getting Started


and
1  
2  
                                                XIN - Part II
                                               Advanced Topics


I object !  Grin Grin

XIN is supposed to explain Xith "in a nutshell".
I had the project to co-write (with you, Qudus) a second book named "Xith Under The Hood" (UTH) which explain the low-level scenegraph and renderer structures how precisely it is handled and how you do to add features.

What would you put in "Advanced Topics" ? Even advanced graphics effects should be made simple ! If a code snippet takes more than one-two page, it is (IMHO) bad and it needs to be simplified. However, explanations with the snippets can be made longer (2-4 pages) if the subject is big. But for XIN, it's the "KISS" philosophy (Keep It Simple Stupid)...

What do you think of that ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #8 - Posted 2006-10-03 18:23:16 »

agreed.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #9 - Posted 2006-10-03 19:31:22 »

Xin is ok for me for First edition.

More chapters/screenshots will be added later.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #10 - Posted 2006-10-04 19:13:05 »

Xin 1st Edition is out !  Cool

http://www.xith.org/

Some things have been added since the "draft" (check it out).

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #11 - Posted 2006-10-04 20:54:30 »

Great! But the page numbers are shifted. I'll fix that the next days.
Offline hawkwind

Junior Member




Java games rock!


« Reply #12 - Posted 2006-10-10 01:37:13 »

observation:

.  the use of the demo folder code  [ new Xith3DDemoFolder() ]assumes a sub directory pattern, texture etc.  this should be spelled out in the tutorial so a new user understands his image data etc needs to be in a specific subdirectory
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #13 - Posted 2006-10-10 02:25:06 »

observation:

.  the use of the demo folder code  [ new Xith3DDemoFolder() ]assumes a sub directory pattern, texture etc.  this should be spelled out in the tutorial so a new user understands his image data etc needs to be in a specific subdirectory

No. The Xith3DDemoFolder class has nothing to do with the XIN book. The info, you're talking about needs to be noted in Xith3DDemoFolder's JavaDoc. And I'll add it there. But this class is never used in XIN and is only a helper for the org.xith3d.test classes and is not meant to be used for other projects.

Marvin
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #14 - Posted 2006-10-10 18:28:18 »

observation:

.  the use of the demo folder code  [ new Xith3DDemoFolder() ]assumes a sub directory pattern, texture etc.  this should be spelled out in the tutorial so a new user understands his image data etc needs to be in a specific subdirectory

No. The Xith3DDemoFolder class has nothing to do with the XIN book. The info, you're talking about needs to be noted in Xith3DDemoFolder's JavaDoc. And I'll add it there. But this class is never used in XIN and is only a helper for the org.xith3d.test classes and is not meant to be used for other projects.
Though we'd have to :
- Ensure that all can be loaded properly both in filesystems and jars
- Talk of how to do that in XIN

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #15 - Posted 2006-10-10 19:15:32 »

Though we'd have to :
- Ensure that all can be loaded properly both in filesystems and jars
- Talk of how to do that in XIN

Yes. Agreed.
Online cylab

JGO Knight


Medals: 34



« Reply #16 - Posted 2006-10-10 21:11:57 »

Do you consider the TextureLoader framework as stable for 1.0 or will it be changed till then?

I was a little confused by the TextureLoader, ImageComponentLoader, TextureStreamLoader and TextureStreamLocator  interfaces. I think they could be better seperated by renaming them:

TextureLoader -> ResourceLoader
Since I think it could be usefull to extend the TextureLoader singleton to locate and load all resources needed by Xith (sounds, models etv.)

TextureStreamLocator -> ResourceLocator
Which would be an obvious change, if the TextureLoader is renamed

TextureStreamLoader -> TextureFactory
To ensure that XXXLoader is not mistakable for XXXLocator

ImageComponentLoader - ImageComponentFactory
to follow the scheme

Also I would vote for a ClasspathLocator implementation, that takes a ClassLoader instance as contructor parameter. I think it would be very convenient to have the ResourceLoader initialized to ResourceLoader.class.getClassLoader() per default, so you always have access to resources on the classpath where xith.jar is loaded from.

what do you think?

Mathias

Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #17 - Posted 2006-10-10 21:55:32 »

I find the names Loader and Locator confusing, too. So I would be happy, if they'd get renamed in some way. I'm not sure, if all these locators and things actually make sense. I guess, it's not the most efficient way. And the textures must not be loaded from java internal ImageIO into a BufferedImage and then converted into a Texture, but directly load them by faster loaders into a Texture. I would prefer to get the createTexture() methods out of TextureLoader and put them into a new class called TextureCreator or maybe TextureFactory.

But TextureLoader and ModelLoader should stay separated, since they're too different to unite them in a common loader system.

We don't have a common Sound loader yet. So it would make sense to write one and put it to com.xith3d.loaders.sound.

Maybe you want to write a wrapper class, that loads resources and makes use of TextureLoader and the model-/scene loaders. I've just improved org.xith3d.loaders.base.* to make the classes more general (not committed yet). If all model-/scene loaders would inherit from this loader base, we'd be a big step further.

Marvin
Online cylab

JGO Knight


Medals: 34



« Reply #18 - Posted 2006-10-10 23:17:33 »

Quote
I find the names Loader and Locator confusing, too. So I would be happy, if they'd get renamed in some way.
Let's see what Amos says to this. Is there any background info, where they came from? They seem to be quite new, since the GSG examples don't uses this scheme.

Quote
And the textures must not be loaded from java internal ImageIO into a BufferedImage and then converted into a Texture, but directly load them by faster loaders into a Texture. I would prefer to get the createTexture() methods out of TextureLoader and put them into a new class called TextureCreator or maybe TextureFactory.
(...)

We don't have a common Sound loader yet. So it would make sense to write one and put it to com.xith3d.loaders.sound.
Hmm, so there should be dedicated Factories for textures, models and sound. I can think of three possible ways to do this:

1. create  XXXFactory singletons which can be extended by registering "XXXProducers" (e.g. ModelFactory with a MD3ModelProducer)
At least TextureLoader follows this scheme... seems the most "service oriented" approach, but may be too J2EE style for games Wink

2. create dedicated classes for each resource type which derive a special base class (e.g. MD3Model extends Model) and take the base name as constructor parameter
I have seen several implementations like this and this seems fast and easy

3. create XXXFactories which inherit resource specific base factories (e.g. MD3Factory extends ModelFactory)
The base factories would specify a create method to force the return type (e.g public Model create(String baseName))

I think solution 1 is oversized and 2 looks suspicious to have a catch (multiple inheritance perhaps). I would prefer something like solution 3. Don't know what you are doing with the new loader base, but it sounds to go into this direction.

Quote
I'm not sure, if all these locators and things actually make sense. I guess, it's not the most efficient way.
At least from the design perspective, they offer a good abstraction of resource loading. I guess with a little caching of valid stream locations they will be efficient enough. I think it is worth it, to have an abstracted access to different resources, but I would vote for the ResourceLoader to be just some sort of repository singleton where to register locators and move the createXXX methods to some other place (s.o.).

Quote
Maybe you want to write a wrapper class, that loads resources and makes use of TextureLoader and the model-/scene loaders.
I do not neccessarily need a central point of Texture/Model/Sound instanciation, I just like the idea of a central point to find resources, so TextureLoader looked like the right victim Wink. Also I think it is substantial to have good support to load from the ClassLoader.

Mathias


Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #19 - Posted 2006-10-11 00:17:23 »

Hmm, so there should be dedicated Factories for textures, models and sound. I can think of three possible ways to do this:

1. create  XXXFactory singletons which can be extended by registering "XXXProducers" (e.g. ModelFactory with a MD3ModelProducer)
At least TextureLoader follows this scheme... seems the most "service oriented" approach, but may be too J2EE style for games Wink

2. create dedicated classes for each resource type which derive a special base class (e.g. MD3Model extends Model) and take the base name as constructor parameter
I have seen several implementations like this and this seems fast and easy

3. create XXXFactories which inherit resource specific base factories (e.g. MD3Factory extends ModelFactory)
The base factories would specify a create method to force the return type (e.g public Model create(String baseName))

I think solution 1 is oversized and 2 looks suspicious to have a catch (multiple inheritance perhaps). I would prefer something like solution 3. Don't know what you are doing with the new loader base, but it sounds to go into this direction.

The loaders base does exactly what you describe in point (2.). And I definitely prefer this way. It is an advancement and generalization of the old / current org.xith3d.loaders.scene loaders base. This one is fine except that scenebase doesn't extend any Group type and the getters return arrays, which need to be created especially for the getters. And there's no difference between a model and a scene, which is a minor issue, but "solved" in my version.

Also I think it is substantial to have good support to load from the ClassLoader.

TextureLoader can theoretically load from an InputStream through TextureStreamLocator. But one had to write an implementation for it. Some time ago I wrote one for zip inputstreams, which is very similar. And org.xith3d.loaders.base.Loader has six methods to load. three to load the file as a Model and three to load it as a Scene. One of each three takes an InputStream, which enables you to easily load from classpath. It is up to the loader implementer to corretly implement these methods.

Marvin

btw. I don't like the naming of Factory or Producer or things like that for Loaders. They don't produce a model, but load it. As I mentioned above the TextureLoader has methods to create an empty texture, which is of course needed to load one. But these methods don't belong to the TextureLoader itself as I think, but to a separate class.
Online cylab

JGO Knight


Medals: 34



« Reply #20 - Posted 2006-10-11 01:07:20 »

Quote
The loaders base does exactly what you describe in point (2.). And I definitely prefer this way. It is an advancement and generalization of the old / current org.xith3d.loaders.scene loaders base.
As I said this option is fast and simple. The only real advantage would be offered by option (1), where you can mix and match different Producers (or Builders ) without the user knowing anything about different model/texture/sound types. This would also prevent different inconsistent Loader classes, since the usage pattern is given by the API (the actual XXXFactory) and all concrete implementations are forced to use the interface offered by the SPI.

Quote
Quote
Also I think it is substantial to have good support to load from the ClassLoader.
TextureLoader can theoretically load from an InputStream through TextureStreamLocator. But one had to write an implementation for it. Some time ago I wrote one for zip inputstreams, which is very similar.
Yes, it's possible to use getResource() to retrieve an URL and pass it to TextureStreamLocatorURL, but this won't deal with the structure of the classpath (multiple jars/directories).Since it is easy to write an own TextureStreamLocatorClasspath, that overcomes this, I think it would be beneficial to adapt that scheme with other loaders, too.

Quote
And org.xith3d.loaders.base.Loader has six methods to load. three to load the file as a Model and three to load it as a Scene. One of each three takes an InputStream, which enables you to easily load from classpath. It is up to the loader implementer to corretly implement these methods.
At this point a general ResourceLocator could tighten the interface, since the InputStream retrieval is shifted to the ResourceLocator, so only resource names are needed to load a resource. Also it would allow for further optimization of the name<->stream mapping and resource access would be generalized for all kind of Loaders.

Quote
btw. I don't like the naming of Factory or Producer or things like that for Loaders. They don't produce a model, but load it
Yeah Producer is wrong, Builder would be better, since it would be an (simplistic) incarnation of the builder pattern. For me however everything that creates an Object is a Factory... Wink

Anyway Loader is fine. They should just all behave the same and share as most base functionality as possible.

Mathias

Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #21 - Posted 2006-10-11 01:22:15 »

As I said this option is fast and simple. The only real advantage would be offered by option (1), where you can mix and match different Producers (or Builders ) without the user knowing anything about different model/texture/sound types.

Well, the user does know exactly what kind of data he is loading, since he'll have to handle the returned object corretly.

At this point a general ResourceLocator could tighten the interface, since the InputStream retrieval is shifted to the ResourceLocator, so only resource names are needed to load a resource. Also it would allow for further optimization of the name<->stream mapping and resource access would be generalized for all kind of Loaders.

Yes, maybe.

Yeah Producer is wrong, Builder would be better, since it would be an (simplistic) incarnation of the builder pattern. For me however everything that creates an Object is a Factory...

Well, it is not simple object creation. Otherwise I would concede to you. Loader is just fine IMHO. Of course there're objects created, but in fact everyone will understand, what a loader does, when he expects it to load a model / texture / sound. And of course an object holding the model (e.g.) is the result.

So I wouldn't depart from the XXXLoader naming scheme.

Marvin
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #22 - Posted 2006-10-11 17:21:11 »

I agree with Marvin.

The only things the "Model" (MD2Model, CalModel or whatever) should conform to is to :
- Display the first frame of anim if that's an anim even if you haven't called any function after load
- Extends BranchGroup or provide a branchgroup containing the data

And we should be able to load a "model" (huge abstraction here) of whatever type with a single generic instruction so a "basic" model loader is really straightforward.

I think we could provide a function which returns an icon of the 3D model file.

It would :
- Load it
- Compute its sphere bounding box
- Create a scene with a Camera at the right distance so you see the whole model on a e.g. 48x48 canvas
- Render an RGBA image of it

That would be most useful in games.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #23 - Posted 2006-10-11 20:32:40 »

The only things the "Model" (MD2Model, CalModel or whatever) should conform to is to :
- Display the first frame of anim if that's an anim even if you haven't called any function after load
- Extends BranchGroup or provide a branchgroup containing the data

org.xith3d.loaders.base.Scene does extend BranchGroup while org.xith3d.loaders.base.Model extends Group.

And we should be able to load a "model" (huge abstraction here) of whatever type with a single generic instruction so a "basic" model loader is really straightforward.

org.xith3d.loaders.base.Loader does exactly this.

I think we could provide a function which returns an icon of the 3D model file.

Cool idea.

It would :
- Load it
- Compute its sphere bounding box

This is done by the extended Group or BranchGroup.

- Create a scene with a Camera at the right distance so you see the whole model on a e.g. 48x48 canvas
- Render an RGBA image of it

I guess, this would be better nested in a loader utility class.

Marvin
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (33 views)
2014-04-15 18:08:23

BurntPizza (30 views)
2014-04-15 03:46:01

UprightPath (45 views)
2014-04-14 17:39:50

UprightPath (28 views)
2014-04-14 17:35:47

Porlus (45 views)
2014-04-14 15:48:38

tom_mai78101 (66 views)
2014-04-10 04:04:31

BurntPizza (126 views)
2014-04-08 23:06:04

tom_mai78101 (226 views)
2014-04-05 13:34:39

trollwarrior1 (191 views)
2014-04-04 12:06:45

CJLetsGame (199 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!