Clickable interface
BlitzMax Forums/BlitzMax Programming/Clickable interface
| ||
| Does anybody know the the best way to add a clickable interface to a game (without maxgui) eg bitmap buttons to click on. My old way had each button object knowing its coordinates and when the mouse was clicked it would go through each button and check to see if it had been clicked. The main problem with this, of course, is that the more buttons you add, the longer it takes. My new idea is to have a 2d array the size of the screen, so each pixel references a button object to execute (or no button). This means it will take the same amount of time to click a button, and will also allow irregular shaped buttons, but use more memory. Any other ideas? |
| ||
| You should be using the collision system for this. |
| ||
| How many buttons are you going to have that a simple bounding square test is going to become speed prohibitive? I'm sure you could manage a few hundred without restricting performance, even on the most demanding of games. Seems like you're overthinking this unless there's more to this than meets the eye. I mean even if you have your array, you'll never be able to have overlapping items, which might well be a problem if you decide to build your GUI up into something more advanced. |
| ||
| How can I use the collision system? Believe it or not, I've never used Blitz collisions before :( I've never needed a pixel-perfect game before I just used a world-map array I'm making a strategy game, so there'll need to be clicks to menu and dialog buttons, minimap clicks, clicks on things in the game world etc. |
| ||
| Blitzmax has collision layers. You can put your menu/gui on one layer, minimap on another layer, game stuff on another, and so on. I'll be the first to admit that Blitzmax's collision system takes a little getting used to, and I'd also recommend reading this, as it explains everything you need. |
| ||
| I agree that you will most likely not have so many buttons that it will hurt the performance. Don't optimize yet. Finish the game first. |
| ||
| At first I thought, it won't affect performance just testing a load of rectangles (you could test thousands). Then I read again and as you were talking about testing every pixel it sounded like you wanted to make pixel-perfect collision detection with odd shaped buttons. If that's the case, definitely use collision detection - if not, just stick with bounding rectangles, it's really not slow at all... |
| ||
| Even if you are using pixel perfect collision, you only ever need to do it once or twice. If you're not overlapping ( you can't be if you're considering using an array to map the pixels to the buttons ) then the mouse can only possibly be within the bounding rectangle of a couple of buttons, so you can eliminate all the other tests with a bounding rectangle and then use a pixel-perfect test for the one or two you're left with. |
| ||
| I am designing a graphical interface in a tile map editor I am working on. I have been redesigning it over and over based on the problems I am running in. So far, I have buttons, sliders and lists some what figured out. Basically I have a mouse handling routines with routines for bounding box, double click, three different states for mouse button conditions(activated, inuse and released) and mouse speed as well as wheel speed. I use a type for handling dragging of objects. I posted the mouse handling type in the code archives here. I have modified it for personal use somewhat sence posting it but the basics are the same. You can try my work in progress from the link in my signature under map_maze folder. The save part doesn't work yet as I have not fully integrated it but if you press "l" you can see a pop up window that can be dragged by holding the left mouse button on the top of the window. [edited] the most significant part is the "activated" part of the mouse control. it checks the bounding box when it is activated only, which locks the "graphical button" down until the mouse button is released. so even if you exit the button, it remains locked down until the mouse button is released and will not check anyother "graphical button" until it is "activated" again. if you are looking for pixel perfect collition it is still best to do a bounding box check first. [/edited] |
| ||
| I'm currently working on a map editing system for a CastleVania game being created by someone else (although it can be used for any game). Everything is homegrown and is very much a WIP, but it uses a Windows GUI style interface, including buttons and icons etc. I haven't used any GUI modules at all. http://www.iprice.remakes.org/stuff/MaxMapper.rar (380Kb) There are two example files (both in the tile folder). Please not that the second example uses a map and tiles from a BlitzBasic map app. You don't have to use collisions or types for button presses, there are alternatives, without losing the speed. I use arrays for pretty much everything (although there are Types in there). It works for me. |
| ||
| IPrice - Is your map editor writting in Blitzmax? |
| ||
| iprice >I haven't used any GUI modules at all You actually did api calls in max to get the gui then?? I don't have the patients for that if I don't have to - thats why I hate plain C++. At least use wxMax or SOMETHING?!?! :) |
| ||
| No API calls. No C. No .DLLs. No external files. There's nothing in the code other than standard BlitzMax commands. :) [EDIT] With the exception of a standard function for Minimizing the screen, which is available on these forums. |
| ||
| iprice - So you're using standard drawimage and other graphics commands to render the interface each loop? Can you make a full screen mode version? Does it run in OpenGL and DirectX? You have me curious as hell now! :) |
| ||
| TBH - I've not tried in openGL. It's been written for Windows, so I just used DirectX. A full screen version isn't possible, as the FileSelector doesn't appear in full screen mode :( |
| ||
| So...is it a full graphic interface with a render loop, flip command, etc? |
| ||
| Thanks for the ideas. I've been thinking, what exactly can MaxGUI do? I knwo it can make windowy-apps but can it be used for "game" interfaces if you know what I mean.. I might buy it if it saves me some time and headaches.. |
| ||
| Why don't you take a look to FryGui or iGlass? |
| ||
| I would like to but I don't know how to use things like that - I've always just done things on my own before. |
| ||
| Jake's framework covers this to some degree. IGlass and FryGui are both as easy to use as MaxGui (which I wouldn't use for a game interface). If you want to do it yourself then I would either go for the Collision Layer for GUI suggestion or by the rect collision test and then an ImagesCollide on buttons close enough to count. |
| ||
| @MGE Mine is. @iprice for the record, it is true, you don't have to use types but they shure make it so much more easier to program at least for me they do. I like your TME it is so much like mines set aside the gui. It includes most of the options I have and going to include in it. althoug I am going to make it adjust to the different tile sizes per window upto 128x128, odd tile sizes in base 2 such as 32x128,64x32 etc. I will include a home grown gui window at the beginning somewhat like yours. good work iprice, I would like to see the finished product. as for mine I am doing verrrrry slooooow progress as I only have time during my free time which is almost none. My work in progress will always be posted at the same place. |
   |