将一个GridPane包装在ScrollPane中或以编程方式修改它。最有效的方法？ [英] Wrapping a GridPane in a ScrollPane or programatically modifying it. Most efficient approach?

问题描述

在游戏中我有一个GridPane在方形单元格中显示世界的Tiles。玩家可以使用键盘移动column \row显示的内容。我想到的方法是：
让GridPane以编程方式更改显示的磁贴，方法是在播放器输入上按x步移动所有内容。
将GridPane包装在ScrollPane中并将ScrollPane的滚动条连接到键盘输入。

In a game I have a GridPane displaying the Tiles of the world in square cells. The player can, using the keyboard, move what is displayed by a column\row. The approaches I've thought of are: Having the GridPane change programmatically the displayed tiles by moving everything by x steps on player input. Wrapping the GridPane in a ScrollPane and tying the ScrollPane's scroll to Keyboard input.

我的问题是，假设那些看起来不对的东西但是在同一个地图总是被加载，每种方法的优点和缺点是什么？最具体地说，我想知道将ScrapPane中的GridPane包装起来是否会保持图像加载，即使它们处于屏幕外，从而影响性能，如果在这种情况下最好只在需要时重新加载它们。我也想知道是否有第三种更有效的方式我没想过。

My question is, assuming that things that are off-sight but on the same map are always loaded, what are the pros and cons of each approach efficiency-wise? Most specifically, I'm wondering if wrapping the GridPane in a ScrollPane would keep the Images loaded even if they are off-screen, thus impacting performance and if in that case it would be better to just reload them when needed. I'm also wondering if there's a third, more efficient way I haven't thought about.

我正在使用JavaFX8

I'm using JavaFX8

推荐答案

一般方法

提供有限视口的最有效方法非常大的世界是为世界使用基于磁贴的模型，并且仅加载图形资源和显示当前视口所需的图块。

The most efficient approach for providing a limited viewport onto a very large world is to use a tile based model for the world and to only load the graphics resources and display the tiles that are required for the current viewport.

示例基于画布的实现

如何实现这一目标的一个很好的概述是eppleton JavaFX tile引擎，它在 eppleton博客文章。该特定实现使用 Canvas 直接基于绘制的方法而不是场景图节点导向方法。

A nice overview of how to accomplish this is the eppleton JavaFX tile engine which is described in an eppleton blog post. That particular implementation uses a Canvas direct draw based approach rather than a scene graph node oriented approach.

基于场景图节点的示例实现

基于场景图的方法依赖于什么叫做虚拟控制;其中控件提供作为基础数据模型的窗口的单元格。 JavaFX ListView 和 TableView 是虚拟化控件的示例。这些虚拟控件可以支持我的数据结构，其中包含数千个项目，但只有当前可见的数十个项目的可视项目实际显示在屏幕上。当滚动控件或修改其底层数据结构时，将调用回调以刷新每个显示单元格的图形节点。

A scene graph based approach relies on what is termed a virtual control; where the control provides cells which are windows on to the underlying data model. The JavaFX ListView and TableView are examples of virtualized controls. These virtual controls can be backed my data structures which contain thousands of items but only visual items for the currently visible tens of items are actually shown on the screen. As the control is scrolled or its underlying data structure is modified, callbacks are invoked to refresh the graphical nodes for each displayed cell.

基于场景图的网格虚拟控件示例是ControlsFX GridView 。请注意，与基于画布的eppleton Tile Engine不同，ControlsFX GridView并非专门为游戏引擎构建并优化为基于核心区块的渲染器，因此如果您以这种方式使用GridView，则需要显着添加GridView的分支或扩展的更多功能，使其在功能上与完整的游戏性磁贴引擎相提并论。

An example of a scene graph based virtual control for a grid is the ControlsFX GridView. Note that, unlike the canvas based eppleton Tile Engine, the ControlsFX GridView is not specifically built for and optimized to be the core tile based renderer for a game engine, so if you would use GridView in such a way, you would need to add significantly more features to a fork or extension of the GridView to bring it functionally on par with a full gameplay tile engine.

现有规范和工具集

请注意，现有Tile地图格式的规范，例如 TMX 和现有的编辑可以创建符合此类格式的文件。使用tilemap适用于实时和回合制游戏，甚至可以在游戏类型之外使用，尽管它的传统用法是创建视频游戏。

Note that there are existing specifications for Tile map formats such as TMX and existing editors to create files which conform to such formats. Usage of a tilemap is appropriate for both realtime and turn based games and may even be useful outside the gaming genre, though it's traditional usage is in the creation of video games.

其他问题的答案

你是否介意详细阐述，即使只是略微说明你对GridView的意思不是优化？

would you mind elaborating, even if just slightly about what you mean with GridView is not optimized?

您的主要应用程序似乎是编写基于磁贴的游戏引擎。这样的引擎通常提供对读取图块地图数据，图块图像数据，将动画精灵叠加到图块等上的支持。这些特征不在ControlsFX GridView中，因为它具有不同的焦点（例如，显示缩略图的视口）文件目录的图像）。关键不在于GridView没有优化性能（因为它），重点是GridView不会为您提供特定应用程序可能需要的最佳开箱即用功能（基于磁贴的游戏） ）。

Your primary application seems to be writing tile based game engine. Such an engine usually provides support for reading tile map data, tile image data, overlaying animated sprites on to the tiles, etc. Those kind of features aren't in a ControlsFX GridView because that has a different focus (e.g. displaying a viewport of thumbnail images for a file directory). The point is not that GridView is not optimized performance wise (because it is), the point is that GridView won't provide you with the optimal set of out of the box features which you might need for your particular application (a tile based game).

我忘了在我的情况下提到实体移动Tile by Tile而不是Pixel by Pixel

I forgot to mention in my case the Entities move Tile by Tile and not Pixel by Pixel

这使得实现更简单，因为您只需要担心离散坐标处的切片，并且实体可以是精确的切片坐标，而不需要当前位置的偏移并在瓷砖。然而，它并没有真正改变将虚拟视口仅用于世界的整个方法，这个世界只能渲染你当前可以看到的东西，而不是一直渲染整个世界。

That makes implementation simpler as you only have to worry about tiles at discrete co-ordinates and the entity can be an exact tile co-ordinate without an offset for current location and rendering between tiles. However it doesn't really change the whole approach of using a virtualized viewport of only onto the world which only renders what you can currently see rather than rendering the entire world all the time.

如果我在一年前知道这一切，我会在我的发展中采取一条完全不同的路线。

Had I know all this a year ago I would had taken a very different route in my delevopment.

有时做研究是值得的，有时候你会错误地学习:-)如果他知道他现在知道什么，我肯定John Carmack会以不同的方式写出原始的Doom。我不会让这些事情让你太担心。只需评估你现在的位置并从那里开始。

Sometimes it pays to do research and sometimes you learn by mistakes :-) I'm sure John Carmack would have written the original Doom differently if he knew then what he knows now. I wouldn't let such things worry you too much. Just assess where you are now and go from there.

这篇关于将一个GridPane包装在ScrollPane中或以编程方式修改它。最有效的方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！