Experimental V72a now up! [MONKEY NEWS]
Monkey Forums/Monkey Programming/Experimental V72a now up! [MONKEY NEWS]
| ||
| Hi, Experimental V72a is now available! This version adds support for mode enumeration/switching on the glfw target. See bananas/mak/bouncyaliens for a demo - hit 'space' to toggle between windowed 640,480 and fullscreen 1024,768. You can now also create 'graphics-less' glfw apps by setting GLFW_WINDOW_WIDTH and GLFW_WINDOW_HEIGHT to 0. This actually used to mean 'desktop size' but I like this new usage better so will stick with it if no one has any major complaints. ***** V72a ***** Added GlfwGame and GlfwVideoMode classes to glfw target: Class GlfwGame Function GetGlfwGame:GlfwGame() Method GetGlfwDesktopMode:GlfwVideoMode() Method GetGlfwVideoModes:GlfwVideoMode[]() Method SetGlfwWindow:Void( width:Int, height:Int, red:Int, green:Int, blue:Int, alpha:Int, depth:Int, stencil:Int, fullscreen:Bool ) End Class GlfwVideoMode Field Width:Int Field Height:Int Field RedBits:Int Field GreenBits:Int Field BlueBits:Int End eg: GlfwGame.GetGlfwGame().SetGlfwWindow 1024,768,8,8,8,0,0,0,True Glfw mojo images now surive GL context changes. Set app config settings GLFW_WINDOW_WIDTH and GLFW_WINDOW_HEIGHT to 0 to disable initial graphics window - but make sure to create one using SetGlfwWindow above before OnCreate finishes! |
| ||
| Yay! |
| ||
| Ahh, thanks Mark! Now that is brilliant. |
| ||
| That's very nice! Thanks Mark and Skn3 for this! |
| ||
| Super awesome update! Thanks also to Mark and Skn3! |
| ||
| Great! Thanks guys |
| ||
| nice, but i would like to see glfw3 support at some point. |
| ||
Would we be able to have an override for SetGlfwWindow to send through a chosen video mode? ie.Local desktopMode:GlfwVideoMode = GlfwGame.GetGlfwGame().GetGlfwDesktopMode() GlfwGame.GetGlfwGame().SetGlfwWindow(desktopMode,0,0,0,True) Also now we have some specific Glfw changes, could I ask if we could also have Show/Hide window functionality?
static void ShowWindow() {
glfwRestoreWindow();
}
static void HideWindow() {
glfwIconifyWindow();
}
|
| ||
| Being able to explicitly specify the number of stencil bits means that my stencil buffer drawing extensions should be able to work on more platforms where glfw is supported instead of relying on the system default. Woot! |
| ||
| Sweet looking forward to playing around with this later, I have a game about to ship and I don't want to alter things just yet (still on v60!) |
| ||
| Well, it looks like both my forum thread, and SKN3's forum threads finally paid off. Thanks Mark, there's still a bucket list, but this was easily the most important issue. If you get around to it, adding similar functionality to the desktop XNA target looks to be a lot simpler. After searching for a bit on Google, I found this Stack-Overflow post, and I think it might persuade you to add this functionality to Monkey. Using 'Extern' for this method in particular isn't such a bad idea, but for the sake of consistency between native desktop targets, I suggest adding it. Also, the whole GLFW_WINDOW_WIDTH and GLFW_WINDOW_HEIGHT as zero thing makes the most sense to me, so I'm glad you went with that. Plus, that method keeps existing programs compatible. I usually wait a bit before updating to a new version of Monkey, but I'm downloading this immediately. As a side note, could you consider adding a simpler overload for 'SetGlfwWindow'? I love the control I get with it, but for the sake of keeping things readable and easy to use, you might want to add: [monkeycode] ' EDIT: Could you also make it so SetGlfwWindow returns a GlfwVideoMode? SetGlfwWindow:GlfwVideoMode(width:Int, height:Int, depth:Int, fullscreen:Bool) SetGlfwWindow:GlfwVideoMode(videomode:GlfwVideoMode, fullscreen:Bool=False) ' And possibly: 'SetFullscreen(toggle:Bool)', but that isn't really necessary. [/monkeycode] EDIT: Now that I think about it, a 'SetWindow' command for Mojo would be ideal. Then you could make an alias (Or a wrapper class) called 'VideoMode' for the platform specific classes. Something like this would be awesome: With a wrapper class you could try to make things more consistent, but I think VideoMode itself should be target specific (Alias would do this). Anyway, that's my take on how the feature should be implemented. |
| ||
| Good news. Think Monkey has just appeared on the edge of the developer's map as far as desktop development is concerned. |
| ||
| massive thumbs up :D Just looked at the code, seems like this is using the method used in blitzmax. Upon loading your image it will exist in video mem as 'texture' and in system mem as 'data'. This could be useful for stuff like pixel perfect collisions as pixel tests can be done in system memory. One suggestion: Could we have a config var potentially to specify the storage method. e.g. GLFW_IMAGE_STORAGE_COPY - duplicate in vid and sys GLFW_IMAGE_STORAGE_TRANSFER - transfer from vid to sys on window change GLFW_IMAGE_STORAGE_SHARED - stored in shared context Or even better, be able to specify at runtime: GlfwGame.GetGlfwGame().SetGlfwImageStorage(IMAGE_STORAGE_TRANSFER) That way it would be able to modify the behavior based on system capabilities. On the oldest systems rely on duplicate copies, and then depending on device compatibility can use transfer / shared context to reduce system resource requirements for the game? |
| ||
| Great, perhaps we could have a "desktop" define. #If TARGET = "desktop" and also +1 for the xna target, I have hacked in borderless window and set window position in my xna version.
public static int SetBorderlessWindow()
{
BBXnaGame._form.FormBorderStyle = System.Windows.Forms.FormBorderStyle.None;
BBXnaGame._form.Location = new System.Drawing.Point(0, 0);
return 0;
}
The reason I prefer xna for desktop is the compilation speed and the garbage collector. |
| ||
| Fantastic stuff!! :D |
| ||
| Erik: Great, perhaps we could have a "desktop" define. #If TARGET = "desktop" Erik, I've done the same sort of thing with my own project. Making it the same as "TARGET" isn't really a good idea if you ask me; plus, it wouldn't be good for compatibility with older programs. However, making a separate variable called "DEVICE" (Or something like it) would be great. For the sake of keeping things simple, I'll be referring to this variable as "DEVICE". "DEVICE" could be set to "desktop" for both GLFW, and XNA (On Windows). And then for mobile devices (Android, iOS, Windows Phones, Vita (If it ever returns), etc), it would obviously be set to "mobile". After that, any other targets could be classified as "other" (Or something to that effect), and custom targets that don't set the "DEVICE" variable would be under "other" as well. Once again, that's just my take on things. I completely agree with your point about compilation speed. Whenever I'm testing something in Monkey (Something that isn't dependent on native code), I usually test it in XNA. Of course, I still use GLFW for the final build, and to make sure things are the way I want them (Not to mention realistic debugging), but C# and XNA are really good at getting things compiled quickly. There's also HTML5/JS, but that's really not convenient for me; and I'd have to worry about a lot of incompatible code. I really think the next step is to get the XNA target off the ground. Sure, it's not a C++ based target, but it's still a DirectX target at the end of the day. |
| ||
| Ouch... Am I the only one who was using WIDTH=0 and HEIGHT=0 to get desktop width/height? Thanks God for the TARGET system, If I hadn't fork my own glfw target I would be in deep trouble with this update :P Edit: Maybe instead of W=0, H=0 for windowless... wouldn't W=-1, H-1 be better? |
| ||
| Great update. Makes it Monkey more viable for commercial PC games. |
| ||
| SLotman, you could always just use the 'GetGlfwDesktopMode' command. |
| ||
| Great, perhaps we could have a "desktop" define. #If TARGET = "desktop" no, i'd prefer not. iOS and Android are about to get into consoles, so no telling how much confusion this will cause. best to do it the long way for now. keep it simple for Monkey for now, let's focus on other features. |
| ||
| That's great. I'm targetting PC, Mac and ultimately Linux with my first Monkey game (as well as Android, iOS and web, obviously!) My previous games have been full screen OpenGL. I did think the missing mode switching was a pain and didn't look foward to rolling my own instead of game coding. Thanks for the upgrade Mark. Monkey is an awesome piece of tech. Compiling into other platform specific languages - such a cool concept! |
| ||
| Excellent now monkey can take on the mighty blitzmax :-) With this update we should be able to get games out on portals :-) Thanks mark :-D |
| ||
| no, i'd prefer not. iOS and Android are about to get into consoles, so no telling how much confusion this will cause. best to do it the long way for now. keep it simple for Monkey for now, let's focus on other features. +1 |
| ||
| nice... but i do not understand why we need extra class for that... what is with XNA? I like to see something unversal (Glfw/XNA) - if possible (?) or for ALL desktop targets: flash, glfw, html, win8, macos, linux (but not for mobile devices) |
| ||
| If I understand this correctly, I am not comfortable with it - I would prefer to use commands that are universal to all platforms (coding once for all platforms is the reason I use Monkey). |
| ||
| Let me get this straight: You'd rather not have Monkey get this functionality (Which is 100% optional, and makes things so much better for desktop developers), simply because it's not platform independent? That reasoning is garbage. By that logic, you must've hated fundamental features like 'JoyHit/JoyDown'. Or is your issue that it doesn't support the other desktop target(s)? Regardless of that, you need to understand that Monkey is a language that's built to convert to various languages. Monkey is not a language which completely ignores the benefits of each target, and Mojo works the same way. Monkey has been known to reinvent the wheel for some targets, and ignore very specific functionality (Pointers), but nothing too extreme. I definitely think we need a SetWindow command, but if XNA gets the same treatment as GLFW, I can deal with that (I'll just make my own wrapper). However, if XNA doesn't get this treatment, then we'll need to bother Mark until he does something about it (The same thing we did with GLFW). The only downside I see to this functionality is with games that auto-detected the resolution; however, it's insanely easy to fix this, so it's not Mark's problem. |
| ||
| If I understand this correctly, I am not comfortable with it - I would prefer to use commands that are universal to all platforms (coding once for all platforms is the reason I use Monkey). So don't use these commands then. You can't change resolution on mobiles anyway. XNA is a dying platform too. So nothing to worry about. |
| ||
| I think I know where Rex is coming from; one of the defining characteristics of mojo is that it is pretty much platform independent, and I wouldn't really like to see it go down a road where you have to worry about platforms a lot either. In practical terms, though, a few pragmatic options that only work on some targets are inevitable. And these don't affect anything in 'standard' mojo code; the functions are all labelled so you could not mistake for anything but target specific stuff. If we find that multiple targets require similar functions, there is always the possibility of wrapping them in more generic functions. |
| ||
| Taking into account what Rex Rhino says, why not use the same graphic modes enumerator in all targets? as long as it does only return one value on targets that do not allow the graphics mode to be changed, it should do it, shouldn't it? |
| ||
| Has someone mentioned ENUMs? I'd LOVE to see real enums by the way! |
| ||
| I think I know where Rex is coming from; one of the defining characteristics of mojo is that it is pretty much platform independent Mojo is still platform independent, these GLFW changes are separate from Mojo. I feel this is a good approach and gets away from the lowest common denominator which has limited some targets. |
| ||
| I think for now flexibility is better than tidiness - probably in the long term when everything settles down there will be a standard for extending mojo. [I still say we need a 'protected' access qualifier, precisely because it makes extensions possible that dig into the base class a bit. Possibly Mark is philosophically opposed to this, but note that you can still do it by putting things in the same file - which is surely worse! Call it 'unsafe' rather than 'protected' if you must!] |
| ||
| I still say we need a 'protected' access qualifier, precisely because it makes extensions possible that dig into the base class a bit. Possibly Mark is philosophically opposed to this, but note that you can still do it by putting things in the same file - which is surely worse! Call it 'unsafe' rather than 'protected' if you must! +1 It would allow me to avoid having to decide between properly encapsulating my modules and having huge files, or making them a bit more unsafe to use, but have properly organized code. I would prefer a "Friend" modifier tho. where a member of a class can only be accessed from within the modules being imported by the module where the class is located. I mean, if my module has a class with a friend atribute called "myfield:Bool", only modules explicitly being imported by my module can get Access to myfild. then, modules Importing my module, won't. That would make encasulation much much better on Monkey in my honest opinion. |
| ||
| Just added some VSync code for GLFW here: http://monkeycoder.co.nz/Community/posts.php?topic=5554 Is this something we could have added? Discussion here: http://monkeycoder.co.nz/Community/posts.php?topic=5547 |
   |