April 20, 2018, 10:27:18 AM

Author Topic: Window->Graphics->Keydown problem HELP!  (Read 112 times)

Offline covi2955

  • Jr. Member
  • **
  • Posts: 2
Window->Graphics->Keydown problem HELP!
« on: April 14, 2018, 09:04:26 PM »
So, this is kind of a multi-stage problem that could be solved at any step. I'm making a game. Its a simple top-down walkaround. I had been using the basic, built in graphics window that comes up when you call Graphics Width,Height but I found that I would need a side window to display some stuff.
I run CreateWindow and now the new side window shows up, but the graphics window doesn't appear.
If there's a fix to this, then my problem is solved. If not, continue

To fix this problem I decided to replace my graphics window with a simple window containing a canvas. But now my "Keydown" input checks don't fire. I replaced it with an event check for "EVENT_KEYDOWN" but that only seems to fire when you initially press the key. So instead of running the action on the If EventID()=EVENT_KEYDOWN check, I now set a "currentAction" variable on that, (to be run later) and clear the current action on a "EVENT_KeyUp" event. I did this so that I could, for example, allow the player to keep walking in a direction as long as he held down the key. But EVENT_KEYUP hardly ever seems to fire. So the character will walk forever, no matter if you hold a key or not.
I've looked around and the program isn't gobbling events anywhere but right where all this is happening. I can't figure this out to save my life. Please help! And thank you so much for your time!

TLDR: Solving any of these problems would solve all of them.
[]Display both the default Graphics Window and a "CreateWindow" window.
[]Properly read Keydown input (not event) in a window/canvas
[]Read KeyUp event consistently


Note: I am using vanilla Blitzmax in MaxIDE

Offline TomToad

  • Full Member
  • ***
  • Posts: 239
Re: Window->Graphics->Keydown problem HELP!
« Reply #1 on: April 16, 2018, 02:26:02 PM »
Might be good to post code of what you are doing. No need to post your entire program, just what is necessary to reproduce the problem.
------------------------------------------------
8 rabbits equals 1 rabbyte.

Offline Brucey

  • Jr. Member
  • **
  • Posts: 40
Re: Window->Graphics->Keydown problem HELP!
« Reply #2 on: April 16, 2018, 07:36:59 PM »
Are you sure you really need a second window? What is it for? If it is just some controls, you can probably replicate this on your graphics display?

Offline col

  • Sr. Member
  • ****
  • Posts: 279
Re: Window->Graphics->Keydown problem HELP!
« Reply #3 on: April 16, 2018, 09:34:03 PM »
Quote
But now my "Keydown" input checks don't fire.
Sounds like you may need

EnablePolledInput

?
It also sounds like you could end up mixing two input systems too. I'm sure we'd all recommend using MaxGUI with a graphics canvas and the user controls in the main window. It is possible to use more than graphics window but it could get messy to code.

Here's a basic example of using 2 graphics windows - ugly as sin though :P
Code: [Select]

Strict

Local a:TGraphics = CreateGraphics(400, 400, 0, 0, 0)
Local b:TGraphics = CreateGraphics(400, 400, 0, 0, 0)

EnablePolledInput

Local x:Float, y:Float, ang:Float

While Not KeyDown(KEY_ESCAPE)
SetGraphics a
Cls

ang :+ 2
x =  200 + 50 * Sin(ang)
y = 200 + 50 * Cos(ang)
DrawText "Graphics context A", 0, 0
DrawText "O", x, y
Flip

SetGraphics b
Cls
DrawText "Graphics context B", 0, 0
DrawText "X: " + x, 0, 20
DrawText "Y: " + y, 0, 35
Flip
Wend

and here's a crude example of using a graphics canvas within a maxgui window
Code: [Select]

Strict
Import maxgui.drivers
Import maxgui.xpmanifest

Local win:TGadget = CreateWindow("", 0, 0, 800, 600)
Local canvas:TGadget = CreateCanvas(0, 0, 600, 400, win)
Local button:TGadget = CreateButton("Quit", 650, 20, 100, 20, win)

CreateTimer(60)
EnablePolledInput

Repeat
WaitEvent
Local ev:TEvent = CurrentEvent

Select ev.id
Case EVENT_WINDOWCLOSE
End

Case EVENT_GADGETACTION
End

Case EVENT_TIMERTICK
SetGraphics(CanvasGraphics(canvas))
ActivateWindow(canvas)

If KeyDown(KEY_ESCAPE) End
Cls
Global ang:Float
DrawText "test", 300 + 200 * Sin(ang), 200 + 100 * Cos(ang)
ang :+ 1
Flip
EndSelect
Forever
When something is important enough, you do it even if the odds are not in your favor. -Elon

Online Matty

  • Full Member
  • ***
  • Posts: 229
Re: Window->Graphics->Keydown problem HELP!
« Reply #4 on: April 16, 2018, 10:03:29 PM »
You'll hate me for saying this:

Two windows is bad design.

Use a single graphics display and simply split it into sections.

However even that is not good design.

Why?

If a user's eyes are focused on the action area of the 'main' window then it is distracting and sometimes impossible for a user to coordinate their eyes to look left/right to the 'other' segment of the screen or other window even for a moment.

What's worse is if that second smaller window has writing in it that needs to be read.

Have you ever driven a car?

Things like speedometers and gauges are directly below the windscreen - not in the rear vision mirror! And they are designed such that a simple glance can tell you what you need to know.

Imagine if you had to read the fuel gauge by looking in the side mirror - what a disaster, or the speedometer?

It's the same principle.

Side panels on action games are not where the eye wants to go to maintain focus on the action.

Offline covi2955

  • Jr. Member
  • **
  • Posts: 2
Re: Window->Graphics->Keydown problem HELP!
« Reply #5 on: April 18, 2018, 03:34:08 AM »
These are all wonderful comments, thanks everyone for the quick responses!

I suppose the main reason why I had figured on using a window was to facilitate the creation of a dialogue popup without having to draw a window sprite, and reinvent the wheel just to have a dialogue popup inside my graphics window. The idea had been that when an event was triggered in game it would pop up a window with a text area (that would wrap and allow scrolling if the text was too long, not features I wanted to recode for an object in a graphics window), and a list box that would contain all possible responses (also with scrolling in case there were more than the 3 that would fit in it at once). This window will show and hide based on when it is needed for the player to read it and make a selection, and would pop up in the middle of the screen/gameplay window as it would need to be resolved before play could continue.

I obviously could make all of this in a graphics window and it could look a lot nicer there. But I had hoped to avoid recoding the wheel, especially since this project is really just to prototype our event-story system to see if it will do what we want it to for a much larger project we'll be working on next year. If the best way to do this is all inside the graphics window, then does anyone know of a possible gui library for managing panels/textareas/buttons/etc. inside a canvas or graphics window? If not, I think I'll look into that EnablePolledInput that Col mentioned.

Thanks again everyone for all your help!