cping

这应该是loon-core-0.5.jar这个包导入失败的结果，报的错误是找不到loon核心包中的一个方法，而这个方法很基本，也是公开的，并且没有任何外部API依赖，只要jar能导入就会找到。

jar导入出问题最简单的解决方式，删除相关jar，然后——拷贝源码，将LGame\Java\Loon-Neo\src以及LGame\Java\Loon-Neo-Android\src下的源码copy过去运行，这样就知道问题具体出在哪里了。

@ml3947 确实好久不见了，主要是一直没时间更新，所以暂时博客也不开，开源项目也不写（因此也就不看issues），等以后有时间我可以再开个博客咱们好好聊聊技术类话题，话说以后准备再开个博客写写Unity3D，游戏算法，以及服务器开发之类的话题。

@ZhangVivianHua 您好，关于文档的问题，因为还存在一些设计上的修改空间，所以暂未提供。 上面已经有道友提过了，游戏方面纯C/C++实现，安全性肯定要比Java实现更好，所以LGame未来肯定要往这个方向走，但因为是Java游戏引擎，也不可能不要Java而直接彻底转C/C++。 具体来说，我是准备走Java代码开发后自动转C编译的路线。 您可以关注一下Teavm项目，这是一个很不错的Java字节码转第三方语言的项目。尤其是，现在teavm添加了转换字节码为c语言的实现，如果我把LGame转为以teavm为后台编译环境进行封装的话，就可以把平台无关的java代码（字节码）直接转c而不必关注于具体运行环境（不能跑c编译程序的环境基本不存在），通过sdl之类已经近乎全平台适配的C语言渲染框架做平台底层交互，完全可以让LGame直接获得更好的跨平台特性（尤其是各种游戏机平台），这应该是LGame未来的开发重点。 然而，这样原有的一些设定可能还会存在修正，所以暂时就没有文档api提供了（因为写了还得改，关键是teavm的c实现部分这货作者也没完全写完，所以我也在等他的开发进度，现在有点守株待兔耗时间的意思……）。

您好，android studio中assets文件夹默认应该放置于src/main目录下，与res和java文件夹平级，也就是yourproject/src/main/assets。但是这并非绝对，gradle中可以通过sourceSets设置main参数来改变默认路径，也就是可以通过设置assets.srcDirs=['xxx']来改变其位置，所以它的位置和名称并不是一定固定的，而是可以根据设定和环境改变的。 例如可以在项目的build.gradle文件的sourceSets设置修改成这样一句: sourceSets{ main{ //... assets.srcDirs = ['assets', 'src/main/assets', '../assets/src/main/resources/assets'] } } 把与build.gradle同级的assets文件夹，src下的assets文件夹，以及额外打入上级目录resources下的assets文件夹都统一放在android的assets文件夹下。 这样这三个位置的assets文件打包后就都能被正常读取到,只要资源在这三个位置其中一个，最终结果就都一样了。 如果不愿意手写调整，android studio中有Folder选项，也可以配置assets folder路径。 当然，找不到文件也不一定是assets文件下没有相关文件，因为linux系统区分大小写，有时也可能是复制产生的文件大小写不一致问题。一般情况下，最好保证assets文件夹名称以及其中文件(含后缀)都小写，然后一律按小写名称读取，这样出名称错误的可能性会小很多。

请问您能提供可以引发问题的代码示例吗?

您好，由于canvas-ver是2012年以前的原始版本，长时间没有更新，肯定无法直接兼容现有的Android环境。 目前是有续写Canvas版计划的，是一个基于Loon-0.5的API和功能，也延续旧Canvas版API的轻量版，这个版本同时还会支持JavaME(现在属于JavaCard了)，JavaFX以及Android和HTML5（以0.5版来说功能基本都会实现，只是后续版本支持不会那么完全）。 更直接的讲，这个Canvas版其实主要是跑嵌入式设备用的。 目前来说，虽然Oracle已经基本放弃了Java的手机端应用(连JavaFX都变社区版openjfx了)，但是JavaME这个项目并没有撤销，而是变成了Java Card的一环，转为支持如树莓派这类的嵌入式设备编程。所以Loon-lite这个Canvas版肯定要尽可能向下兼容的，也会完整支持JavaME的渲染API(界面UI类则不支持，毕竟太丑了……)，基本的API支持和代码实现最近就会上传，不过测试的不太够，目前也就在我的树莓派3B上大概跑了一下，也就是[理论上]运行没有问题，正式版还要等着我把loon完整版再优化下再回头去优化它……

上次回复我提到过的。 LTexture[]数组的四张图默认顺序是，第一张图按钮默认图，第二张图鼠标悬浮图（鼠标滑过），第三张图按钮按下，第四张图按钮禁用图。因为触屏没有鼠标悬停事件，暂时没有悬停效果，也就是第二张图在触屏环境默认无效（Window10触屏环境下默认是长按算鼠标悬停，不过它那是出提示信息用的，也不是按钮图切换用，暂时无没想好按钮上怎么处理悬停事件）。

主要是我怕用长按触发悬停事件，和按下时的图片切换有冲突，时间不好把握，短的话，会造成悬停和按下两种图有闪烁感，长的话用户来不及触发，以为没效果就不按了。这需要实际优化下再决定最后怎么处理。

您好，这确实是个bug，但和LButton本身无关，这是一个Desktop的处理方式问题, 导致LButton处理悬停图时处理错误（LButton默认的最多四张图是，默认，悬停(鼠标滑过)，按下，禁用）。错误原因在于processTouchExited函数在手机环境中没有有效执行。原始方法中，在组件管理类Desktop的processTouchMotionEvent函数中，有一处组件查找方法 LComponent comp = this.findComponent(touchX, touchY); 他会对比鼠标位置下是否有组件，如果没有或者组件改变再执行已有组件的processTouchExited函数，在桌面上，根据鼠标滑动位置处理所获得的数据肯定是正确的，因为屏幕中鼠标轨迹就算不点击屏幕，也会随着移动变化，鼠标离开组件或屏幕processTouchExited也就执行了。 因为这个引擎最早版本是仅有桌面环境的，所以当初的设计没有问题。 但是，运行在手机环境，touch只有按下和拖拽还有放开时会获得touch位置，所以会造成这个方法在touch有操作前不能被执行，而且执行后不点击屏幕选中的组件也不会改变，所以processTouchExited触发时机会变得很奇怪。 现在我把这部分代码改成了 // 获得当前窗体下鼠标坐标 LComponent comp = null; if (SysTouch.getButton() != -1) { comp = this.findComponent(touchX, touchY); } 也就是一旦Touch无状态，则当前选中组件不查找，直接清空重新计算，这样touch无状态（没有任何操作）时processTouchExited就会生效。 不过悬停状态图也会执行不到，因为comp=null也就是没有组件被选中，也就没有悬停事件了，自然不会换图。这会需要细分一下拖拽和点击才能处理好，暂时先这样(毕竟touch的drag和down有时差不多，区分不好会产生类似闪烁的感觉，所以暂时先不处理了。其实不处理从逻辑上讲也是没错的，毕竟触屏本来也没有鼠标悬停事件……)。 bug已经修复，目前您可以java文件夹下的jar获得，等0.5正式发布后我会同步到maven。