Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Every time I fix or change something, I find something else to fix :)


major bugs:

printf/stdout not properly stubbed on release builds - can cause crashing [done]
menus need to override hw low detail modes [done]
fix level completion / intermission under double buffering [done]
status bar needs refreshed when shrinking from fullscreen back to window mode [done]
intermission screens need to override hw low detail modes [done]
game loading needs to override hw low detail modes [done]
statusbar remains on at level exit [done]


IKBD can lose sync / stuck keys [in progress]
IKBD erroneous scancodes with simultaneous keypresses [in progress]

RGB double line mode affects VBL (2 VBLs instead of one?) which disrupts audio etc.
can't yet draw non-postmapped textures as transparent midwalls (no path for stacked opaque surfaces)

minor bugs:

RGB double line mode only works in fullscreen for some reason, should work with statusbar up too
display reconfigure needed on exit from help screen
HD sky textures need same scaling fix as for standard sky mode
tearing/flicker at statusbar raster on VGA, final line of play area (ok on RGB). reduce window by 1 line.
V_DrawPatchFlipped not implemented yet (only used by original finale seq.)


essential work:

finalise video modes for RGB, VGA [80% - custom fullscreen VGA modes missing]
physics needs recalibrated for critical distance jumps
texture switches for sector floor/ceiling surfaces
scrolling textures need implemented
game save/load needs fixed & tested

important work:

low detail modes need implemented in display system [done]

low detail mode needs fat pixel path for all drawing methods on RGB [in progress]
reduce footprint of static buffers in bmengine + game [in progress]

plasma gun causes slowdown
mouse control poorly calibrated for play
some special shader fx need to be tied up
need option to generate cache for all graphics in WAD, to WAD-local cache dir (to prevent pauses when throwing switches etc)
generate cache dirname from PWAD hash, or IWAD hash if no PWAD
status bar doesn't work in Hatari - will need a special mode for it
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Fixed a few more bugs re: low detail modes on RGB.

More importantly, I have found a reliable way to cause those erroneous keyboard scancodes which interrupt gameplay (IIRC shoggoth noticed in an earlier test binary - the HELP screen would pop up randomly during play, and is normally bound to the F1 key).

This seems to happen by simply holding down LSHIFT+S+D together, in that order. I don't know if any other patterns cause it but that works every time. The bad F1 scancode comes directly from the keyboard data register so it's not a bug in the handler (I tried two different handlers, to no effect).

So this is some kind of bug in the IKBD hardware or software and probably needs to be dodged/worked around rather than fixed.

Unfortunately the help screen draws ON TOP of my scancode debugger so that foiled my debugging plan a bit. There's a small delay though so I can probably get some more info without changing things.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Yep the scancode debugger shows that LSHIFT+(S+D) often - but not always - produces scancode $3B (57) on a real Falcon, but not on the emulators.

Fun!

I find it interesting that nobody has noticed this until now :) including me.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Eero Tamminen »

Here's a GCC 2.x profile from TIMERBASE=1 timedemo, for all frames in the demo with latest BM code.

CPU side:

Code: Select all

Time spent in profile = 74.58885s.
...
Used cycles:
   8.71%   8.88%   9.38%   104231624 106298016 112239696   _BM_P_CrossBSPNode
   5.51%                    65959244                       R_AdvanceSurface_TMip2
   4.94%   4.99%  35.96%    59078436  59704684 430333788   _P_RunThinkers
   4.87%                    58251296                       R_AdvanceSurface_NMip0
   4.76%   4.81%  13.40%    56988600  57588136 160351216   _P_CheckPosition
   4.40%                    52701884                       R_AdvanceSurface_TMip0
   4.31%   4.36%   4.62%    51628540  52167524  55307540   _R_PointInSubsector
   3.47%                    41516348                       R_VisPlaneSkyShader
   3.24%                    38783240                       R_VisPlaneShaderWarp
   3.23%   3.26%   3.43%    38598416  39005132  41036300   stream_texture
   2.76%   2.79%   2.98%    32998356  33361984  35637392   _PIT_CheckThing
   2.74%                    32843824                       R_DrawTSurface_Masked2
   2.74%                    32784296                       R_VisPlaneShaderQuickMip
   2.61%                    31182524                       R_AdvanceSurface_TMip1
   2.34%   2.34%   2.34%    27954024  27954024  27954024   _BM_A_Mux3x2
   2.25%                    26936608                       R_AdvanceSurface_TMip3
   2.16%                    25887004                       R_BSPHyperPlane
   1.89%   1.91%   2.02%    22658032  22903920  24155212   _P_UpdateSpecials
   1.36%   1.38%   1.51%    16318684  16476712  18121212   _PIT_CheckLine
   1.29%   1.29%   1.29%    15495680  15495680  15495680   _BM_A_Mux2x2
   1.29%   1.31%   1.38%    15482068  15658224  16564508   R_ViewTestSpriteLines
   1.25%   1.26%  10.70%    14904796  15076724 128021756   _BM_P_CheckSight
   1.20%                    14344324                       R_AddLine_loop
   1.13%   1.13%   1.13%    13497444  13497444  13497444   _BM_A_Mux1x2
   1.12%                    13441688                       R_AdvanceSurface_NMip3
   1.07%   1.23%   1.31%    12833488  14687412  15625384   stack_visplane_area
   0.99%                    11905928                       R_SpriteColumnShader_Masked2
   0.95%   0.96%   1.08%    11416384  11540292  12915076   R_AddSpriteSpans
   0.94%   0.95%  14.62%    11271028  11389352 174894632   _P_Move
   0.93%                    11185508                       build_ssector
   0.91%                    10919236                       R_StackTransparentSurface
   0.84%   0.85%  15.60%    10105148  10212532 186694144   _P_TryMove
   0.74%   0.75%   9.97%     8856352   8942316 119308748   _P_LookForPlayers
   0.65%   0.65%   1.83%     7758356   7835804  21923024   get_ssector
   0.64%   0.65%   0.67%     7693624   7769104   8018228   R_SetSubSectorLuma
   0.60%                     7133728                       R_DrawTSurface_Masked1
   0.56%   0.56%  28.22%     6660016   6750368 337692960   _P_SetMobjState
...
Instruction cache misses:
  12.19%  12.25%  26.09%     2098636   2108368   4490868   _P_CheckPosition
   6.59%   7.03%   7.23%     1133740   1210756   1245208   _BM_P_CrossBSPNode
   6.42%   6.47%   6.57%     1105443   1114122   1131514   _R_PointInSubsector
   5.19%   5.25%  61.77%      893517    903910  10631927   _P_RunThinkers
   4.36%   4.38%   4.61%      750893    753538    793781   _PIT_CheckLine
   3.70%   3.72%  10.98%      637390    639963   1888975   _BM_P_CheckSight
   3.60%   3.64%   3.72%      619946    625945    640069   _PIT_CheckThing
   3.40%   3.41%   3.55%      584362    586339    610603   R_AddSpriteSpans
   3.10%   3.11%  29.46%      533943    535932   5071251   _P_Move
   2.33%   2.34%  50.56%      401860    403307   8702359   _P_SetMobjState
...
It changed a bit when enums were change to be 1-byte instead of 4-bytes.

DSP side:

Code: Select all

Used cycles:
  43.64%                  1044302940                       command_base
  20.34%  21.68%  21.68%   486758958 518912446 518912446   R_DoColumnPerspCorrect
   5.02%                   120221444                       ALGO_P_CrossBSPNode
   3.65%                    87336962                       R_VPRenderSky
   3.40%                    81342300                       R_VPLoadTexture
   3.18%   3.18%   3.18%    76131268  76131268  76131268   VPRenderSpanWarp
   2.80%                    67047180                       P_CrossSubsector_body
   2.48%   2.48%   2.48%    59358858  59358858  59358858   VPRenderSpanQuickMip
   2.06%   2.06%   2.06%    49345300  49345300  49345300   extract_subvisplane
   1.72%                    41115334                       R_DoColumnTextureUV
   1.68%                    40142446                       R_ViewTestAddLine
   1.06%                    25315654                       project_node
   0.91%   0.91%   0.91%    21873920  21884536  21884536   InterceptVectorsUF
   0.89%   1.11%   5.43%    21400702  26540968 129906396   AddLowerWall
   0.71%   0.85%  17.70%    16991240  20308094 423603158   AddMidWall
Attached is a callgraph of above. In that demo, column perspecting is mostly called from through midwall symbol, and a bit from lowerwall symbol.

Worst frame stuff with TIMERBASE=3 is probably more interesting though, even for GCC 2.x builds.
You do not have the required permissions to view the files attached to this post.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Thanks, it really did need re-profiling after all recent changes. I could easily have broken stuff after status bar work.

I have lost my ability to profile locally after moving machines but will restore it very soon to check all of this with gcc 4.6.4

BTW it didn't run for me with 1-byte bools. Some wad dir string stuff went crazy.

[EDIT]

..I mean its currently configured for 4-byte with a special type for 1 byte flags (as yet unused). If I change the default boolean to 1 byte, it won't run.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Eero Tamminen wrote:
DSP side:

Code: Select all

Used cycles:
  43.64%                  1044302940                       command_base
  20.34%  21.68%  21.68%   486758958 518912446 518912446   R_DoColumnPerspCorrect
Attached is a callgraph of above. In that demo, column perspecting is mostly called from through midwall symbol, and a bit from lowerwall symbol.
The perspecting routine is relatively expensive but I haven't worried too much about it because it always happens in parallel with column drawing, which takes longer. It's possible the cost does show for very short columns (steps?) and some other cases but I wasn't able to measure it for real when testing, despite trying a few times.

The alternative way to do it is use tan tables, but they are too big for the DSP so I have left it as it is. If I see the cost showing anywhere significant I might reconsider.

The floors are another matter - I found more efficient ways to do some of the floor calculation and perspecting while writing STRay so it could all be recrafted for more speed, but it's a big job and impacts a lot of things. Better revisited later.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Eero Tamminen wrote: CPU side:

Code: Select all

Time spent in profile = 74.58885s.
...
Used cycles:
   4.31%   4.36%   4.62%    51628540  52167524  55307540   _R_PointInSubsector
This one is already optimized using inline asm - but I've been wondering if it can be speeded up further by dropping the fraction part and hashing/caching the x,y coordinate result. The BSP is static so the answer will always be the same for a given x,y no matter what. *** assuming repeat queries, which I haven't checked.


It's mostly used to figure out which part of the map a monster or other object is in - I imagine the fraction part isn't very important for a lot of cases, although it would need tested quite well.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Eero Tamminen »

I don't think it makes that much sense to pay attention to TIMERBASE=1 stuff, or average over large number of frames as it contains both rendering and thinking parts averaged together. I think worst frames stuff at TIMERBASE=3, separately for render & thinking is more relevant for users, especially if it were for GCC 4.x stuff. :-)
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Eero Tamminen wrote:I don't think it makes that much sense to pay attention to TIMERBASE=1 stuff, or average over large number of frames as it contains both rendering and thinking parts averaged together. I think worst frames stuff at TIMERBASE=3, separately for render & thinking is more relevant for users, especially if it were for GCC 4.x stuff. :-)
It is misleading but still useful, as it's close to original behaviour. It's just not representative of the final version or indicative of gametick vs rendering cost.

It is somewhat indicative of relative gametick costs.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Implemented a cache for R_PointInSubsector and measured the hit/miss rate for repeat queries. Results are interesting.

After playing e1m1 (and using results from experimental cache, with 1024 entries), the metrics recorded 1668 hits vs 1733 misses. Queries are cached with 48% efficiency. Results look correct because initially the hitrate is 100% but drops off as you move around. The game continues to play properly as far as I can tell.

I'm not sure what that means yet - maybe all of the unmoving entities (health packs, corpses etc.) are querying position regularly all over the map? That would be unexpected, but useful info for optimizing :)

Eero - perhaps it's worth re-profiling after I check this change in, to see if it actually impacts thinking overhead?
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

I think I can see another way to disappear the cost of R_PointInSubsector, if the memory overhead isn't too big.

Break the BSP into a regular grid, sample all 4 corners of each grid cell using R_PointInSubsector. If all 4 corners return the same subsector ID, the interior must agree because subsectors are convex. The grid cell can then cache a fixed result for any point in that cell. The problem then is finding a suitable grid resolution which fits a good population of grid cells within subsectors, without offensive memory overhead.

It's worth a try because even if R_PointInSubsector isn't a huge singular cost on its own, it's called regularly from the thinking code which caches poorly. It might help a bit with that.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2512
Joined: Thu Sep 15, 2005 10:01 am
Location: Serbia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Post by calimero »

I am not sure where is problem?
If you can held 4 control keys and two normal than:

(move forward OR back) - First normal key
AND
(turn left OR right) - second normal key
AND
(strafe/sidestep left OR right) - first control key
AND
(shoot) - second control key
AND
(shift to walk/run) - third control key

There is no sense to hold e.g. left and right arrow at same time! Or trying to walk forward and backward at same time :)

Btw DynaBuster/tSCc two players can play on keyboard - four normals keys are pressed at same time!
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

calimero wrote:I am not sure where is problem?
If you can held 4 control keys and two normal than:

(move forward OR back) - First normal key
AND
(turn left OR right) - second normal key
AND
(strafe/sidestep left OR right) - first control key
AND
(shoot) - second control key
AND
(shift to walk/run) - third control key

There is no sense to hold e.g. left and right arrow at same time! Or trying to walk forward and backward at same time :)
This is basically what I was saying, yes :-)

The only 'problem' is that I haven't chosen a pattern yet that's actually comfortable to play, since the 'control' keys are not all in helpful places for directional stuff. However I'll try to find a decent pattern today, it doesn't look too bad.
calimero wrote: Btw DynaBuster/tSCc two players can play on keyboard - four normals keys are pressed at same time!
That's interesting. Does it work that way on a real machine too? This problem only shows on a real Falcon.

It is possible that the conflict I found is limited to a few keys (S+D?) but the limit of 2 normal keys at once seems to be deeper. I don't see any further key events beyond 2 keys, and it's not a 68k thing. The keyboard stops reporting internally after 2.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

dml wrote:
calimero wrote: Btw DynaBuster/tSCc two players can play on keyboard - four normals keys are pressed at same time!
That's interesting. Does it work that way on a real machine too? This problem only shows on a real Falcon.
I guess it must be well tested on real HW since it was released in 1994. So that suggests either....

A) Dynablasters dodges problematic key combinations, or
B) the gameplay isn't harmed by the problem, so it goes unnoticed
C) the IKBD is somehow reprogrammed or put in a different 'mode'.

I had already looked into the 'reprogramming' idea but it seems impractical. There's almost no reference on it and nobody seems to have bothered, since there hasn't been an obvious reason for anyone to go there. That leaves 'special mode' for C. All I can think of is disabling mouse and joystick handling to see if the key handling capacity magically increases, but it seems doubtful.

[EDIT]

Just re-read the Atari docs on the IKBD. Nothing mentioned about simultaneous key limits or changes to scancode behaviour in different modes.
Last edited by dml on Thu Jan 02, 2014 10:08 am, edited 1 time in total.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2512
Joined: Thu Sep 15, 2005 10:01 am
Location: Serbia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Post by calimero »

I will test DynaBuster in few hours on real Falcon...

And I think that Frooger/RG also does not block when more than two keys are pressed (two players can go up or down but if you press both keys (up and down) other player would not be blocked since his key press would be normaly read)

But give me hour or teo to confirm all this! :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

calimero wrote: But give me hour or teo to confirm all this! :)
Ok thanks. It is very useful to know what happens with other programs.


Another thought just occurred to me - perhaps it's not the IKBD that stops reporting scancodes, but rather the MFP that stops responding to the IKBD, and sends no interrupt for the key.

This would mean polling the IKBD directly could give the correct result, but waiting for a report does not. This is difficult for me to test just now but it's worth a look. I can't see WHY that would happen since the MFP doesn't care about simultaneous keys, but the IKBD might have a bug which isn't generating interrupts properly in that scenario.

This is perhaps a realistic explanation because I know a lot of ST games/demos just poll the IKBD for scancodes, as its less likely to miss keys when the framerate is 50hz. For lower framerates, polling tends to miss keys very easily - which is why I don't do that.
User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 985
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Bad Mood : Falcon030 'Doom'

Post by mfro »

Attached is the ST keyboard matrix scheme (stolen from the "Atari Profibuch"). The ST keyboard is arranged in 8 rows x 15 columns connected to individual ports on the keyboard processor.
ST_keyboard_matrix.png
According to this docs, the keyboard processor feeds '0's into the individual column ports and scans the result from the row ports in an endless loop.

If I didn't miss something important, it should be perfectly possible to implement full n-key rollover? At least in theory.
You do not have the required permissions to view the files attached to this post.
Last edited by mfro on Thu Jan 02, 2014 12:00 pm, edited 1 time in total.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

It's useful to have this diagram, because I can test a few things - S & D keys are on the same matrix column. Interesting to see if bad scancodes can be generated from other key pairs on the same column (or any column).

Specifically, LSHIFT+S are on the same row, S+D are on the same column.

This suggests Eero might be on the right track with the matrix wiring idea - might not be possible to read correct codes when there is pairing on both a row and column at once.

I can confirm that LSHIFT+E+S causes the same conflict (E,S are on the same column), but LSHIFT+W+E does not (W,E on same column, but neither on same row as LSHIFT).

LSHIFT+F+C also generates a conflict (different column)

More interestingly, a conflict does *not* occur when using CTRL instead of LSHIFT, in the same scenario. It might be a bug specific to the shift keys?

...

A (different) conflict does occur with ALT+C+V. So it's not just the shift keys.

...

Another interesting point is that bad scancode $3B - the F1 key - happens to be on the same column as LSHIFT, which generated the original problem.

The bad scancode generated by ALT+C+V is different - $3C, which is the F2 key - on the same column as ALT. And there is no function key bound to the same column as CTRL, which may be why CTRL does not generate bad scancodes...



So in summary, there are 2 obvious problems.

1) Holding patterns simultaneous keys involving either of the SHIFT,ALT keys can generate erroneous F1,F2,F3 keypress events - but only when one of the other keys is on the same row, and multiple keys in that column (!) :twisted:

2) Holding more than 2 normal keys stops generating key events (regardless of whether polling might still work - but I'm beginning to doubt that, since this looks like a matrix interpretation issue, at electronic or IKBD software level).

It's notable that 'normal' keys have fully populated columns, while control keys don't (and are staggered to avoid each other's row/columns). That's another clue to simultaneous keypress limitations.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

So from what I've found so far, it looks like there are hard limits to simultaneous keypress handling, and also electronic/controller level bugs in the IKBD which generate bad scancodes in some scenarios.

It does however look possible to use the matrix diagram to dodge these issues, and maybe 'reinterpret' the bad scancodes when they appear, by looking at the current state of other pressed keys (maybe - providing keyrelease events are not also corrupted).

However given the above, it seems the limit of 2 normal keys can't be solved, just avoided. I'd be interested to know if any game can/does deal with more than 2 normal keys held at once and what those key combinations are (and whether the state is polled or uses a handler).
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2512
Joined: Thu Sep 15, 2005 10:01 am
Location: Serbia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Post by calimero »

dml wrote:
calimero wrote: But give me hour or teo to confirm all this! :)
Ok thanks. It is very useful to know what happens with other programs.
Just checked on real Falcon and I was WRONG:

1. DynaBusters: only one player on keyboard is possible and you can place bombs (fire) only on SHIFT key if you press e.g. UP + LEFT (arrow keys). You can place bomb on SPACE but only if you DO NOT press two arrow key at once (same conclusion as yours Doug)
2. Bugger: two players on keyboard BUT one use arrows and other use CONTROL keys so four keys at same time is possible (same conclusion as yours Doug)

so both games run at same limit as you discover Doug.

btw
you can completely omit F1, F2 and F3 key! For help, use HELP key :) and we can made custom Help screen for BadMood ;)
regarding moving, fire, strafe, run: you can copy order of keys from Mikro's Quake port ;)
although F1 key are generated when:
LEFT SHIFT + arrow RIGHT + one other arrow key (DOWN or UP or LEFT) are pressed!

ALTERNATE or CONTROL with arrow keys does not invoke F1 (nor any other Fx key! e.g. F2 and F3 are load/save screens but they never occur!)!
RIGHT SHIFT also down not invoke F1

F1 should be simple omitted.
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

calimero wrote: so both games run at same limit as you discover Doug.
Ok thanks for testing that for me. It's helpful to know - at least, I won't waste more time trying to poke the IKBD into health :)
calimero wrote: btw
you can completely omit F1, F2 and F3 key! For help, use HELP key :) and we can made custom Help screen for BadMood ;)
Yes the HELP key can be used instead for the game.

The problem isn't so much that the help screen pops up due to F1 - that's just a symptom - the main problem is that the INTENDED keypress is not registered... and just to add to the fun, a key release event IS then registered for a key which didn't register as pressed in the first place (fortunately that one doesn't upset me).

I have found another solution to this bug using the matrix diagram - for any F1,F2,F3 event, the control keys and their rows can be scanned for existing keypresses. If a conflict is found, the keycode can be disambiguated to the intended keypress.

Unfortunately this only works if you know which two keys are mapped to the game for each row :-) so it's hardwired for the current keys until I choose better ones. The bug however has a solution in theory, even if it is more difficult to implement for 'reconfigurable' keys. It can be done but it's messy and I'll leave it for now.
calimero wrote: regarding moving, fire, strafe, run: you can copy order of keys from Mikro's Quake port ;)
although F1 key are generated when:
SHIFT
+ ALT (or CONTROL)
+ arrow RIGHT
+ arrow DOWN or UP or LEFT)
are pressed!
F1 should be simple omitted.
See above - while omitting F1 doesn't fix it (the 2nd normal key gets lost as a false F1 key regardless of what F1 is used for), the disambiguation trick does seem to work well and always reports up to 2 normal keys properly.

I assume the Quake pattern uses a control key to enable 'strafe' mode? This is another possibility, but I find it's a bit less convenient than the left+right handed strafe/steer play style because you can perform 'curved' moves with that which aren't possible without 'mouselook'. Still, if it helps matters it's worth considering as a choice.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Haha, it turns out there is one more bit of 'fun' to add to the problem.

If you generate a conflict e.g. with LSHIFT+S+D, and then release either S or D (or both simultaneously), it sometimes returns the 'keyrelease' scancode for F1, instead of the actual released key :-)

That means it's not possible to know which of the two keys was released since the conflict is order insensitive. All you can do is record a release of both keys (it seems the LSHIFT key state remains properly tracked) and the player is forced to re-press them if needed.

[EDIT]

Given that proper tracking of press/release state is needed for disambiguation, this becomes a circular problem. While the rate of error can be reduced, I'm no longer sure it can be fully fixed at the 68k side in this way.

Best course of action is probably careful choice of key combinations, coupled with good-as-possible disambiguation for cases which can't be helped.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2512
Joined: Thu Sep 15, 2005 10:01 am
Location: Serbia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Post by calimero »

Quake use:
Control - fire
LShift - run
Alternate - strafe
and Arrow keys for move/rotate

and it is work quite well except problem with LShift and F1...
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 908
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: Bad Mood : Falcon030 'Doom'

Post by EvilFranky »

How does it work in PMDoom?

Also an easy workaround...JagPad support! ;)

Sent from my Nexus 4 using Tapatalk
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

EvilFranky wrote:How does it work in PMDoom?
I expect PMDoom uses PM's keyboard routines, which I also tried in in this project a while back in case there were bugs. It didn't make any difference, because the problem is deeper than the software running on top.
EvilFranky wrote: Also an easy workaround...JagPad support! ;)
That would in fact work, since it doesn't use the same system. Unfortunately I don't have one to try. It would also be quite limiting to need one just to play it, so it is worth persevering with keyboard and mouse woes.

Incidentally I found another problem - again which seems to work in Hatari but not on a Falcon, this time with the mouse. I'm not going to blame it on the HW yet so I'll have to spend some time figuring that out next.
Post Reply

Return to “680x0”