敲了几晚SnakeGo, 原型出来了, 大家来看看不...

    不错, 这货就是---贪吃蛇...哈哈...别急, 这还是原型, 好玩的在后面呢...(以我敲字速度, 大约再等不到六个月应该可以完成了...)

    今天这里记录下使用LIBGDX过程中碰到的两个问题:

        1. 调整屏幕比例;

        2. 移动观察镜头;

一, 调整屏幕比例

    LIBGDX是跨平台的, 一大好处就是直接在PC上测试, 那是非常的方便, 但这有两个问题需要考虑, 一, 手机是1280x768, 但我PC只有1280x1024的, 而且真要开个跟手机一样大小的一样大小的屏幕, 那还怎么看log输出呢? 二就是不同的手机有着不同的分辨率, 长宽比也不一致, 那怎么保证图形不变形呢?

    这个问题不难解决, 只需要在屏幕尺寸发生变化时, 即resize()(第一次启动也会调用此函数)中, 重新调整镜头(Camera)的参数即可. 如下代码:

	@Override
	public void resize(int width, int height) {
		Vector2 size = Scaling.fit.apply(WIDTH, HEIGHT, width, height);
		
		camera = new OrthographicCamera(size.x, size.y);
		camera.update();

		batch.setProjectionMatrix(camera.combined);
	    
              int viewportX = (int)(width - size.x) / 2;
	       int viewportY = (int)(height - size.y) / 2;
	       int viewportWidth = (int)size.x;
	       int viewportHeight = (int)size.y;
	    
		Gdx.gl.glViewport(viewportX, viewportY, viewportWidth, viewportHeight);

		super.resize(width, height);
	}

    这里采用的是重新创建camera实例的方式, 另外用改变已有camera实例的参数方式也是一样的. 很简单, 而且这样一次就解决了上面两个问题 -- PC机上使用任何尺寸的窗口, 都可以获得跟设置等比例的窗口, 手机上亦是如此. 像I;P就是采用的这种方式来保持其在任意手机上都是1280:768的比例.

    这种方法只是改变了'视图'的大小, 但并不会改变其中的图形的大小, 这样为了保持图形显示比例, 需要在输出图形时做相应的比例放缩. 可以在resize()获得这个比例, 染在图形输出时使用这个比例.

              screenScaling = new Vector2((size.x / WIDTH), (size.y / HEIGHT));

              ...
              ...
              batch.draw(img, (- WIDTH / 2) * screenScaling.x, (- HEIGHT / 2) * screenScaling.y, WIDTH * screenScaling.x, HEIGHT * screenScaling.y);

二, 移动观察镜头

    在SnakeGo中, 为了不让Snake'跑出'屏幕, 需要镜头camera跟Snake本身保持'同步'移动, 这样看起来Snake保持在屏幕的中间, 但其它Object是移动的. 根据'相对运行'原理, 使整个看起来像是Snake在Object中穿行. 所以, 移动camaera是必须的, 代码也简单, 如下:

              ...
		final OrthographicCamera camera = game.getCamera();
		camera.translate(0.0f, 32.0f, 0.0f);
		camera.update();
		game.getSpriteBatch().setProjectionMatrix(camera.combined);
              ...

<----心烦意乱的分割线---->

    这几天在找工作, 前面去面了一次, 其中没一个App或者Game的问题, 倒全是C++相关的, 登时就傻眼了...虽说咱也是C++'出身'的(不然Blog也不会在这里不是), 但也许真的是'老'了, 才三年不用C++,竟然忘记的只剩下个auto_ptr了...更悲剧的是咱用的C++98标准已经变成C++11了, auto_ptr变成smart_ptr了...

    都说现在是个'跨界'的时代, 但咱这还没有跨界, 只是同行转个方向而已, 为啥就这么悲剧了...好吧, 估计学艺不精才是根本...

    同学"'大数据'的博士"周五来电, 问我要不要跟她一起做个'图像搜索', 有些犹豫, 要说三年前, 也许就干了, 但现在...再转次嘛...

    恰逢I;P敲完, 心烦意乱的一周, 只好赶紧抓起SnakeGo来, 夜夜疯敲, 来安抚砰砰躁动的心...是的, 至少敲字可以让自己平静些...

    吐槽而已, 这里想说 ---- 程序员们啊, 转行要趁着年轻赶紧啊...

    老爷子心不老, 依然在勤勤恳恳地敲着书和代码...没错, 就是source code. 像老爷子这样的老一辈会用电脑的都不多, 而我亲爱的老爷子那是会Turbo Basic的顶尖高手啊...每次想到这个, 内心都倍感自豪...

    当年的"窗口"编程极其繁琐, 如果不看看那一套<Win32 API大全>, 再加上个<Visual C++技术内幕>, 都不保证能敲个Window出来, 什么HWND, hInstance, 以及乱七八糟的各类窗口和消息的struct...反正我是早早就忘光光了...想想现在在的Android上弄个"窗口"出来, 那,那真是"太小儿科"了...

    呃, 跑远了...我意思是 ---- 老爷子止步于Windows编程, 各类代码全部运行在DOS下. 随着Windows的不断改进, 终于, Windows下再也不能运行老爸手中的无敌神器 -- Turbo Basic了...

    曾跟老爷子说过, 将他的代码都移至到Android上, 但老爷子不同意, 因为, 他老人家还要改些参数的, 改些参数, 些参数, 参数...看着老爷子在Win7上装个VM跑XP再打开Command窗口运行Turbo Basic, 甚是辛苦. 作为知原理, 会Google的程序员我来说, 帮老爷子弄个DOS虚拟环境来跑TB.EXE, 那是必须的...

    于是就有了下面的截图.

   DosBox