LOCKJAW 0.44 is out 0.44 (2008-02-20) Computes the preview and hold offset of all pieces (was wkNextMove in <= 0.43) from the entry position of the I tetromino (was wkSpawnMove in <= 0.43). Kick tables have been inverted to a single struct per rotation system, for future loading from a file. SKIP_IF system for handling J/L/T exceptions in Arika is replaced with IF_NOT_CENTER: wall kicks are allowed if the free-space orientation overlaps any blocks other than in the center column. Options DAS doesn't repeat too fast, even on those systems where vsync() is a no-op (0.43 regression, reported by caffeine). This actually has the same root as the pause problem in all versions before 0.42: Windows Vista makes vsync() a no-op. Options DAS doesn't continue across page boundaries. GBA/DS: Options has new look. DS: Reads the touch screen and the X and Y buttons. Right now, touch isn't mapped to anything, but X and Y are Far Right and Far Left. In the past, I've developed two games that changed skin per section: Zeus (a Zoop clone developed as part of the freepuzzlearena project) and Luminesweeper. Zeus loaded all the backgrounds and music into RAM, but it used 256-color 320x200 pixel backgrounds and MIDI music because it was designed to run on the 25 MHz 486SX that I owned at the time. About ten backgrounds and half that many songs were put in a loop. Luminesweeper also loaded all the backgrounds and music into addressable memory, but that is the norm on the Game Boy Advance, where the entire program of up to 32 MB is loaded into a huge NOR flash or RAM before it starts. Another issue: multiplayer. Zeus was co-op: both players' clears subtracted from the number of blocks until section change. Luminesweeper, on the other hand, was a single-player game. As for the present project, I take it that automatic skin changes won't happen in multiplayer mode. They don't happen in Yoshi's Cookie for Super NES, Bust-A-Move for Super NES, or The New Tetris for N64. How are skin changes triggered in TGM games' 2-player modes?
in TAP doubles, the background changes after the first line clear from a player who has already reached 100 (not when that player initially reaches or surpasses 100), and again when a player makes a line clear after reaching or passing 200. there is no level stop at 99 or 199 though, so this may or may not be useful for you. there is a level stop at 299, and here the background changes when a player at 299 makes a line clear, reaching 300. edit: if a player reaches 100 or 200 with a line clear the background changes. if a player reaches 100 or 200 without clearing a line the background doesn't change. sorry for the confusion. i'm not really sure if a player can make a multi-line clear when level < 299 and reach 300, or if that line clear puts them at 299, requiring another line clear to reach 300. maybe someone here knows.
In other modes, a double made at 298 will move it to 300 (and the new section). I can't imagine Doubles being any different. As for the other modes, they appear to follow the highest section currently in play, based on a video I have from the meeting in July. Except for Verses mode, which has its own background in TAP.
Thanks for the info Actually, now that I think about it, the total of an average set of files for multiple-section backgrounds (and multiple-section music, if that feature is added), wouldn't be all that large. As an example, if a skin set consisted of ten 800x600 24-bit BMP format background images and ten 2MB OGG files, the total filesize (including two 24-bit BMP format LJBlocks and LJConn block image files) would only be 34,594,184 bytes... well within most PCs RAM specs (hehe, including my old archaic 486-DX100 <G>). I would suggest either not having background/music changes for multiplayer games, or simply triggering the change when one player advances to the next section (reguardless if the multiplayer game is co-op or vs). BTW (O.T.), have you had any progress, or have a possible ETA for "0096" in the "Bugs.txt" file?
Woot! Nice graphics for menus! And debriefing is now official on GBA! Good! Now... I'll wait for modefies for making the linux version easily. Thank you!
Hmm, mind if I have a few suggestions/bugs for the DS version? Suggestions: - A DLDI system, which would allow the following: -Changable BGM, block graphics -Post-game logging, like the PC version -Saving options and control settings, also like the PC version. -And a few non-DLDI related suggestions: -Customizable UI/game colors, though this is a pretty big stretch... it'd still be fun to see. -Allowing tabs and buttons to be pressed on the touch screen, maybe...? (Of course, we'd still need a non-DLDI build... but it'd be a nice touch since most cards support DLDI.) Bugs: - When an option is changed, the glowing color resets to its initial value. One of those tiny little things that just bothers you when you notice it. Sometimes the text overflows the box, causing a few "stray pixels" outside of it. All in all, excellent overhaul to the GBA and DS versions, especially to those of us stranded on portables due to crappy computers.
Especially compared to Tetris Zone. And I could give you an ETA for bug 0096, but you'd have to pay me for that information Isn't everything you need to make the Linux version install to /opt/Lockjaw already in ljpath.c since 0.43? Would they also be viable on the GBA version? In what format should custom background images and block graphics be stored? I don't know of any popular PC raster image formats that can represent the color model of the TurboGrafx-16, Sega Genesis, Super NES, and Game Boy Advance. In this model, each tile has only 15 colors, but each tile can draw from any one of several 15-color palettes. And in what format should custom background music be stored? On the PC, the vast majority of lj.exe is music decoders (DUMB and libvorbis), and download size is part of why I haven't done much on bug 0028 (NSF, SID, or SPC support). And how should skins, options, and debrief handle the surprise removal of the CF or SD card adapter? That is planned. I just need to sketch out the UI completely. The Game Boy Advance uses NOR flash cards. These support DLDI (through FCSR, which is analogous to GBFS), but only in read-only mode. I would have to use a single 32 KiB SRAM file, and I can't guarantee that the same file will work from version to version. This is intentional. Whenever a highlighted line item is drawn, the blink phase resets for better legibility. Compare this behavior to that of the insertion point in editable text areas in Windows XP Notepad, Windows Internet Explorer 7, and Mozilla Firefox 3 Beta 3 for Windows. If the insertion point is inside an editable text area, and you move the insertion point with the arrow keys, it becomes visible and stays visible as long as it is moving. Any idea which strings cause this?
Most of the changes would be for the DS version only, really, though I think the actual READING (BMPs, maybe?) would work on the GBA too. As for music formats, maybe libmikmod could be used to play back MODs of any format, like the PC version? And the strings: "Three opponents send you disabling attacks." The "s." overflows slightly, a minor annoyance... but I'm picky. ...That's actually the only string that has that problem. I guess I'm just overly picky, like I said. :/ Surprise removal of the card would be tough to deal with, though. Maybe loading everything into RAM? :/ It'd crash on post-game debrief, though, if it tried to write...
I've tried to compile the latest LJ under linux. (Sorry - I haven't seen the source package ) In ljpath.c, function ljpathSetRWFolder is uses the 'homeSubpath' and 'dstLen' variables but seems to be undefined. I've grepped a bit the sources but are only referenced in that functions. I'm doing something wrong?
i wonder if something can be "fixed," because it doesn't seem optimal. if you shift right, and without releasing that key, shift left, the piece goes left, and if you release left it goes back to the right. this feels correct to me. but if you shift left, and without releasing, shift right, the rightward shift is ignored until you release shift left. this means if you shift to the left wall then shift back to the right, you have to fully release shift left before the piece will go right. this behavior was in earlier versions of LJ too, so maybe it's always been that way. could this be changed in the next version tepples? edit: tepples, do you have any extra sounds bytes on your computer you could add to Lockjaw, without assigning them to anything? it would be nice to play around with them when modding, without breaking things that use those sounds. i would add my own sounds, but i don't want to stray from the original program that much.
And endure another round of "Why can't I use music composed by someone else, performed by someone else, and ripped from a CD", like what happened between 0.10 and 0.23? Got any ideas for a shorter wording? That was the solution for TOD on GBA. But I wonder how practical that would be with changes to the background image and music per section, as people are requesting for the PC version. This is physically impossible on a standard directional pad or joystick under the standard key mappings. Figure: What I use to test LJ's input processor (src/macro.c) I didn't test this situation for symmetry in part because I rarely play on a keyboard. There are NES and Super NES games that glitch even worse when the player presses Left+Right or Up+Down, such as the Zelda series. Fix off the top of my head, not tested: right should add left to repressKeys, and left should add right to repressKeys. There are three steps to adding a sound to the PC version: In lj.h, look for LJSND_ROTATE and add a line. In pcsound.c, look for playSoundEffects and add an if-then. In sound.dat using Allegro Grabber, create a new sound object and grab it from a wave. As for putting things into sound.dat myself so that you can play with them, I usually create my own sounds, and I don't have any idea what they should sound like or what they should be named unless I know what triggers playing them.
I don't think the wording would need any changing... perhaps either removing the anti-aliasing artifacts or making the text scroll a bit could work well.
poor style to start a sentence with numeric characters. what about "Three opponents send disabling attacks."
i get this: Code: src/ljpath.c: In function ljpathSetRWFolder: src/ljpath.c:110: error: homeSubpath undeclared (first use in this function) src/ljpath.c:110: error: (Each undeclared identifier is reported only once src/ljpath.c:110: error: for each function it appears in.) src/ljpath.c:111: error: dstLen undeclared (first use in this function) src/ljpath.c:104: warning: unused variable suffix when i try to compile it under linux any idea?
caffeine: Implemented. Thanks. Kesiev was the first to point out a few typos introduced during a refactor. In that function, do this: s/homeSubpath/suffix/g s/dstLen/PATH_MAX/g
