March 25, 2019, 12:25:42 AM

Author Topic: Window->Graphics->Keydown problem HELP!  (Read 594 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

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


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]


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


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

While Not KeyDown(KEY_ESCAPE)
SetGraphics a

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

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

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

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)


Local ev:TEvent = CurrentEvent




If KeyDown(KEY_ESCAPE) End
Global ang:Float
DrawText "test", 300 + 200 * Sin(ang), 200 + 100 * Cos(ang)
ang :+ 1
Any bugs in my code are proof of its hand-coded nature.

Offline Matty

  • Hero Member
  • *****
  • Posts: 611
    • MattiesGames
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.


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!