|
Socoder -> Concept/Design -> Method for showing windows/menus |
|
| Thu, 07 Oct 2010, 05:21 | |
waroffice
|
afternoon, Im trying to decide which would be the best method to show popup menus or different screens in my map editor. options i have so far are: 1) Completely isolate the menu screen from the main loop, going out of the main loop and setting up another loop condition and flip commands. This is how i have it now. Pros = simple to add new screens Cons = repeated code, not the prettiest of options b) Similar to above but take a snapshot of the main screen buffer, dim or blur it slightly then repeat the above process but using the image as a background and moving the text rendering to the centre of the screen. Still keeping it in a different loop. Pros = a little more time to dev but is essentialy identical cons = background animation will stop. iii) using the main loop and some sort of window handler to render the menu and gain focus, make them positionable and semi-transparent. I have something similar already. Pros = a lot better looking and scalable cons = a lot more work in terms of development time Im not sure which i should go for or if there is a 4th option? 
|
| Thu, 07 Oct 2010, 05:42 | |
HoboBen
|
It's a tough question, and one I always get wrong... I would just pick whatever is easiest for now, and just get the program working (functionality before beauty!). Inevitably you'll go back and re-work bits; if it turns out that you weren't happy with the way it worked before, change it at that point. -=-=- blog | work | code | more code |
| Thu, 07 Oct 2010, 05:46 | |
|
waroffice
|
I see what you mean, why spend a few days getting a nice pretty menu working when it would benefit more from being able to edit maps! The sys dev guys who work here get that wrong all the time, they create a nice web app but dont go back and change the interface so it looks ok and is user friendly. no one cares if the code is a stroke of genius if its not usable. I will stick with option 1...i think...probably :S
|
| Thu, 07 Oct 2010, 11:04 | |
JL235
|
Build whichever makes the code the most modular. Sure over engineering is bad, but it's much worse to need to re-write everything every time you want to add a feature. Build it right! It saves time in the long run. Btw, a menu should need to be constantly redrawn. If it's open for 3 seconds then at 60 fps it's drawn the same thing 180 times! Only 1 frame is needed to draw it. I'd build an event based menu. Proper GUI's are built that way and there are good reasons why. |
| Fri, 08 Oct 2010, 02:49 | |
|
waroffice
|
If someone had an article on how to make a more efficient menu/gui system i would be most grateful. i guess you would only re-draw the bits that update but not sure on how to achieve that. ps: by article, i dont want someone to code it for me i want to learn the best way to go about it and code it myself.
|
| Fri, 08 Oct 2010, 06:21 | |
Afr0
|
It's been a long time since I've been doing any Blitz stuff, so I'm not going to suggest any method. I'm also going to refrain from reccommending a particular language, but I'd say that in general, Blitz3D (which seems to be what you're using) is really bad for applications. Blitz3D was made for games, so the executables tend to hog alot of memory and processing power without any concern for letting Windows process various tasks. If this is an in-game map-editor though, that's a little different. If you're going to go ahead and make this in Blitz3D, I'd suggest making it in-game (I.E making it only accessible from the game's main menu). -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Fri, 08 Oct 2010, 06:44 | |
|
waroffice
|
Im using Cobra, i made the map renderer and then implemented that code in the editor and game, the editor is basically the same as the game but you can change and save stuff. basically the map functions are an include file so changes to it are replicated everywhere. I'll stick to my plan and have simple menus/gui for the editor and focus on game play
|
| Fri, 08 Oct 2010, 06:44 | |
|
HoboBen
|
@waroffice, if using Cobra, use sprites instead of images for the GUI. They make it so that you don't need to worry about what to draw and when. I tried to write a clever system that rendered images as rarely as possible, but using sprites was faster and much easier. -=-=- blog | work | code | more code |
| Fri, 08 Oct 2010, 06:45 | |
|
JL235
|
I second Afr0's points, but I'd also encourage you to ensure that the runtime used for displaying the map is the same as the runtime for the game itself. Otherwise you can end up running into lots of bugs because of slight differences between your editor and your game.
|
| Fri, 08 Oct 2010, 07:09 | |
|
waroffice
|
@JL235 it is a cobra unit so it imports the map.c3d file which includes the DrawNewMap() function, this is used for both editor and game so should be ok. Unless i missunderstood you. (its been a long day,week) @hobo, i thought that too and thats how i have done it ingame but found it a bit of a pain at first. for the moment i will use basic text in the editor and some nice sprites in the game. download the game files from my website, load up the main.exe and press i multple times to see what i mean.
|
| Fri, 08 Oct 2010, 07:41 | |
|
JL235
|
waroffice  @JL235 it is a cobra unit so it imports the map.c3d file which includes the DrawNewMap() function, this is used for both editor and game so should be ok. Unless i missunderstood you. (its been a long day,week) Yeah, that's pretty much what I'm getting at. But to also ensure that everything else is shared too (like update code and your data structures). |
| Tue, 12 Oct 2010, 01:00 | |
|
waroffice
|
managed to get a nice little interface done last night, not sure where it came from but I actually like it. I is text based, pressing certain keys will open different menus etc. after getting the menu working it took seconds to get the map functions working, im quite pleased with it. i think its time for a blog update
|
|
|
| |||
|
| ||||