Tag Archives: 2d

（关于Moai，见我的上一篇文章。）

下面贴出在Moai Forum上我最近的两个问题帖。回答者都是Patrick，他是Moai引擎的领导者，同时也是’Zipline Games’的CTO。他似乎是个不错的人，在我每次贴出问题后，总是在最快的时间内解答。

1. Does MOAILayer2D only support 512 props maximumly?

http://getmoai.com/forums/moai-sdk-developer-support/does-moailayer2d-only-support-512-props-maximumly/

Me:

I was trying to put lots of props onto a layer with function MOAILayer2D:insertProp, but found that if I inserted more than 512 props, all the props will fail to render on the layer. Is 512 the threshold for a layer’s prop count? Why is it a restriction? 512 doesn’t suffice my need. If there did exist a restriction, Moai even didn’t tell me any info or warning about the number 512, it took me lots of time to detect the problem and the number… 🙁

Patrick:

Sorry you had to spend your time on that. I agree that we could emit better warnings for situations like that.

The 512 restriction is arbitrary. It’s the size of the buffer created on the stack to sort the prims. I can fix it for you in the next release – will grow the buffer dynamically instead. When I have time to add an option to disable sorting by MOAILayer2D, the buffer won’t be needed at all.

If you need a fix immediately and are building from source, you can go into MOAILayer2D and just change it to something else.

(512 props is a lot! Is this for a mobile game? Mind if I ask what you’re displaying? Depending on what it is, may be other ways I can help.)

Patrick:

OK. I removed MAX_RENDERABLES and now use a flexible size buffer to gather and sort the props returned from the partition. That will be in the upcoming release. Try it out and let me know.

If you run into stuff like this in the future (any kind of odd or mysterious behavior) please let me know and I’ll hop right on it. Would much rather deal with a few false positives than have you waste your time!

Me:

Thanks so much for your reply and help, Patrick.

I’m just new to Moai. I was generating and displaying a map (31×28 grids) with each grid empty or filled with a type of sprite (like a the Pacman game, each grid could be filled with a Wall or a Bean or …). So this is why I used so MANY props. Do you have some other way or suggestions for generating such kind of game maps, so that not that many props will be used?

As you’ve fixed this issue, so I’m looking forward to the next release. Thanks a bunch!

Patrick:

Absolutely. Check out MOAITileDeck2D and MOAIGrid. Any of the deck types can be used in conjunction with a grid, but MOAITileDeck2D is ideally suited. The grid draws with one transform (from the prop it’s attached to) and also gets viewport culled on a per tile basis. It’s ideally suited to tiled backgrounds. You will get way better performance and can also update the grid values at runtime or animate them using a MOAIDeckRemapper. Check out tilemap-animated for a sample. In the games we are working on in-house we have multiple layers of tilemap parallax drawing hundreds and hundred of tiles at really good frame rates. If you need to animate a tile flipping or rotating (like what happens to a block in a Mario game when Mario hits it with his head), just hide the original tile in the grid and replace it with a prop – you can use the same tile deck as the source for the prop.

Also, can’t say enough good things about Tiled (mapeditor.org). The latest version supports flip flags and can output its data as Lua tables you can then load in to Moai (with a little bit of work).

Always a pleasure to help out, so let me know if you have more questions as you go.

Me:

Oh, how stupid I was that I didn’t find these classes, I will try these MOAI classes later. THANK YOU!

2. Questions about MOAIAction:stop

http://getmoai.com/forums/moai-sdk-developer-support/questions-about-moaiactionstop/

Me:

I have some questions regarding the usage of MOAIThread and MOAIAction

Firstly check out the code snippets below.

MOAISim.openWindow ( "test", 320, 480 )</span>
viewport = MOAIViewport.new ()
viewport:setSize ( 320, 480 )
viewport:setScale ( 320, 480 )

layer = MOAILayer2D.new ()
layer:setViewport ( viewport )
MOAISim.pushRenderPass ( layer )

gfxQuad = MOAIGfxQuad2D.new ()
gfxQuad:setTexture ( "cathead.png" )
gfxQuad:setRect ( -64, -64, 64, 64 )

prop = MOAIProp2D.new ()
prop:setDeck ( gfxQuad )
layer:insertProp ( prop )

function moveThreadMain()
	movingAction = prop:moveLoc( 1000, 0, 100, MOAIEaseType.LINEAR )
	local x
	local y
	while ( movingAction:isBusy() )
	do
		x, y = prop:getLoc()
		print( "current x - " .. x )
		coroutine.yield()
	end
end

isCrossBound = false
function checkThreadMain()
	while ( true )
	do
		local x
		local y
		x, y = prop:getLoc()
		if ( isCrossBound == false )
		then
			if ( x > 20 )
			then
				isCrossBound = true
				movingAction:stop()
				print( "x after stop current frame - " .. x )
			end
		else
			print( "x after stop next frame - " .. x )
			break
		end
		coroutine.yield()
	end
end

moveThread = MOAIThread.new()
checkThread = MOAIThread.new()
moveThread:run( moveThreadMain )
checkThread:run( checkThreadMain )

I start and run 2 threads. The ‘moveThread’ uses MOAIAction to move the prop continuously and print its location each frame, while another ‘checkThread’ checks if the prop crosses some bound and if yes stops the moving animation with function MOAIAction:stop

But the result of MOAIAction:stop differs based on the launching sequence of those above 2 threads.

If I run ‘checkThread’ before ‘moveThread’, here is the result. MOAIAction::stop successfully stopped moving prop.

x after stop current frame – 20.099973678589
x after stop next frame – 20.099973678589

But if I run ‘movingThread’ before ‘checkThread’, I will get the following result, seems that animation will continue running for another frame

x after stop current frame – 20.099973678589
x after stop next frame – 20.199974060059

This really confuses me. Can anyone do me a favor to explain at which condition MOAIAction will run an additional frame after stopped, and when not? Is there a way to ensure that MOAIAction:stop will run no more frame no matter the running sequence of MOAIThread?

Patrick:

Just ran your code. It’s a legitimate bug in the way the MOAIAction update loop works. I’ve fixed it and checked it in to ‘master’ on moai-dev. We should have the next binary release out early next week.
Thanks for finding this!