People are still missing the point the article was trying to make (or haven't even read / understood it).
The situation is this:
* On one hand JEE describes a set of patterns and best practices Java web applications should be architected with
* Additionally, JEE also prescribes the implementation of these patterns JEE developers should use (Session Beans, Entity Beans, etc.)
The fact is that when developing JEE applications, on a technical level developers can choose to completely ignore some of these JCP technologies and implement the JEE patterns using perfectly fine, capable and even superior alternatives, such as Hibernate and Spring.
So the point the article's author was trying to make was that just as AJAX describes a set of patterns for developing web applications, while the developer chooses the implementation he prefers (JSON, DWR, frameworks such as Dojo, YUI, whatever...), JEE could benefit from "officially" allowing developers to freely choose whatever implementation of those patterns they saw fit (such as using Spring and Hibernate instead of the JCP-sanctioned Session Beans and Entity Beans respectively), instead of trying to force them to use the standard ones.
That's how he was comparing JEE and AJAX and how he was hoping things could be similar - nothing to do with comparing "apples and oranges".
Personally, I've been using Spring and Hibernate in my JEE projects instead of the official implementations for some time now, and seeing the advantages and innovations these have put on the table, I have agree with his point.
i'm currently working on an outdoors game engine and i find quadtrees working very nicely for me. you'll probably want some sort of hierarchical data structure, so that culling can be done very efficiently (culling a higher level node automatically culls all of it's child nodes), and so that you can easily do node simplification for parts of the map that are far away from the user.
more concretely what i have is all the vertex data objects stored in an array, and then a quadtree where every node has nine pointers to the nine vertex objects that describe it, and other info such as it's bounding box (even though you can recalculate them every time you need them instead of storing them if you want to save memory at a cost of more computational time), plus some other stuff. during the rendering fase first i reject all the nodes that are not visible to the player (pretty fast, as i said you only need to test for visibilty the bounding box of a higher level node in order to reject all of its child nodes), and then starting with the higher level visible nodes i determine wether they should render themselves or have it's children handle it, depending on how far away it is from the viewer (the more far away a node is from the viewer, the more likely it is that it's enough to render it instead of having to go deeper into the tree and have its children rendered). when rendering a node itself you can also do some vertex simplification depending on it's distance.
i find this quite efficient in computing terms for very large maps, the main problem being of course the huge amount of memory these maps eat;)
you can find some more info on http://www.gamasutra.com (there's a very nice article on using quadtrees there in a different way as i've described) or http://www.vterrain.org, where they have links to several papers describing different techniques and data structures
So RMS's has a deficit on social and communication skills (at least when seen from a 'mainstream' frame of reference)... Well?
Myself, i do hold as RMS a spiritual father in many ways, despite all the personality 'quirks' he might have (and seems to even treasure), like them or not. We are all human after all, and we all have our naughty sides that other people might not like (or even ourselves!).
I don't think it makes his ideals, work and contribution to make this world a better place for all of us less valid.
Slashdot Mirror
People are still missing the point the article was trying to make (or haven't even read / understood it).
The situation is this:
* On one hand JEE describes a set of patterns and best practices Java web applications should be architected with
* Additionally, JEE also prescribes the implementation of these patterns JEE developers should use (Session Beans, Entity Beans, etc.)
The fact is that when developing JEE applications, on a technical level developers can choose to completely ignore some of these JCP technologies and implement the JEE patterns using perfectly fine, capable and even superior alternatives, such as Hibernate and Spring.
So the point the article's author was trying to make was that just as AJAX describes a set of patterns for developing web applications, while the developer chooses the implementation he prefers (JSON, DWR, frameworks such as Dojo, YUI, whatever...), JEE could benefit from "officially" allowing developers to freely choose whatever implementation of those patterns they saw fit (such as using Spring and Hibernate instead of the JCP-sanctioned Session Beans and Entity Beans respectively), instead of trying to force them to use the standard ones.
That's how he was comparing JEE and AJAX and how he was hoping things could be similar - nothing to do with comparing "apples and oranges".
Personally, I've been using Spring and Hibernate in my JEE projects instead of the official implementations for some time now, and seeing the advantages and innovations these have put on the table, I have agree with his point.
i'm currently working on an outdoors game engine and i find quadtrees working very nicely for me. you'll probably want some sort of hierarchical data structure, so that culling can be done very efficiently (culling a higher level node automatically culls all of it's child nodes), and so that you can easily do node simplification for parts of the map that are far away from the user.
;)
more concretely what i have is all the vertex data objects stored in an array, and then a quadtree where every node has nine pointers to the nine vertex objects that describe it, and other info such as it's bounding box (even though you can recalculate them every time you need them instead of storing them if you want to save memory at a cost of more computational time), plus some other stuff. during the rendering fase first i reject all the nodes that are not visible to the player (pretty fast, as i said you only need to test for visibilty the bounding box of a higher level node in order to reject all of its child nodes), and then starting with the higher level visible nodes i determine wether they should render themselves or have it's children handle it, depending on how far away it is from the viewer (the more far away a node is from the viewer, the more likely it is that it's enough to render it instead of having to go deeper into the tree and have its children rendered). when rendering a node itself you can also do some vertex simplification depending on it's distance.
i find this quite efficient in computing terms for very large maps, the main problem being of course the huge amount of memory these maps eat
you can find some more info on http://www.gamasutra.com (there's a very nice article on using quadtrees there in a different way as i've described) or http://www.vterrain.org, where they have links to several papers describing different techniques and data structures
Indeed... this looks like what's been described over and over again for years on any of my old unix sysadmin manuals.
So RMS's has a deficit on social and communication skills (at least when seen from a 'mainstream' frame of reference)... Well?
Myself, i do hold as RMS a spiritual father in many ways, despite all the personality 'quirks' he might have (and seems to even treasure), like them or not. We are all human after all, and we all have our naughty sides that other people might not like (or even ourselves!).
I don't think it makes his ideals, work and contribution to make this world a better place for all of us less valid.
Let's give him the credit for that.