Yes, you could create a skin to make the window size smaller. Check the "Skinning" section of LJ's included Readme.html file: Code: wndW=length Sets the width of the game window in pixels. wndH=length Sets the height of the game window in pixels. Also, depending on window size, you may need to create or resize the ljblocksSega/ljblocksSRS and ljconnSega/ljconnSRS block images with smaller blocks, and edit your ".Skin" definition file: Code: blkW=length The width in pixels of each block in the ljblocks and ljconn, if it is not 24 pixels. blkH=length The height in pixels of each block in the ljblocks and ljconn, if it is not 24 pixels. This is allowed to differ from blkW
I don't know if someone has mentioned this.. But I found a bug in replays. Let's take a game I've played. It says after I'm finished "Pressed 470 keys (4.65/piece)" and that is written to lj-scores.txt too. If I play the replay of the very same run, everything is correct in the statistics, except that it says "Pressed 360 keys (3.56/piece). Here's the replay: http://upload.meroigo.com/lockjawreplay ... -07-15.ljm It's the same in every game and replay. I think it might have to do with my strange wannabe-like-Texmaster configuration. =P Here's a screenshot of my key config: http://upload.meroigo.com/ljkeys.PNG ... The ones marked with blue are the ones I use in play. (Note that I don't use Hard drop, I use Alt. Firm Drop instead and then locks the piece with Soft Drop)
It would be cool if there was stats for how many times you used Hold in a game, that is shown among how many lines, keypresses etc in the stats after a game. That way when people share their stats when posting a record, if they used Hold, you can see how much they needed to use it.
Which inputs should cancel ARE? I'm guessing DAS charging shouldn't, but which should? And I found this on Slashdot today: I've seen the effects of "reduced thoroughness of testing" due to interactions between options, when tiny well widths caused an instant game over in Tengen rotation due to the I spawn point overlapping the right wall, and deep drop crashed on Rich Nagel's copy of Windows 98 due to different behaviors in uninitialized memory.
rotation, left/right movement, hard drop, and locking (in 20G) inputs all cancel ARE in Heboris when playing with DTET rotation system, while soft drop and hold do not. however, it seems you must manually lock the current piece to be able to cancel ARE for the next piece. as far as DAS charging goes i guess it's more advantageous speedwise to get the piece moving right away, as long as your auto-shift rate is fast enough. the ability to make the piece spawn how and when you want it to gives you a strong feeling of control, and allows you to get into a rhythm where everything is happening at a pace that makes perfect sense to you, whether you're playing slow or fast. in case you can't tell, i really like ARE canceling. a lot. if you think it would add more confusion and bloat though, then it could be left out, as it's not as essential as some other options. t'would be quite the pity though i say...i say indeed. incidentally, DRS also allows you to cancel line clear delay. edit: if anyone is trying DRS in Heboris make sure you're playing properly (on a keyboard ) with 8-way input on. this allows initial left/right before you've released the locking key.
If left/right movement cancels the ARE without charging the DAS then that'd mean you're having to use up DAS charging time when the piece is active, which would kill you for fast lock delays. Or is that solved with the last sentence of your post?
the only thing i can assume is the DAS must be fully charged as the piece spawns when you use initial left/right, because i just set all the delays to 99 frames but was able to play as fast as normal. i also tried setting the lock delay at 3 frames, DAS at 99, and ARE at 99, and even with "INIT LR MOVE" off the pieces were sometimes shifting two columns before i manually locked. with these settings it was easy to tell ARE was being canceled (99 frames is noticeable) so the only explanation is that they were shifting two columns if i manually locked after two frames (if the lock delay had expired, the ARE for the next piece would've been un-cancelable, and there would've been that ~1.5 second pause before it spawned).
Bug: Replays do not record correctly when Hard and Soft Drops share a key, despite functioning in-game. My current quick fix was to set Soft Drop to K. If possible, it would be nice to have the option to entirely disable an input.
On 9G autorepeat + 20G gravity, Lockjaw does this: http://zeta.hypersector.com/Tools/Tetri ... BT3cTZBAAA But shouldn't this happen instead: http://zeta.hypersector.com/Tools/Tetri ... Bb3cbdBAAA
It follows an ordering identical to that of TGM for all movement within a frame: Hold Rotation Shifting Gravity Lock So if you have >1G DAS, TGM ordering prescribes the following events in one frame: O piece is not rotated O piece moves all the way to the right, up to 9 cells O piece moves down, up to 20 cells
sure, that works in TGM because the DAS is never greater than 1G. but with 20G gravity in Lockjaw, if the player can choose sideways speed greater than 1G, shouldn't gravity take effect after each column shifted, even if that means looping steps 3 and 4 (x) number of times? for the sake of predictability and playability, a 20G player relies on the piece falling whenever it can, regardless of the sideways speed.
Gravity every shift doesn't sound right either, or something like 1G would look bizarre. You want to apply up to the current gravity's limit in a given frame. So, say, at 5G you'd apply gravity every shift until 5Gs of gravity had been given.
I dug up the 180 degree kick tables if you ever want to implement them. Code: //For every piece but I int 180KickTableOthers[11 * 2 * 4] = { 1, 0, 2, 0, 1, 1, 2, 1, -1, 0, -2, 0, -1, 1, -2, 1, 0,-1, 3, 0, -3, 0, // Initial SRS orientation going to initial SRS orientation rotated twice. 0, 1, 0, 2, -1, 1, -1, 2, 0,-1, 0,-2, -1,-1, -1,-2, 1, 0, 0, 3, 0,-3, // Initial SRS orientation rotated CW going to initial SRS orientation rotated CCW. -1, 0, -2, 0, -1,-1, -2,-1, 1, 0, 2, 0, 1,-1, 2,-1, 0, 1, -3, 0, 3, 0, // Initial SRS orientation rotated twice going to initial SRS orientation. 0, 1, 0, 2, 1, 1, 1, 2, 0,-1, 0,-2, 1,-1, 1,-2, -1, 0, 0, 3, 0,-3 // Initial SRS orientation rotated CCW going to intial SRS orientation rotated CW. }; //For I int 180KickTableI[11 * 2 * 4] = { -1, 0, -2, 0, 1, 0, 2, 0, 0, 1, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, // Initial SRS orientation going to initial SRS orientation rotated twice. 0, 1, 0, 2, 0,-1, 0,-2, -1, 0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, // Initial SRS orientation rotated CW going to initial SRS orientation rotated CCW. 1, 0, 2, 0, -1, 0, -2, 0, 0,-1, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, // Initial SRS orientation rotated twice going to initial SRS orientation. 0, 1, 0, 2, 0,-1, 0,-2, 1, 0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0 // Initial SRS orientation rotated CCW going to initial SRS orientation rotated CW. };
it could work like that, or 1G of gravity could be subtracted after each failed attempt at gravity, if you want shift and gravity to take turns within a frame when sideways speed is greater than 1G. in these examples the piece has landed prior to the frame shown: O piece, 1G gravity, 9G sideways O piece, 2G gravity, 9G sideways O piece, 3G gravity, 9G sideways I piece, 2G gravity, 9G sideways and i think you get the idea now. of course this is just one way to handle sideways speed > 1G. this would require that "instant" gravity be greater than 20G for the piece to always fall as far as possible in a given frame in every possible situation though. a simple workaround for that would be to replace 20G with 29G. edit: the 3rd example is incorrect. the remaining gravity should be used before another shift is attempted once the piece falls in the hole. in other words the piece should fall as far as possible until gravity fails or there's no gravity remaining. if gravity is used and then fails within one column, only the amount used should be deducted from the allowed gravity for that frame with no additional deduction from the failure. edit2: under a system like this, shifting G should not be deducted from a shifting failure IMO, but should continue to attempt shifts up to a max of 9 successes. this would allow true far left/right single frame shift to still work under any stack condition, regardless of what happens with the gravity. edit3: and the reason i disagree with allowing the max possible gravity to be persistent within a frame is that if you had an I piece vertical against the left wall, with a perfectly flat stack and 1G gravity, and shifted it with 9Gs of force to the right wall, it just doesn't seem correct that it would fall into the 9th column if it could. but if gravity were pulling at an equal force i think it should fall there. edit4: i just can't leave this alone sub-20G gravity really presents a tough situation. maybe the piece shouldn't fall more than one row before attempting another shift? after all, if the shifting speed is greater, it shouldn't allow the piece to drop more than one row at a time without another shift attempt. but if you make it that way, 20G will still be broken. maybe shift and gravity should take turns (1 cell left/right, 1 cell down) until the allowed gravity has been used, unless the gravity is instant, in which case the piece attempts to fall 20 rows after each shift?
for G greater than or equal toshift rate, you shouldnt' skip over a hole. for G less than shift rate, you should.
but how far should it fall before shift is attempted again, when sideways speed is 9G? as far as possible (i.e. 5 rows with 5G, 10 rows with 10G)?
a couple bugs found while using these settings: speed curve = rhythm 20G max entry delay = 0ms hold piece = on, empty DAS = 16ms/1G initial movement = off allow diagonal motion = on (shouldn't matter because i wasn't manually locking while doing this testing) 1. pressing only hold (or hold + whatever) at game start sometimes makes the 1st piece go to hold, 2nd piece lock, and 3rd piece become active. restarting the program fixes this temporarily. 2. i made a fumen for this one. don't mind the previews; everything is explained in the captions and shown in the well: link it seems the piece coming out of hold is behaving as if initial movement is on. note that the S piece (not pulled from the hold box) in the example i gave acts correctly.
