So I have an editor I've been working on for a project.
Basically I have a grid of 48x48 cells that I can click on with the mouse to set information for each cell. Now I decided to add an ALLEGRO_MENU since I'm using Allegro 5.2 and have access to it. The problem is that when I click on a cell to add a tile it toggles the wrong cell. What it seems is that the lines are being drawn at every 48 pixels but the ev.mouse.x value is not matching to the pixel values for my lines.
Additionally this works perfectly fine when the menu is not displayed its only when the menu is displayed (effectively reducing the usable screen area) that the problem occurs.
I feel there could be something really obvious I am missing but I'm not sure what it is.
Here is some of the important bits of code
As an edit I have produced the same behaviour with a subset of the code.
This should make it clearer what I am trying to do and what I might be doing wrong.
This was compiled with Visual Studio 2015 on Windows.
Try initializing your addons before creating the display.
Initialising the addons before creating the display did not make any difference.
Tried your second source code and it's pretty much pixel perfect under Linux X11..
(Apart from the half-squares at the bottom select the top ones)..
btw, why do you have variables with a trailing underscore..?!
My Makefile
A quick glance shows they're all globals. Not a bad idea to highlight variables that have side-effects outside your functions.
I was wondering if it would be platform specific.
I was in the process of "quickly" spinning up a Debian Stretch vm so I could be lazy and just install the allegro 5.2 package (my other Debian installs are all Jessie still) but my internet being dreadful means I probably won't have it installed until tomorrow.
Thanks for the makefile.
As for the trailing underscore this is because of a particular project at uni where we had a coding standard that included using a trailing underscore for member variables.
I found it convenient and so it stuck however I've never been quite sure what to do with it in my main or the top of a c/cpp file. I try to be consistent but I'm not always as consistent as I should be.
Its effectively the equivalent of doing m_foo as opposed to foo_ or _foo is another option.
Hehe, fair enough - never seen such a convention before.
Being _ inconsistent is fine, that's why the words consistent_ & inconsistent_ exist
Yeah, maybe it is platform specific - the native_dialog stuff can be a bit of a bitch in my experience on different platforms.
I also couldn't reproduce your issue on Windows.
Clicking the bottom row/right column goes out of the bounds of the array (no checks on tileX/tileY in updateCell) - I suppose just because it's test code, but it might explain Kev's observation.
If I added some submenus to that menu (see code below), then I did see an issue. If I open up the menu and move the mouse off it, the first click closes the menu, and the next click is registered at a spot that's beneath where the menu was. Is that what you're referring to?
Pete
[edit] When you call updateCell you should take the mouse X,Y from the event that caused the mouse down, not a previous mouse move. When you open the menu and move off it, you don't get any mouse move events until you click (to close the menu) and move the mouse again. That explains what I saw.
ALLEGRO_MENU *menu = al_create_menu(); ALLEGRO_MENU *sub = al_create_menu(); al_append_menu_item(sub, "Open", 0, 0, 0, 0); al_append_menu_item(sub, "Save", 0, 0, 0, 0); al_append_menu_item(sub, "Destroy Universe", 0, 0, 0, 0); al_append_menu_item(menu, "File", 0, 0, NULL, sub); al_set_display_menu(display, menu);
Yeah its supposed to be the minimum needed to show what I was experiencing, so no bounds checking.
I've attached what happens when I click the mouse at the position in the grid where the cell above is activated instead of the one I expected.
As I get further down the grid the amount it is off gets bigger.
So effectively my mouseX and mouseY variables are redundant and I should use the ones from the event? It doesn't fix my issue but I'll keep that in mind.
It's not a rounding issue is it?
OK, yes I see it now. It's like a sort of scaling the client area to the area including the menu (or something)
{"name":"610992","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/b\/9be93d840ce36d70df67589d1dd946d0.jpg","w":801,"h":627,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/b\/9be93d840ce36d70df67589d1dd946d0"}
SiegeLord might know why, possibly due to the HiDPI scaling code?
[edit] Possibly I am going mad. Can you take some screenshots and measure them with MSPaint or something? Basically it looks like, if you request an 800x600 display then put a menu onto it, the client area will get squashed a little bit in the Y direction. On my system, the client area goes to something like 582 pixels, so your grid squares are no longer quite square. Is this in the documentation? I haven't checked.
Yeah I thought when you opened a menu everything shifts down a bit.. It doesn't draw over it.
Is this what you're seeing?
I usually get round this by resizing the draw to the display when the menu is enabled.
Guess you'd have to convert mouse coordinates as well.
I think this is a bug and you should file an issue on it:
https://github.com/liballeg/allegro5/issues
Pete