Release Puzzle Moppet

[ptitSeb]

This game use Irrlicht (with OpenGL-ES 1.1 Hardware acceleration) and OpenDE for physics calculation. ODE is not really Pandora Friendly, so game struggle a bit when many (like 10) crates are present in a level (for example level 2).

 

I fixed nub configuration like for an fps, so "mouse movement" in right nub, and "mouse button" in left nub (your nub configuration is restored at the exit).

 

A few screenshot more: 

 

History log

=========

 

 

Build 02

----------

• Corrected the restoration of nubs setting.

 

Build 01

-----------

• Initial build
• fixed (in startup script) Left nub to mouse button, Right nub to mouse movement
• No level editor for now.
• Overclocked to 800 MHz by default as some level (for ex. the #2) are heavy on CPU
• downsized some texture.
• should be slackware friendly

I am aware some level, like 2nd, are too slow. The CPU is the bottleneck in this game, not really the GPU. Most time is spent in ODE, doing the dBoxBox function, that handle Box on Box interaction (calculating points of contact between 2 boxes, normals of the forces, etc.). Standard optimization switches are not enough, some assembler or major refactoring of the function is needed here.

 

[CocoCreekFisherman]

This is a great game. I played to level 3 with no problems. A real gem.

I noticed no slowdown in level 2.

Thank you for this one!! 

 

[F_Slim]

Very nice game, looks like it has some Sokoban-elements. Controls are well chosen for the Pandora, but the Nub settings are not restored when quitting the game. Apart from that really great!

 

[ptitSeb]

Very nice game, looks like it has some Sokoban-elements. Controls are well chosen for the Pandora, but the Nub settings are not restored when quitting the game. Apart from that really great!

Hum, that's must be anoying (I didn't notice, this config is my default one). I'll do a repackage.

 

[ptitSeb]

Ok, update build on the repo that correctly restore the nubs setting. Sorry for that.

Build 02

----------

• Corrected the restoration of nubs setting.

 

[Magic Sam]

Hi ptitSeb

Thank you for this nice game !

Standard optimization switches are not enough, some assembler or major refactoring of the function is needed here.

There is an interesting article on Wikipedia about Collision detection and its optimization, I hope it helps....

EDIT: would using PAL be a good idea ?

From wikipedia here:

Scalable - The abstraction layer allows developers to run their code on handheld console platforms up to supercomputers.

EDIT 2: Bullet physics 2.80 features some NEON optimizations, could it be worth a look ?

Bye, Magic Sam

 

[ptitSeb]

Thanks MagicSam for all the links. I don't want to change the lib used for Physics, it's a big work... But I will take a look to see if I can spot some quickwin optim... But that PAL thingy looks really cool. I think I will at least compile it for next Code::Blocks

About Bullet and Neon, I have comiled latest Bullet from SVN. I didn't notice NEON here, maybe I will doublecheck, to make sure neon code is compiled (I have to mess a bit with the configure to make it compile, it just doesn't know linux-arm, just android-arm)...

 

[crow_riot]

never heard of PAL - from the description it's great stuff. something i could use for my work, too! :-D

 

[Magic Sam]

[BUMP]
Hi all !

@ptitSeb : one of your very first port has been updated recently

Puzzle Moppet - Package Details - repo.openpandora.org Repository of Software for the Open Pandora open source console - Games | Apps | Emulators

Repository of Software for the Open Pandora open source console. Upload, Download, Comment, Rate.

repo.openpandora.org

GitHub - karjonas/Puzzle-Moppet: A challenging 3D puzzle game

A challenging 3D puzzle game. Contribute to karjonas/Puzzle-Moppet development by creating an account on GitHub.

github.com

Would it be worth a (new) look ?

EDIT:

Manual - ODE

ode.org

Looks like there are some interesting options for ODE:

--disable-demos --without-x to let it compile on Mac OS X
--enable-double-precision enables double precision math
--with-trimesh=opcode use OPCODE trimesh support (default)
--with-trimesh=gimpact use GIMPACT trimesh support
--with-trimesh=none disable trimesh support

EDIT2: --disable-sse2 (in favor of FPU) could also come in handy I suppose

EDIT3: If I understand correctly, --with-trimesh=gimpact would in turn use Bullet, right ?

GIMPACT

gimpact.sourceforge.net

GitHub - bulletphysics/bullet3: Bullet Physics SDK: real-time collision detection and multi-physics simulation for VR, games, visual effects, robotics, machine learning etc.

Bullet Physics SDK: real-time collision detection and multi-physics simulation for VR, games, visual effects, robotics, machine learning etc. - bulletphysics/bullet3

github.com

It seems to be slightly newer than OPCODE:

OPCODE

www.codercorner.com

And I just grep'ed a fresh clone of the bullet repository, there are indeed several references to NEON in the code, whatever it means for our particular use case.

EDIT4: 7 years have passed, and I'm still bugging you with stupid questions

Cheers, Magic Sam
[/BUMP]

 

[DrasticNerd]

I've been playing this port for years. It's a beautiful little puzzler. It has a real "pick up & play" factor and is highly addictive in a "just one more level" type of way. It starts off deceptively simple then the difficulty ramps up. The game rates how well you completed each level so it is fun to replay beaten levels to see if you can refine your technique to reach a 'Perfect' rank.

Thanks @ptitSeb for bring this hidden gem to Pandora.

This game is available for free on PC, Mac & Linux. Download from the official site here.

 

[karjonas]

Hi ppl,

I saw that you found my repo on GitHub and I am happy to see people still play this game I just wanted to let you know that if you have any ideas for improving performance or have any issues/ideas/improvements in general please feel free to pm me or create a ticket!

Cheers

 

[Magic Sam]

Hi all,

@karjonas : thanks for joining the boards

Do you think building ODE with Gimpact / Bullet would help the game run more smoothly on our 10 years old handheld computer ?

Cheers, Magic Sam

 

[karjonas]

@Magic Sam - Thanks for the welcome I had a quick look at the performance and it does seem like the big expense is the collision between the movable boxes in the game. So using Gimpact/Bullet for the trimesh would make no difference since the expense is not in the trimesh collision. One thing that could help is making sure ODE is using single precision math, although I assume that is already the case. I think the best way to improve performance is to look in the game code itself, but this might be trickier of course. For instance, maybe one can ignore collisions between boxes with no velocity. When is the last time you built the game? There might have been improvements in ODE as well in the last 7 years.

Cheers

 

[Magic Sam]

Hi all,

@ptitSeb : any plans to bring this great game to the Pyra ?

Cheers, Magic Sam

 

[levi]

Damn, when I saw another thread started Release and started by Ptitseb I assumed he's ported it already!

 

[ptitSeb]

I have worked on Irrlicht engine. I'm more focussed on SupterTuxKar 0.8.1 and HCraft for now, but I'll try to check this one later (I think it want an older version of the engine).