neilo 2015-04-21 09:19
Will play later, but I've built it up for Linux for ya and had a quick look at the bugs in valgrind. See #ludumdare, I left messages with yaib :)
https://www.dropbox.com/s/m1lbkaf3o2trf1f/CommanderStitch_LD32.zip?dl=0
Foon → Ludum Dare Explorer → LD32 → Ursplaticus
| Category | Rank | Score | Count | |
|---|---|---|---|---|
| Coolness | 2469 |
Will play later, but I've built it up for Linux for ya and had a quick look at the bugs in valgrind. See #ludumdare, I left messages with yaib :)
https://www.dropbox.com/s/m1lbkaf3o2trf1f/CommanderStitch_LD32.zip?dl=0
I'm not able to rate the game seeing how I can't play it. But i thought I could tell you the reason that the game runs so much faster in the build version is that you have not limit how many updates the computer can do per CPU clock cycle (this is a problem with older games on newer computers as well) becouse the computer can do how many updates it wants per clock cycle if you don't limit it then the better your CPU is thje faster the game will run (in the fast forward faster way). The way to prevent this is to usuapy have a timer that updates every update and everytind else in a "if" statment for example(using psudo code):
mTimer = 0;
mTimerlimit = 0.1;
void update()
{
mTimer += time since last update; (Time.deltaTime in unity)
if(mTimer > mTimelimit)
{
Do the normal update
mTimer = 0; -Important, otherwise it will always update anyway.
}
}
I hope this helped.
I think the start bug is fixed.
love the mouse particles