Analyser

Do you want to contribute to improving ZGameEditor? Check out the list of open activities and find out where you may be able to help!

Moderator: Moderators

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Analyser

Post by Kjell » Fri Jan 15, 2010 6:20 pm

:idea:

In order to simplify the process of finding out what and how people are using ZGameEditor, I'm writing a small browser-based "application" ( HTML5 + Javascript ) that takes a .zgeprog, analyses it, and generates a compact visual report.

Currently I'm assembling the following data ..

- Filename / Filesize / Last_Modified
- Component chart listing how often each Component has been used.
- Data chart listing the size of all imported Mesh / Bitmap / Sound Data.
- Script chart listing the number of characters used in ZLibrary / ZExpression / MeshExpression etc.

Anything else?

K
Attachments
Report.gif
WIP ( Needs color coding and scale indication )
Report.gif (1.92 KiB) Viewed 11814 times

User avatar
diki
Posts: 140
Joined: Thu Sep 11, 2008 7:53 pm
Location: GMT+1
Contact:

Post by diki » Fri Jan 15, 2010 9:23 pm

good idea!

how about:

- depth of parent/child hierarchy (min/max/avg), maybe different counts for functional & render trees?

also - wip of course, but - layout:
(please ignore text flip; the idea is to align the bar to the corresponding component)
Attachments
alt.GIF
alt.GIF (2.93 KiB) Viewed 11812 times

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Fri Jan 15, 2010 9:39 pm

:)

I've gone back and forth on horizontal / vertical bars a couple of times already :wink: Ideally the colors and fixed order of the components should eventually be enough, but we'll see ..

Depth might be a little tricky, since Events / Models / Groups / States etc would have to be excluded .. counting how many components are used in each individual Event ( OnLoad / OnUpdate / OnRender etc. ) is a excellent idea though ~

+ It's funny to see how various projects by the same person generate similar reports 8)

K
Attachments
Ville.gif
Ville.gif (5.73 KiB) Viewed 11784 times

User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et » Sat Jan 16, 2010 5:31 pm

Hmm...
"Fingerprints"?
"DNA"?
You can prog, but you can't hide.
:wink:

User avatar
diki
Posts: 140
Joined: Thu Sep 11, 2008 7:53 pm
Location: GMT+1
Contact:

Post by diki » Sat Jan 16, 2010 6:39 pm

:D

this might also be a useful tool to remind us of scarcely-used components we might have forgotten about ;)

User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski » Sat Jan 16, 2010 7:51 pm

Cool,. looks to be quite interesting. wundering if it could be integerated into the editor? or if you keep building nifty ZGE related web apps perhaps adding them all to a page somewhere., . are you working on some net based game project?
iterationGAMES.com

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Mon Jan 18, 2010 6:10 pm

Hmm,

You could integrate it in a similar fashion as the help file, but i don't really see the point ... and it doesn't work online ( without uploading the .zgeproj at least, which is not what you want ).

Anyway, almost done :)

K

User avatar
VilleK
Site Admin
Posts: 2050
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Mon Jan 18, 2010 7:28 pm

Interesting, reminds me of heuristics used by virus analyzers to detect programs that are functionally but not syntactically duplicates. And yes, I seem to use the same style every time :)

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Tue Jan 19, 2010 4:23 pm

:?:

@diki - Turned out that generating a depth chart wasn't all that difficult afterall ( and produces quite interesting results ). The only question is what filter rule(s) to apply exactly.

Right now I'm ignoring every non-Component* node that is empty or of which the parent doesn't have more then 1 child ( see attached for example, blue is a entry and red is a exception ) .. but I'd like some feedback on this.

*Also, I'm ignoring "Group" as a entry ( but it does count as 1 depth step ) .. but perhaps I should just completely ignore everything that's not a Component?

K
Attachments
Filter.gif
Filter.gif (3.08 KiB) Viewed 11730 times

User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et » Tue Jan 19, 2010 4:45 pm

I would agree that "Group" looks like a depth step in the project tree, but in the processing, is it really? I don't think grouping affects the hierarchy of processing, or anything, other than visually making order.

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Tue Jan 19, 2010 6:24 pm

@y_offs_et,

You're right, it doesn't do anything for a game / application you make using ZGE, but the question is whether or not it should be represented in a depth chart. My initial thought was no as well .. on the other hand it does say something about how somebody structures their project.

Any opinions / idea's about the non-Component nodes?

K

User avatar
diki
Posts: 140
Joined: Thu Sep 11, 2008 7:53 pm
Location: GMT+1
Contact:

Post by diki » Tue Jan 19, 2010 7:35 pm

hmmm, the 'Group' component is really mostly used to introduce a (functionally neutral) order/hierarchy into otherwise non-hierarchical collections (the Content-tree mostly ;)) ... i think it would be nice to get the option of having it counted; it could tell a lot about programming style.

regarding the depth-counting of non-component nodes: i think if you omit the 'Children'-node of the 'Group', you should also omit the 'OnTrue' & 'OnFalse'-nodes of the 'Condition' (and also other non-component nodes, like the different 'On...'-events in the 'Model'). when counting for depth, all they really do is increment the count for the containing components - depth count does not discriminate their functionality. since the contained components' depth is already properly incremented by counting the parent node, another increment is not necessary... i think ;)

about the layout: did you think about different ways of encoding the informations on 'depth' and 'event type' into the chart yet? one could imagine coloring the bars differently in the corresponding relations. you could also approach the data the other way and show how many of each component there are for each eventtype, or at each depth level... oh, the possibilities! data viz is such a cool thing to think about ;)

User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et » Tue Jan 19, 2010 8:21 pm

on the other hand it does say something about how somebody structures their project
True. So far as I can see, your project is about programming style, rather than functionality or efficiency.

depth is already properly incremented by counting the parent node, another increment is not necessary... i think ;)
True, however I have situations with two or three components activated with a single "on".

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Tue Jan 19, 2010 10:50 pm

:)

@y_offs_et : Yea it's about the source only .. not performance / efficiency ( unfortunately ). Such a tool would be great to have as well, but it would have to be build on top of the ZGE Engine to be accurate ( and thus written in Pascal ).

@diki : That's the difficulty .. choosing a standard of what data to show .. and how. When everybody starts using their own settings, it'll be impossible to easily compare results.

And I went with your suggestion to simply only include Components in the depth processing :wink:

K
Attachments
Depth.gif
Depth.gif (3.05 KiB) Viewed 11703 times

User avatar
diki
Posts: 140
Joined: Thu Sep 11, 2008 7:53 pm
Location: GMT+1
Contact:

Post by diki » Wed Jan 20, 2010 7:38 pm

kjell: i was tempted to link this earlier, but that last graphic is hitting the spot :) - edward tufte on the topic of sparklines. there are other interesting bits on tufte's site, too; some practices are questionable, though, so it's a good idea to trust your own viewing habits for guidance.

Post Reply