Version 1.05 released. -Random number generator is now seeded upon startup instead of each time a randomizer is chosen (doesn't really matter anyways though). -Selecting bastet randomizer now correctly tells you that hold is disabled. -A, S, or D in big mode now act as F. Similarly, L and ; act as K. In 40-key mode, this works for Z, X, C, Q, W, F, 1, 2, 3, ., /, O, P, 9, 0 as well. -Fixed a bug that would potentially cause a crash upon shutdown. -Increased width of numerical display fields, and capped TPM display so the maximum TPM is 9999999 (Good luck hitting it). -Switched S and Z colors to fix SRS piece appearance. -Game keys are now fully remappable by editing keyblox.ini (see the "Keyboard Remapping" section at the end of the readme). -New input type, 40-Key-Inverse, is the same as 40-Key but with upper and lower rows swapped. -Added a symlink to the /Applications folder in the OS X .dmg bundle.
sorry for posting a really err.... annoying? feature request but Your controls use a "rotate piece z-ways(0, clock, anti, double), then move piece such that (left/mid/right) part of the piece is in y(0-10) column" however Typingtetromino uses a "press left/right x times, followed by y rotate" Your control system is easier to learn (e.g. for sz rotations q/z, w/x, e/c etc are the same) however typingtetromino's system is more....... true to the original concept. i guess. i'm not saying implement it (its probably annoyign to do it) but yeah.
i...don't really understand what you're saying. It sounds like you might be referring to the positioning of the pieces, in which case you should try the Center-Aligned placement system, as it matches TypingTetromino. With 40-key control and Center-aligned, you should be matching typingtetromino exactly. Unless you're talking about how typingtetromino has a "ghost" piece, which IMO is just plain silly.
ok i'll try that. i thought they mis-matched. in fact i'm pretty sure they do indeed mismatch. Also, bag seems to be broken. i was stacking for a tsd and it took me more than 15 pieces to get a T. is it bag of 7 or bag of 14? or not even bag :/ Edit: just checked -> you (Seem to) process rotation before movement. TypingTet processes rotation after movement. For example, in 40 key center aligned Keyblox, hit 'Z' with an I tetromino. Do the same with typing tet. different results. regardless, processing rotation before movement makes keyboard much easier to learn. for the pieces "I/S/Z" you only have to learn 20 keys out of the 40 available, instead of 23 keys.
yes, the I piece is the only one that differs. It's not really that I process rotation before movement; I just didn't have the cw orientation of an I piece shifted over one, as I thought that was really unintuitive.
[noparse]Process: KeyBlox [28906] Path: /Applications/KeyBlox.app/Contents/MacOS/KeyBlox Identifier: KeyBlox Version: ??? (???) Code Type: X86-64 (Native) Parent Process: launchd [89] Date/Time: 2010-05-20 22:22:51.097 -0400 OS Version: Mac OS X 10.6.3 (10D573) Report Version: 6 Interval Since Last Report: 600091 sec Crashes Since Last Report: 3 Per-App Crashes Since Last Report: 3 Anonymous UUI 3A0195C6-7CE5-46EB-B055-A06A4581803B Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Dyld Error Message: Library not loaded: @executable_path/../Frameworks/SDL_ttf.framework/Versions/A/SDL_ttf Referenced from: /Applications/KeyBlox.app/Contents/MacOS/KeyBlox Reason: no suitable image found. Did find: /Applications/KeyBlox.app/Contents/MacOS/../Frameworks/SDL_ttf.framework/Versions/A/SDL_ttf: no matching architecture in universal wrapper /Applications/KeyBlox.app/Contents/MacOS/../Frameworks/SDL_ttf.framework/Versions/A/SDL_ttf: no matching architecture in universal wrapper Model: MacBook3,1, BootROM MB31.008E.B02, 2 processors, Intel Core 2 Duo, 2 GHz, 1 GB, SMC 1.24f2 Graphics: Intel GMA X3100, GMA X3100, Built-In, 144 MB Memory Module: global_name AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8, Broadcom BCM43xx 1.0 (5.10.91.27) Bluetooth: Version 2.3.1f4, 2 service, 2 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Serial ATA Device: FUJITSU MHY2080BH, 74.53 GB Parallel ATA Device: MATSHITACD-RW CW-8221 USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8501, 0xfd400000 USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.), 0x0229, 0x5d200000 USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0x5d100000 USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8205, 0x1a100000[/noparse]
argh...okay, i'll try and look into it. i changed my OS X build chain slightly (got my own macbook instead of having a friend compile for me), so that probably did it.
Multiplayer is still a loooong ways off, assuming I ever do decide to implement it (there are many other things which take priority, including fixing the borked OS X version and replay support), but that doesn't mean I can't start speculating at what would be good for multiplayer modes. Obviously you can't have TDS-style garbage with deep drop...xD. So you could either have very randomized garbage (a la BlockBox), or just disable deep drop altogether. Also, I'm thinking T-spins don't really make much sense anymore What about multiplayer cooperative modes? Both players on the same 10x20 board? xDDD
Note: version 1.05 of KeyBlox has a bug where the manual screenshot feature doesn't work. This will be fixed in the next release, but for now either rely on the auto-screenshot feature or use printscreen.
Oh. @Caithness, I just realized what I think caused the error for v1.05. Will try and fix it soon-ish.
Version 1.06 released. This should fix the F2 screenshot key not working, and also hopefully the OSX version.
hey kirby i was wondering if u could explain how ur bag randomizer works.. (it doesnt seem to be 7 bag all the time)
I'm terribly insecure about my own code. Code: /* bagrandomizer.cpp Implements the 7-bag randomizer. */ #include "bagrandomizer.h" #include <string> //default constructor -- initializes the bag history BagRandomizer::BagRandomizer() { //init bag history reset(); } //returns the number of remaining pieces in the bag int BagRandomizer::pieces_left() { int result = 0; for (int i = 0; i < NUM_PIECES; i++) { if (bag[i]) result++; } return result; } //resets the bag history void BagRandomizer::reset() { for (int i = 0; i < NUM_PIECES; i++) bag[i] = true; } //generates a new random piece and sets piece->type to that piece, updating the history accordingly //note: this relies heavily on the defines in piece.h to work. void BagRandomizer::get_piece(Piece *piece, GameState &gameState) { int pieceNo = rand() % pieces_left(); //random, from 0 to numpieces-1 int index = 0; //go to the pieceNo'th piece remaining in the bag for(;;) { if (bag[index]) pieceNo--; if (pieceNo < 0) break; index++; } //remove from bag bag[index] = false; //refill bag if empty if (pieces_left() == 0) reset(); piece->type = index; } std::string BagRandomizer::get_name() { return BAG_RANDOMIZER_NAME; }
I suppose I could install Rosetta, but wouldn't it be more ideal to have it run in x86 natively instead of (I assume) being converted to PPC and then back again?
i'll read over that bag code when i get back from work (8 hours from now). It seems right from first glance but i implemented it a more naive, inefficient and easily understandable way. but yeah theres a glitch either relating to bag or double-hold (hit hold 4 times at beginning of game then drop 7 pieces)
