1 Jun 2007 21:11
2 Jun 2007 01:07
[Bug 378] Sprite Editors Forget Data After Pasting
<Bob-bugzilla <at> HamsterRepublic.com>
2007-06-01 23:07:04 GMT
2007-06-01 23:07:04 GMT
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=378 ------- Comment #3 from mystah_b <at> hotmail.com 2007-06-02 07:07 ------- (In reply to comment #2) > (In reply to comment #1) > > This sounds almost exactly the same as bug 363, which was fixed last saturday. > > Is what is the date on your copy of custom.exe? > Umm...probably last friday. Which is kind of funny 'cause I've been meaning to > post this bug for over a month. I think my file is from the 25th. I'll check. I checked. It was definitely from the 25th. Sorry to post a falacious bug here! -- -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
2 Jun 2007 01:27
[Bug 363] Copy pasting in sprite editor doesn't save
<Bob-bugzilla <at> HamsterRepublic.com>
2007-06-01 23:27:09 GMT
2007-06-01 23:27:09 GMT
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=363 Bob <at> HamsterRepublic.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mystah_b <at> hotmail.com ------- Comment #3 from Bob <at> HamsterRepublic.com 2007-06-02 07:27 ------- *** Bug 378 has been marked as a duplicate of this bug. *** -- -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
2 Jun 2007 01:27
[Bug 378] Sprite Editors Forget Data After Pasting
<Bob-bugzilla <at> HamsterRepublic.com>
2007-06-01 23:27:09 GMT
2007-06-01 23:27:09 GMT
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=378 Bob <at> HamsterRepublic.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Comment #4 from Bob <at> HamsterRepublic.com 2007-06-02 07:27 ------- *** This bug has been marked as a duplicate of bug 363 *** -- -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
2 Jun 2007 07:56
Keyval
Ralph Versteegen <teeemcee <at> gmail.com>
2007-06-02 05:56:09 GMT
2007-06-02 05:56:09 GMT
I'm now regretting the behaviour of keypressing polling. Namely, that it isn't possible to distinguish between a real new keypress and one due to key repeat. Currently, for each key, there are 2 bits in the keyval array: bit 0: key is currently held down bit 1: new keypress/key repeat How about changing this, so that there's a 3rd bit which is on exclusively for new key presses, while changing bit 2 to key repeat only. Then existing uses "keyval(x) > 0" and "keyval(x) > 1" will be perfectly fine, and you can use "keyval(x) > 3" if you don't want repeating. I want to change this for scripts as well (actually the only reason), though for extra safety, if anyone uses "keyval(x) = 3" or something, current games could call a version of keyval which merges bits 1 and 2 together. Objections? TMC
2 Jun 2007 08:23
Re: Keyval
David Gowers <00ai99 <at> gmail.com>
2007-06-02 06:23:31 GMT
2007-06-02 06:23:31 GMT
CRUFT, I say.
On 6/2/07, Ralph Versteegen <teeemcee <at> gmail.com> wrote:
CRUFT, I say.
Is there any reason why bit 1 can't remain as it is? In either case, you would still have to check both bits 1 and 2 to determine whether a keypress was new or repeated.
I'm now regretting the behaviour of keypressing polling. Namely, that
it isn't possible to distinguish between a real new keypress and one
due to key repeat.
Currently, for each key, there are 2 bits in the keyval array:
bit 0: key is currently held down
bit 1: new keypress/key repeat
How about changing this, so that there's a 3rd bit which is on
exclusively for new key presses, while changing bit 2 to key repeat
only. Then existing uses "keyval(x) > 0" and "keyval(x) > 1" will be
perfectly fine, and you can use "keyval(x) > 3" if you don't want
repeating.
I want to change this for scripts as well (actually the only reason),
though for extra safety, if anyone uses "keyval(x) = 3" or something,
current games could call a version of keyval which merges bits 1 and 2
together.
Objections?
TMC
CRUFT, I say.
Is there any reason why bit 1 can't remain as it is? In either case, you would still have to check both bits 1 and 2 to determine whether a keypress was new or repeated.
_______________________________________________ ohrrpgce mailing list ohrrpgce <at> lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
2 Jun 2007 09:15
Re: Keyval
Ralph Versteegen <teeemcee <at> gmail.com>
2007-06-02 07:15:12 GMT
2007-06-02 07:15:12 GMT
On 6/2/07, David Gowers <00ai99 <at> gmail.com> wrote: > CRUFT, I say. > > > On 6/2/07, Ralph Versteegen <teeemcee <at> gmail.com> wrote: > > I'm now regretting the behaviour of keypressing polling. Namely, that > > it isn't possible to distinguish between a real new keypress and one > > due to key repeat. > > > > Currently, for each key, there are 2 bits in the keyval array: > > bit 0: key is currently held down > > bit 1: new keypress/key repeat > > > > How about changing this, so that there's a 3rd bit which is on > > exclusively for new key presses, while changing bit 2 to key repeat > > only. Then existing uses "keyval(x) > 0" and "keyval(x) > 1" will be > > perfectly fine, and you can use "keyval(x) > 3" if you don't want > > repeating. > > > > I want to change this for scripts as well (actually the only reason), > > though for extra safety, if anyone uses "keyval(x) = 3" or something, > > current games could call a version of keyval which merges bits 1 and 2 > > together. > > Objections? > > > > TMC > > CRUFT, I say. > > Is there any reason why bit 1 can't remain as it is? In either case, you > would still have to check both bits 1 and 2 to determine whether a keypress > was new or repeated. Currently: To check for a keypress: "keyval(x) > 1" To check for a new keypress, ignoring repeats: you have to record the last value of keyval and check if it was 0, and is currently > 1 With change: To check for a keypress: "keyval(x) > 1" To check for a new keypress, ignoring repeats: "keyval(x) > 3" Only people concerned with the difference between new presses and repeated key presses (a subset of the people using keyval instead of keyispressed in their scripts) need care. As long as everybody writes "keyval(x) > 1" instead of "keyval(x) == 2 || keyval(x) == 3", there won't be a difference.
2 Jun 2007 12:24
SVN: teeemcee/1117 Finished bug 322 fix by changing the z sort (it's now insertion, twice+
<subversion <at> HamsterRepublic.com>
2007-06-02 10:24:17 GMT
2007-06-02 10:24:17 GMT
teeemcee 2007-06-02 03:24:17 -0700 (Sat, 02 Jun 2007) 254 Finished bug 322 fix by changing the z sort (it's now insertion, twice+ as fast and stable) As a side effect, the Beam attack animation always displays the same now; the front-most sprite of it used to display randomly either in front or behind the beam. --- U wip/bmod.bas U wip/subs.bas U wip/whatsnew.txt
2 Jun 2007 14:27
Re: SVN: james/1116 Avoid confusion for linux users unfamiliar with the ohr's odd build syst
Ralph Versteegen <teeemcee <at> gmail.com>
2007-06-02 12:27:19 GMT
2007-06-02 12:27:19 GMT
On 6/2/07, subversion <at> hamsterrepublic.com <subversion <at> hamsterrepublic.com> wrote: > james > 2007-06-02 03:11:14 +0800 (Sat, 02 Jun 2007) > 75 > Avoid confusion for linux users unfamiliar with the ohr's odd build system > --- > U wip/makefile > We should fix it; personally I find makegame.sh a lot more to type than make game.
2 Jun 2007 20:20
[Bug 322] Z position of enemies in battle inconsistent in custom and game
<Bob-bugzilla <at> HamsterRepublic.com>
2007-06-02 18:20:13 GMT
2007-06-02 18:20:13 GMT
http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=322 teeemcee <at> gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #2 from teeemcee <at> gmail.com 2007-06-03 02:20 ------- Fixed r1117, also making the appearance of attacks like Wave predictable. -- -- Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
RSS Feed