TinyRivers(beta#2) need linux/mac testers :)

tactic1: don’t use a graphics tablet (since they skid, and it’s easy to mis-select - hence my bitter comments earlier). Although I can even now get sub-40s easy enough with a tablet…should be easy for you mousers :stuck_out_tongue:

tactic2: if you ever find yourself looking for tiles to choose for more than a second, give up. Hit r and try again. Basically, if you have time to realise you’re looking, you’re going too slow and will never hit 30 s. You soon get the hang of just going from one to the next without pausing for thought.

tactic3: go for all the obvious ones first, wherever they are (i.e. the adjacent pairs).

tactic4: think of the board as a being full of holes (where you’v removed stuff) which you’re trying to link together; when choosing two of three identical blocks, pick the pair that links two holes, or widens the gap - this increases your chances of finding more new pairs.

Start in the centre, and work your way out?

Kinda. It’s biting through (from one side - usually top or bottom) plus planing ahead (on crack) in order to keep the distances small. After a while you’ll instictively recognice pattern and dismember 'em automatically. It’s similar to the “sacrifice” moves in tetris (which look plain silly at first for the untrained eye).

Well, hard to explain… it looks like this:

xxxxxxxxx xxxxxx__x xxxx_____ 
xxxxxxxxx xxxxx___x xx_______ 
xxxxxx_xx xxxxxx___ _________

So… it’s actually the other way around. Small surface. Small enough to remember the key tiles. Small enough to have everything in reach and of course it’s easier for the brain to check for matchable tiles then :slight_smile:

Just play straight ahead - there’s no way back. The only thing you need to care about are 4 tile deadlocks(*) others occur rather rarely.

(*=12\n21)

The biggest deadlock I’ve seen so far was build out of 10 tiles and it took me more than 15 seconds to realize that it’s really a deadlock :wink:

(hope that makes some sense)

Soo adictive… but it seems to have a memory leak - I played for far too long on Win Xp with JRE 5.0 beta 3-b57

and it was taking up over 200 MB of memory and the system started to act funny. Looks like it could be a bug in the JRE…

36.622, w000h000! =)

/me wonders why the ceiling is blinking red at the moment :S

[quote]Soo adictive… but it seems to have a memory leak - I played for far too long on Win Xp with JRE 5.0 beta 3-b57

and it was taking up over 200 MB of memory and the system started to act funny. Looks like it could be a bug in the JRE…
[/quote]
How can that be? :o

Isn’t the default max heap size somewhat like 64mb? Kinda sounds like that the GC never kicked in.

Well, there are several rather silly spots. Eventually that behaviour will disappear after refactoring.

WHERE IS TEH FLUFF!?

Here ;D

791bytes image data there… and it looks so cute in animation :slight_smile:

Heh… the code is so goddamnugly. It’s really a bad idea to call your timer flags t1, t2, t3 and t4… the horror… zombie vars all over the place. Heh I really like search&replace :wink:

So… yea I’m redoing some of the graphics, because they looked a bit off. Especially that main menu thing. Thought it looked great back then, but that one piece metal-ish look… bwuergh. Plain silly… oh and the edges… embrassing. Together with that zoom feature everything left is just pixel mud.

Dunno when it’s done, because I schedule only leftover time for that project, but there aren’t that many things left. Oh well, it already took longer than expected (I blame the zombies ;D).

How can I run it at 1x, everytime I run it, its always 3x and the graphics are so dam pixelated at that level.

DP

You can change the zoom factor with F1-F4. I think I’ll use 1x as default again and eventually store that somewere (together with the highscore).

I suspect it was leaking memory outside the Java heap. For some reason I suspected it was related to the playing of sounds… but I don’t know why - it is just a wild guess.

Just played around with this some more - I can repeat the lock up - with large memory useage. The app stops responding to clicks, but if I move the window around it repaints properly. Otherwise it sits using 0 CPU… This time the memory usage is about 157MB. The display was in 3x mode while I was playing. It seems that after ending a game you can at first click the mouse to get back to the menu, but then after a few games that stops working and I have to hit ESC to get to the menu after a game.

[quote][…]It seems that after ending a game you can at first click the mouse to get back to the menu, but then after a few games that stops working and I have to hit ESC to get to the menu after a game.
[/quote]
That’s the broken flow (which happens if your score isn’t good enough for the highscore). It’s already fixed in my local version for a while.

However, that leak error is pretty weird. Sounds are allocated once on the java side and I don’t see that behaviour on my machine.

You can try this build. The flow error is fixed there and it’s refactorized. Would be good to know if that leaking still occurs.

I haven’t had a chance to try again on Windows yet. But this version is working on the Mac better than the previous version did. But after many games the application simply vanished.

The last console messages are:
wDeactivated
wActivated
wDeactivated
wActivated
new map
new map
[dirty]exit
java.lang.ArrayIndexOutOfBoundsException: 1736228936
at R.gameLoop(R.java:538)
at R.main(R.java:1469)
writeCFG
[clean]exit

Thanks for testing it again.

But this version is working on the Mac better than the previous version did.

Good. Seems like properly getting graphics and disposing em once per frame is the most correct way to do it (surprise surprise).

But after many games the application simply vanished.

Which is really odd. Especially at a spot were it just shouldn’t happen ever… I hadn’t changed anything there (or in related places), which could cause such a thing, but I’ll take a close look and check everything carefully. After all it’s highly unlikely that an error is hardware related.