Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (577)
games submitted by our members
Games in WIP (498)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Improving compatibility with older Xith3D codebase  (Read 6136 times)
0 Members and 1 Guest are viewing this topic.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #30 - Posted 2006-10-25 19:35:10 »

Hi,

Quote
What do you mean by "attend"?

I mean just to continue discussion and do not get as personal critics - you did a great job anyway.

I plan to intensively use Xith3D core (maybe, toolkit not too much), so I want to have it production quality on the other hand, but I also do not want to break anybody's code by introduction of incompatible changes. You know, I prefer minimalistic changes.

So "attend" means "please check if I understood your ideas behind correct and explain if not".

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #31 - Posted 2006-10-25 19:52:56 »

Hi,

Quote
ShapeAtom.updateShaders(...) actually is called from Appearance.verifyChange(). This method is called from ShapeAtomPeer.renderAtom().

Yes, I see, and this explains why I get the result of "only one wrong frame just after the changes", so 2nd and other subsequent frames are OK.

Updating shaders in renderAtom() is too late - it should be updated BEFORE sorting pass. So if you check the changes I made to CVS now I placed this call immediately when atoms are collected (added) during re-cull.

Quote
I don't fully understand this shaderId thing.

This thing comes from very first versions of Xith3D, I think I have explained how it works a year or so on this forum. But with great pleasure I will explain you the idea and why updating shaders in renderAtom() is too late.

As you see, for each (in general words) appearance component type there is a shader. For each by-value-unique appearance component the core makes unique stateId which is assigned using a map (StateMap) - when creating a shader, map is looked up for the appearance component and if exactly equal shader has already been created, and if so, take its stateId (creating a new stateId otherwise).

Now, after stateIds are assigned, core on atom-by-atom basis executes the shaders and AFTER (!) calls renderAtom(), so if you update shaders there core will execute shaders at least once with old stateId's assigned before the change.

The problem is that the core can decide to skip actual shader execution if it sees that the shader of given type with specific stateId was already executed just before, so if two shaders with different characteristics will have the same stateId, one may be skipped while have to be applied in order to get correct rendering result.

Yuri




Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #32 - Posted 2006-10-25 19:54:53 »

P.S. we should remove now a call to app.verifyChange( shape ) from renderAtom(...) because of it is redundant...

Yuri

Yuri Vl. Gushchin
JProof Group
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 #33 - Posted 2006-10-25 19:58:56 »

P.S. we should remove now a call to app.verifyChange( shape ) from renderAtom(...) because of it is redundant...

OK. We can either remove it from FrustumCuller or from renderAtom(). Removing it from renderAtom() is ok for me. (so ignore the appropriate post-part int the other thread Wink).

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #34 - Posted 2006-10-25 20:00:57 »

P.S. we should remove now a call to app.verifyChange( shape ) from renderAtom(...) because of it is redundant...

OK. We can either remove it from FrustumCuller or from renderAtom(). Removing it from renderAtom() is ok for me. (so ignore the appropriate post-part int the other thread Wink).

Marvin

Done.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #35 - Posted 2006-10-26 01:37:49 »

Hi,

So we are more or less re-starting to work community-way. Great to see this.

Yuri

P.S. Unfortunately, I can not stay always on-line, so some responces are a bit delayed.

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




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


« Reply #36 - Posted 2006-10-26 11:27:59 »

So we are more or less re-starting to work community-way. Great to see this.
Indeed. I'm in holiday right now (for one week and a half) maybe I'll have more time to dig the core.

P.S. Unfortunately, I can not stay always on-line, so some responces are a bit delayed.
Yuri, in case you ever disappear again for several weeks/months, could you please write a detailed doc on the core (once it's stable again, of course) so I and others can get how it works in a way easier than reading 5 classes in parallel to find what comes from where and goes where by which mean and when ?  Grin

"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 Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #37 - Posted 2006-10-26 12:03:18 »

Hi,

Looks like my chapter to XIN should come... Or so... For those who feel fit to read heavy technical stuff.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




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


« Reply #38 - Posted 2006-10-26 12:23:17 »

Hi,

Looks like my chapter to XIN should come... Or so... For those who feel fit to read heavy technical stuff.

Yuri
This would take place in the UTH book ("Under The Hood"), not in the XIN.
XIN is meant to be simple and stupid, UTH is mean to be thorough and exhaustive.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: 1 [2]
  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 (19 views)
2014-04-15 18:08:23

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

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

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

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

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

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

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

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

CJLetsGame (187 views)
2014-04-01 02:16:10
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

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!