• What are you working on? V4 (HTML ISN'T PROGRAMMING)
    2,003 replies, posted
[QUOTE=garry;17898603]What kind of thing do you want to know how to do? Lets say, a button? [code]Controls::Button* pButton = new Controls::Button( this ); pButton->SetText( "Button Text" ); pButton->SetImage( "danger.png" ); pButton->SetPos( 20, 20 ) pButton->GWEN_CALL( "OnPress", ThisClass::OnClickButton );[/code] To hook up a callback on press.. [code]void ThisClass::OnClickButton( Controls::Base* control ) { Msg( "Button Pressed!\n" ); }[/code][/QUOTE] Well I meant something more complicated like creating window with nested components, snapping etc. Can I ask why you are using strings for events? It just seems to me that it opens the door to runtime errors for things that could be caught at compile time if you were to use enums/structs/classes or functions like button.onClick( funptr ); Can you have multiple callbacks for one event? How do you feed input to GWEN?
[QUOTE=Guru-guru;17898393]Images have been a pain in my ass. I tried to switch over to using the images that are in the jar file. But I got lots of errors. One day I will do it right.[/QUOTE] What didn't work with that? I never made an applet, but it shouldn't be different and it's really easy to access images or other stuff from the jar. [cpp]BufferedImage img=ImageIO.read(ClassLoader.getSystemResourceAsStream("images/tree.png"));[/cpp]
[QUOTE=r4nk_;17899157]Well I meant something more complicated like creating window with nested components, snapping etc. Can I ask why you are using strings for events? It just seems to me that it opens the door to runtime errors for things that could be caught at compile time if you were to use enums/structs/classes or functions like button.onClick( funptr ); Can you have multiple callbacks for one event? How do you feed input to GWEN?[/QUOTE] Named events seems like it'd be a hell of a lot simpler than using enums or whatever. I mean, yeah, sure if the only events were ever fired from the 'default' components, like a set menu - but these events can be fired from anywhere. Yeah you can have multiple callbacks. For input you just fire shit right into Gwen::Input. You can do that any way you want. In my tests I've just made a class to do it. This is the class to do that under windows.. [code]class GWENINPUT_Windows { public: void ProcessMessage( MSG msg ) { switch ( msg.message ) { case WM_MOUSEMOVE: { int x = LOWORD( msg.lParam ); int y = HIWORD( msg.lParam ); // TODO: Do these coords need changing? Gwen::Input::CursorMoved( x, y ); break; } case WM_CHAR: { Gwen::UnicodeChar chr = (Gwen::UnicodeChar)msg.wParam; Gwen::Input::Character( chr ); break; } case WM_MOUSEWHEEL: { Gwen::Input::MouseWheel( ((short)HIWORD( msg.wParam )) / 120 ); break; } case WM_LBUTTONDOWN: { Gwen::Input::MouseButton( 0, true ); break; } case WM_LBUTTONUP: { Gwen::Input::MouseButton( 0, false ); break; } case WM_RBUTTONDOWN: { Gwen::Input::MouseButton( 1, true ); break; } case WM_RBUTTONUP: { Gwen::Input::MouseButton( 1, false ); break; } case WM_MBUTTONDOWN: { Gwen::Input::MouseButton( 2, true ); break; } case WM_MBUTTONUP: { Gwen::Input::MouseButton( 2, false ); break; } case WM_KEYDOWN: case WM_KEYUP: { bool bDown = msg.message == WM_KEYDOWN; int iKey = -1; if ( msg.wParam == VK_SHIFT ) iKey = Gwen::Key::Shift; else if ( msg.wParam == VK_RETURN ) iKey = Gwen::Key::Return; else if ( msg.wParam == VK_BACK ) iKey = Gwen::Key::Backspace; else if ( msg.wParam == VK_DELETE ) iKey = Gwen::Key::Delete; else if ( msg.wParam == VK_LEFT ) iKey = Gwen::Key::Left; else if ( msg.wParam == VK_RIGHT ) iKey = Gwen::Key::Right; if ( iKey != -1 ) { if ( bDown ) Gwen::Input::KeyPress( Gwen::Key::Shift ); else Gwen::Input::KeyRelease( Gwen::Key::Shift ); } break; } default: { break; } } } private: };[/code] [editline]05:56PM[/editline] That said - you only need to hook up what you want to use.
Nice that input system looks cool. [QUOTE=garry;17899788]I mean, yeah, sure if the only events were ever fired from the 'default' components, like a set menu - but these events can be fired from anywhere.[/QUOTE] Wait what do you mean? [QUOTE=garry;17899788]Named events seems like it'd be a hell of a lot simpler than using enums or whatever.[/QUOTE] Easier for who, you or the user? IMO it makes it much harder for the user. It introduces runtime bugs which might be hard to track down if they make a typo. Infact it's even harder for them to code, because they would have to refer to the documentation every time to find out what events are acceptable for what components and what the exact events are called. However if you were to use enums/classes/structs/functions then the user can get instant feedback or hints from intellisense 90% of the time - which would be way faster than going to the documentation. If you use functions then it's impossible for the user to set a callback for an unusual event for that component... consider this: [cpp] Controls::Button* btn = new Controls::Button(this); btn->GWEN_CALL( "OnKeypress", someFunctor ); //Wait what?! That doesnt make sense, but still compiles [/cpp] vs. [cpp] Controls::Button* btn = new Controls::Button(this); btn->onClick( clickFunctor ); //Makes sense btn->onKeypress( lsdkjflskd ); // doesnt compile //or alternatively btn->onEvent( Events::onClick, doSomething ); [/cpp] I dunno, just remember that a good interface is one that's easy to use correctly, and hard to use incorrectly.
[QUOTE=Funcoot;17892039] [highlight](User was banned for this post ("WEB DESIGN IS NOT PROGRAMMING" - garry))[/highlight][/QUOTE] what the fuck
[QUOTE=compwhizii;17900154]what the fuck[/QUOTE] Good ban IMO :v:
[QUOTE=compwhizii;17900154]what the fuck[/QUOTE] It has begun :ohdear:
[QUOTE=garry;17899788]...[/quote] So the GUI is global? That is the main point that annoys me with [b]all[/b] of the GUI solutions I've seen so far.
[QUOTE=r4nk_;17900130][cpp] Controls::Button* btn = new Controls::Button(this); btn->onClick( clickFunctor ); //Makes sense btn->onKeypress( lsdkjflskd ); // doesnt compile //or alternatively btn->onEvent( Events::onClick, doSomething ); [/cpp][/QUOTE] I never thought of doing it the top way - I'll look into that, it would be a lot easier for the end user. The bottom way is exactly what I was trying to avoid.
I wanted to post webdesigns, but since it's bannable i'll stop. Maybe we should create a thread for web designs, and let all the other programmers post in this thread. Also garry, that looks allot like derma, simple and clean.
[QUOTE=nullsquared;17900326]So the GUI is global? That is the main point that annoys me with [b]all[/b] of the GUI solutions I've seen so far.[/QUOTE] No, just the input and renderer are. The GUI itself is on a 'canvas' - you can have as many different canvases as you want, and they all act independently. There's no overall system like GWEN::RenderShit().. you have to call it on the canvas directly - in this code GwenTest is a derived Canvas which contains all that shit in the video. [cpp] GwenTest->SetSize( render->TargetWidth(), render->TargetHeight() ); GwenTest->DoInput(); render->Push2DView(); GwenTest->RenderCanvas(); render->Pop2DView(); [/cpp]
[QUOTE=ddrl46;17900394]I wanted to post webdesigns, but since it's bannable i'll stop. Maybe we should create a thread for web designs, and let all the other programmers post in this thread.[/QUOTE] [url]http://www.facepunch.com/showthread.php?t=576232[/url] [B]Mousetrackerupdate:[/B] [url]http://dl.getdropbox.com/u/1106779/MouseTracker3.3.jar[/url] [media]http://i35.tinypic.com/m7vsjq.png[/media] I added antialiasing to the lines (not visible in this screenshot) and finally added garry's suggestion: Optionally you can now make the lines change color depending on what direction you moved the mouse. And I fixed a bug with the default dot color not being transparent.
What about having "signals" similar to the boost::signals for each event? Something along the lines of: [cpp]Controls::Button* btn = new Controls::Button(this); btn->onClick.add(myFunc); btn->onClick.remove(myOtherFunc); btn->onClick.trigger();[/cpp]
What would be the benefit of that?
[QUOTE=garry;17900459]No, just the input and renderer are. The GUI itself is on a 'canvas' - you can have as many different canvases as you want, and they all act independently. [/quote] If the input is global, then essentially you have a global GUI. How would you handle a situation where there are multiple in-game GUI's?
That'd be down to the user - the input is stored in a global queue. It's up to the user which Canvas processes the input from that queue.. (using mycanvas.ProcessInput() )
[QUOTE=garry;17900663]What would be the benefit of that?[/QUOTE] Mainly code-reuse, and you could easily make changes to all signals without having to modify all your code.
[QUOTE=garry;17900950]That'd be down to the user - the input is stored in a global queue. It's up to the user which Canvas processes the input from that queue.. (using mycanvas.ProcessInput() )[/QUOTE] The problem is what happens when you have 2 or more active GUI's at once.
You'd have a system to decide which GUI should take the input. You wouldn't/shouldn't have canvases that you can poke through into other canvases. If you want to do shit like that for some reason you'd have to code that yourself. I dunno why you would have more than one canvas and still want them to be interacting though?
[QUOTE=garry;17901524]You'd have a system to decide which GUI should take the input. You wouldn't/shouldn't have canvases that you can poke through into other canvases. If you want to do shit like that for some reason you'd have to code that yourself. I dunno why you would have more than one canvas and still want them to be interacting though?[/QUOTE] The question is why the input is global at all instead of just being tied to the canvas you want it to apply to. As for why: multiplayer. AKA, why this: [code] Input::injectStuff(someInput); someCanvas->eatInput(); [/code] instead of this: [code] someCanvas->eatInput(someInput); [/code]
[QUOTE=Robber;17899348]What didn't work with that? I never made an applet, but it shouldn't be different and it's really easy to access images or other stuff from the jar. [cpp]BufferedImage img=ImageIO.read(ClassLoader.getSystemResourceAsStream("images/tree.png"));[/cpp][/QUOTE] That works in the Applet viewer in eclipse but not online. I have also tried this. This one works but not for everything. But that might be due to the fact that I might be missing some images in the jar file. [cpp]cl = this.getClass().getClassLoader(); temp1 = ImageIO.read(cl.getResource("axSwing0.gif"));[/cpp] This one is what I am using because it has never failed me. [cpp]grass1 = getImage(getDocumentBase(),"http://www.davidjokinen.com/grass1.gif");[/cpp]
[QUOTE=Guru-guru;17902827]That works in the Applet viewer in eclipse but not online. I have also tried this. This one works but not for everything. But that might be due to the fact that I might be missing some images in the jar file. [cpp]cl = this.getClass().getClassLoader(); temp1 = ImageIO.read(cl.getResource("axSwing0.gif"));[/cpp] [..][/cpp][/QUOTE] Are you sure you tried getSystemResourceAsStream and not getSystemResource? I never tried the second one, but the first one always worked. And did you try this? [cpp]cl = this.getClass().getClassLoader(); temp1 = ImageIO.read(cl.getResourceAsStream("axSwing0.gif"));[/cpp] [B]Edit:[/B] Google'd a bit and apparently this is the proper way to do it: [cpp]ImageIO.read(this.getClass().getResource("axSwing0.gif"));[/cpp]
[media]http://www.youtube.com/watch?v=vdU_2jo0FfI[/media]
[QUOTE=nullsquared;17901868]The question is why the input is global at all instead of just being tied to the canvas you want it to apply to. As for why: multiplayer. AKA, why this: [code] Input::injectStuff(someInput); someCanvas->eatInput(); [/code] instead of this: [code] someCanvas->eatInput(someInput); [/code][/QUOTE] There's nothing stopping you from manually firing input shit into your individual canvas, it' just seems like a messy way to do it. Plus the input system does things that aren't exactly related to the canvas - like handle drag and drop, hooks and closing menus.
[QUOTE=garry;17898398]Here's where GWEN is. We have most major controls done.. there's about 3-4 big controls to do (off the top of my head, tree, modal file dialog (which will consist of a couple of new controls). [media]http://www.youtube.com/watch?v=sk-WsgejKFE[/media] The video is shitty quality right now. There's some visible bugs, but nothing major. Unicode doesn't display right in the Botch renderer yet - and neither do textures (it's not hooked up). But it's on the right track I think. Oh and I put it on top of a bowling thing I had in Botch - just to show how it's rendered in game.[/QUOTE] Can you elaborate more on how the docking works? I'd love to do something similar but I can't find any information on how docking systems like this are built.
[QUOTE=Jimmylaw;17903858][media]http://www.youtube.com/watch?v=vdU_2jo0FfI[/media][/QUOTE] More like "Gravity = False" the whole time :v:
[QUOTE=Robber;17900465][url]http://www.facepunch.com/showthread.php?t=576232[/url] [B]Mousetrackerupdate:[/B] [url]http://dl.getdropbox.com/u/1106779/MouseTracker3.3.jar[/url] [media]http://i35.tinypic.com/m7vsjq.png[/media] I added antialiasing to the lines (not visible in this screenshot) and finally added garry's suggestion: Optionally you can now make the lines change color depending on what direction you moved the mouse. And I fixed a bug with the default dot color not being transparent.[/QUOTE] Thanks for the first answers but I've got another question: how do you create the image? Or the real question is how do you draw the lines in the image?
Finished porting Robot9000 to PHP, and I've created a Lua addon to use it. Wondering if it's a good idea to just release the access to my implementation so everyone uses my db.
Why play a game when you can make an app to do it for you? A little C++ project. [media]http://www.youtube.com/watch?v=j_7d1SLxmVo[/media]
Haha, nice one. How do you retrieve the game information like that?
Sorry, you need to Log In to post a reply to this thread.