Mapping screen for mouse

[mdijkens]

A method that I've used, which is relatively simple to implement, is use screen masking.

You draw your menu or whatever on the first screen like normal.

Then you create an image the same size as your target screen. This will be the hidden overlay.

Code: (Select All)

hiddenScreen = _NEWIMAGE(_WIDTH(0), _HEIGHT(0), 32)

 
On the second screen (the hidden screen) you mask off the areas that you want the mouse to be sensitive to, and you assign specific colors to those areas.

Code: (Select All)

myButton_1 = 1 ' Assign Numbers to masked off areas (colors)
myButton_2 = 2

_DEST hiddenScreen
LINE(10, 10) - (30 ,20), myButton_1, BF
LINE(50, 10) - (80 ,20), myButton_2, BF
_DEST 0

And when you want check your mouse.

Code: (Select All)

DO WHILE _MOUSEINPUT '      Check the mouse status
  mx = _MOUSEX
  my = _MOUSEY
LOOP

_SOURCE hiddenScreen
buttonTouched = POINT(mx ,my)
_SOURCE 0

I find this easier than making a large number of conditionals for my mouse position.

(Forgive me, I haven't tested this code, but it conveys the general idea.)

I've used this technique for a graphic representation of a complex machine interface.
Copied the full-screen graphic showing the whole system and in picture-editor created colored area's to click on.
Using different colors per area and even using R,G,B for sub-areas.
Then this image was used as a hidden screen to retrieve clicked area.
Works excellent and even with very odd-shaped click-areas

[bplus]

@justsomeguy or @mdijkens


As I said this is interesting but for clarification: This is all done at run time that you run the graphic in a picture editor and create colored areas then find what color the mouse is on?

It must be to handle moving boxes I would think? 

To me, this is way more complicated than running a couple If Then lines on boundaries. Move the x,y top right box corner, no problem!

I do see the advantage of being able to get the odd shapes left for rectangles being overlapped.

[mnrvovrfc]

My goodness another basic! This one uses SDL nice! Does it work on Linux?

https://sourceforge.net/projects/sdlbasic/

Sadly the Italian author hasn't been extensively developing it for years, and a short time ago the forum was lost.

I checked it out on Debian GNU/Linux "Bullseye" which is now the "old stable". The IDE it comes with is very fussy to display. I remember I tried it in at least one other distro and it refused to start, and in another distro, the IDE launched but with really erratic behavior and some functions not available. Definitely the "runtime module" couldn't be used.

This is entirely 32-bit. The author made an attempt to port it to 64-bit and SDL v2 but failed. There is a separate project page for it on Sourceforge abandoned since 2011, there is nothing there.

The programmable mouse routines were primitive. It does not employ the cursor from the operating system, has to draw its own cursor. At least that's how it was on my side.

This is replete with incomplete programs but which were interesting. My favorite was "Biomorfi" by the author of SDLBASIC. I ported it to QB64. It uses the arrow keys to "animate" a few trees on the screen. It's sort of a fractal study.

[mdijkens]

@justsomeguy or @mdijkens


As I said this is interesting but for clarification: This is all done at run time that you run the graphic in a picture editor and create colored areas then find what color the mouse is on?

It must be to handle moving boxes I would think? 

To me, this is way more complicated than running a couple If Then lines on boundaries. Move the x,y top right box corner, no problem!

I do see the advantage of being able to get the odd shapes left for rectangles being overlapped.

No creating the image in a picture editor and 'color' the click-regions is of course done during design. I then incorporate the 'click-image' in the source-code.
And you are right, this only makes sense if you have a lot of different click-areas with odd shapes and maybe even overlapping. For just a few square/circle-shape click-regions you're easier off using some conditions checking _mousex and _mousey

[TerryRitchie]

Your version of quick and dirty is of great quality! Is it OK to use this in our own projects?

This is an awesome example, thank you for sharing it!

Screenshot for others:

Thank you. Any and all code I post is freely available to everyone to modify and use for their needs. Hack away

Awesome thank you. Your code is easy to understand and follow. I never finished studying the tutorials you made. Now I know I should. Also, have you done any more?

Thanks @TerryRitchie !

The current lesson count is at 21. I'm currently exploring 2D physics for a lesson I would like to do on the topic. Any suggestions for further lessons are welcome. Is there anything in particular you would like to see added?

JustSomeGuy has done an awesome job of creating a 2D physics engine for QB64. The lesson (or lessons) on 2D physics will more than likely consist of examples on how to incorporate his engine in games with explanations of the physics math going on behind the scenes. I tried to write my own rudimentary 2D physics engine to use for the lessons but quickly got lost in the math and implementation of it. For the most part I understand the math behind the individual concepts but piecing it all together into a cohesive engine is a monumental task.

JustSomeGuy is working on the documentation for his engine that will help me greatly in understanding how to incorporate it into games. Once I've explored these docs and have a firm grasp on using his engine I'll add the 2D physics lessons.

[justsomeguy]

@justsomeguy or @mdijkens


As I said this is interesting but for clarification: This is all done at run time that you run the graphic in a picture editor and create colored areas then find what color the mouse is on?

It must be to handle moving boxes I would think? 

I do see the advantage of being able to get the odd shapes left for rectangles being overlapped.

If I'm understanding your question correctly, I see no problem with moving boxes. The hidden screen in merely a stencil of the areas that you are wanting the mouse to be sensitive to. They could be updated at runtime. I do this with the GUI demo that uploaded earlier. 

The "color" would have to homogeneous across the stencil of a particular button or control, that way you always get the same value when pressing the button.

Effectively this in nothing but a large look up table. Its just convenient to use the same commands to create it as you do to draw your GUI.  

To me, this is way more complicated than running a couple If Then lines on boundaries. Move the x,y top right box corner, no problem!

If you only have a few GUI items, then by all means 'IF' 'THEN' on boundaries are the way to go.  But, if your GUI requires a ton of controls, it might get unwieldy pretty quickly. Because, I'm a bit of feature creep, I try to write my code to scale.