[SoC 2009 - Accepted] Unified Samples Framework & Browser

Threads related to Google Summer of Code
Post Reply
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Kencho »

You're aware that human beings need to sleep, aren't you? :D
Image

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Assaf Raman »

I just wanted to say that I think you are doing a great job. :D
Watch out for my OGRE related tweets here.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

I've been meaning to comment on this great thing .. but is totally overwhelmed by the amount of stuff going on! :D
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Wolfmanfx »

Great progress but i have some concerns regarding the gui system.

I understand your argument with CeGUI, MyGUI, YourGUI, WhatEverGUI :) but with you put something into the framework which will never be satisfy all people out there ( i mean people want always more widgets :) )
Also the Ogre project projects had a own GUI system which were based on overlays which sinbad stripped out and now you reintroduce something like it again. What really makes sense is to put something leight weight into the sample system like http://www.ogre3d.org/forums/viewtopic.php?t=30688 http://www.antisphere.com/Wiki/tools:an ... ar:gallery

keep up your great work

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

I think the idea of a reintroducing the Ogre GUI is a good idea.
CEGUI is great, but it creates unnecessary confusion for beginners, because it's pretty advanced.
Ye Olde OGRE GUI stuff was core'd - this will be part of the sample framework.
Sounds nice. Let's keep as much as possible in the smallest box possible.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

Wolfmanfx wrote:you put something into the framework which will never be satisfy all people out there
I may have misunderstood the scope, but AFAIK this is the Ogre sample framework.
Scrap other peoples needs. It's ease of use which matters. And staying within scope. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Wolfmanfx »

But why reinvent the wheel again and again and than again.... for example -betaGUI is some sort of a tiny overlay based gui system why not use something like that instead cooking his own soup?

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

Because BetaGUI is a bloody mess (in the official obfuscated form).
And besides: there's not much to it. As the size of BetaGUI indicates. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Wolfmanfx »

i said something like that :)
I think you do not get my point there already gui libs out there why not use one of them?

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

Simply because they are 'out there'. :wink:
Otherwise, we could just stick to CEGUI (tried and tested).

((All in my humble opinion, of course))
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

Woa! So many replies. :o

Thanks for the comments everyone.

And Wolfmanfx, I'll try to address your concerns as well as I can:

Your first concern was that this GUI system will not be able to satisfy everyone's needs. Well, that is true, undeniably. But neither will the samples framework. This GUI system was made to be sufficient for most of the things you will do with the samples framework. And if people really really need another kind of widget for the samples framework, they can extend their own easily, or tell me and I'll add it in. Full GUI systems were designed to be as feature rich as possible. This one was designed to be as minimalistic as possible, but perfect for samples.

Your second concern was that sinbad had an overlay GUI system before and tore it out, and it's a bad idea for me to reintroduce it. As jacmoe said, it was part of the core. And as such, the burden fell on it to meet the needs of all OGRE users. The overlay system basically became a self-proclaimed GUI system, and people expected it to be such. In the end, it just wasn't feasible to maintain it when there were thousands [/hyperbole] of other, better GUI solutions out there. It just wasn't worth the team's effort. The system I am making will be part of the samples framework. As mentioned in the previous section, it does not aim to be a full GUI solution, but a very light-weight one for samples. If people request new widgets that are commonly used in samples, then I will add them. However, if people request a new type of widget for their next game, or if they ask me why there isn't a TabbedWindow or RichTextBox or why the buttons don't make sounds, well... no.

Your third and most pressing concern seems to be that I am reinventing the wheel. Yes, there are many GUI systems out there, but in my original we established why they might not be suitable for the samples framework - they are heavy and confusing for beginners, and still a pretty big hassle (for samples) to use even as an experienced user. The exception would be BetaGUI, and while it is quite lightweight, its focus is to make a flexible overlay-based foundation on which people can put together their own GUIs. It provides the most basic pieces to put together a GUI, nothing more, nothing less. The one thing that these solutions have in common is that they target all OGRE users, or sometimes all 3D developers. The new system I am making is made strictly for the samples framework. It has all the common sample widgets made for you, and the SdkSample class calls about 2 lines of code to setup and shutdown the system for you, so all you have to do is create widgets with another line of code and write listener methods.

This is not even a separate project, in case you're worried about it taking up too much of development time that could be better used on the browser. The total code for the system that produced the screenshots is in a single, 441-line header file. I made this file in 2 days. The basic system is already in place, and all I have to do now is add the other widgets. I aim to be finished these by next week.

One of the major goals of this project is to make the samples framework more accessible. Currently, it's pretty intimidating. It should take people 30 seconds or less to set up a button that tests an OGRE features, because that's what counts - the OGRE part of the sample, not the GUI. We're not trying to teach people how to make a 3D game here, we're just trying to demonstrate OGRE features. And it's just so much easier to do that with this new GUI system.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by sinbad »

I think y ou're doing some great work here, and I love your enthusiasm. Keep it up.

I do have a small concern about the GUI system though. On the one hand, I totally understand your need to have a simple, light GUI set that doesn't overcomplicate the sample applications. After all, we want to demonstrate Ogre and not an advanced GUI.

But, it's important to recognise that by adding a new GUI system, you will have added something new and non-core to support. It's certainly better that it's out of the core, but actually so was most of the old GUI (most classes were in a plugin IIRC - but still a sample lib is better). It doesn't matter whether it's marked as 'basic', people will expect it to work in all kinds of situations, and will raise enhancement requests on it. They'll want to add new controls, because they'll start off using it for something small, and then realise they want to just add 'one more small thing' rather than switch to a 'proper' GUI system. Even our basic samples use list boxes, combo boxes, checkboxes, radio buttons etc. I have to question whether spending time on that is really justified versus working on the samples themselves and using an external GUI.

Here's what I would suggest - don't write your own GUI. Use the functionality of CEGUI (or MyGUI, or whatever), which we already include and wrap it in your higher-level friendly API so that the interface is as easy as you wanted your custom system to be, but that you don't have to write your own GUI system. If the main bugbear is that CEGUI et al are more complicated than you want to expose to sample code viewers (and I agree there), then by all means hide it underneath a simpler API. But there's no need IMO to be implementing a low-level GUI renderer when there are already ones in existence, it's just reinventing the wheel. What you'll be bringing to the table is a simpler, more intuitive API that to all intents and purposes will look the same as if you'd implemented your own GUI, but you won't have to repeat any existing work, nor will we be saddled with maintaining a GUI which will unavoidably be subject to unended feature requests (believe me, I've been there already - don't think for a second that people will listen when you tell them it's not supposed to be a full GUI). At least by wrapping another GUI, you satisfy both needs - a simple, uncluttered interface but also an 'upgrade path' for those that outgrow it. They will outgrow it, and they will grumble like crazy if you tell them they have to swich libraries once they get beyond N complexity. Like I say, been there.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

The difference here is that the GUI is part of the sample framework.
And that it's only 400 lines of code.

No matter what, people will start whine about that this framework is unsuitable for a full game..
Which it is, of course, as it's a very specific framework.
People will refuse to see that, no matter how you put it. :wink:

Just tell people how easy it would be to swap out that GUI with another GUI.

Before we know it, we'll start a USF/B GUI plugin revolution. :)

I'd rather explain to people why they can't have those features, than dealing with CEGUI questions all the time.
There's just so much which can go wrong - DLLs, dependencies, libs, XML files, imagesets...

I know what I prefer.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by sinbad »

jacmoe wrote:The difference here is that the GUI is part of the sample framework.
In my experience, people don't make these kinds of distinctions. They assume that if something is in OGRE when they get it, that it's the 'recommended' solution for everything. I've learned this lesson the hard way ;) Only veterans have the experience required to graduate what comes with OGRE into the various shades.
And that it's only 400 lines of code.
It's 400 lines of code now. Wait until checkboxes, list boxes, drop downs etc are added. And the first 50 patches come in ;)
Just tell people how easy it would be to swap out that GUI with another GUI.
You were around when the old GUI was there, you should know this doesn't work. One of the primary reasons the GUI was ditched was because people didn't listen, and the only way to make them realise it wasn't a complete solution was to take it away and make them use something else from day 1. Anyway, it isn't that easy to switch, especially as the sample GUI gets more capable. At least if they're already using a more proficient GUI, albeit through a simplifying wrapper, all the core assets and techniques they're using will go with them to the next level should they exhaust what's there.
I'd rather explain to people why they can't have those features, than dealing with CEGUI questions all the time.
There's just so much which can go wrong - DLLs, dependencies, libs, XML files, imagesets...
So pick a simpler GUI system with less external dependencies and wrap that. I still don't think any of this justifies reinventing wheels that have nothing to do with what this GSoC project is about, and then having to support them into the future, which is nothing to do with what OGRE is about.

You have to have a good reason to rewrite something that already exists. Being simpler to use is not a good enough reason - did Apple re-engineer every component of the Mac to make it easier to use? No, they just put their expertise on top of existing solutions to make the same hardware simpler (they also tried going down the esoteric custom hardware route a decade earlier and look where that got them). The best answer to something you don't like is not always to rewrite it from the ground up (that's the sledgehammer to crack a nut), but to pick the mature bits you can use, and then write the bits that are needed to make the whole package better. Usability is always about the last 20% of refinement, not about the guts.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by sinbad »

Bear in mind this is my opinion only. At the end of the day, this is your project, and if you want to write a GUI from the ground up, you can provided it doesn't prevent you from completing your project. My experience with the old GUI influences my view here, plus the fact that at the end of the day, the buck for supporting what's in the codebase stops with me - so naturally I take a longer term view of this.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

You're right. It's a fact. And I do remember the situation with the OGRE GUI.
There's little point in denying the reality.
Since we already carry CEGUI, I'd recommend a CEGUI wrapper.
That way we don't have to choose a new GUI. And all that controversy.
People really can't complain about CEGUI lacking in features. They do complain about it being difficult to use, but not in this case, using the USF wrapper. :wink:

Whatever you choose, Omniter, I am looking forward to it. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

You make some excellent points, sinbad. And it is hard to argue with previous experience with persistent users.

Though, I will be frank - I think I will actually complete this project more quickly if I create and use this GUI system. I also wouldn't say that this GUI has nothing to do with this GSoC project. In the original timeline, there was more than one week dedicated to GUI-related development. The browser needs a GUI, and it's definitely not going to use the current CEGUI skin in the SDK (I think it looks ghastly, and even if I didn't, it doesn't look very OGRE). It would take ages to tinker with imagesets and whatnot to make a new skin. And call me unfit for this job, but my experience with CEGUI is quite limited. I have very little understanding of the roles played by the 9 different file types found in the gui media directory. On the other hand, the new GUI system requires only that I make a few boxes in Photoshop and write a few simple materials and overlays. I have every confidence that I can complete this project (just not as much if I use CEGUI).

I'm not a fan of reinventing wheels either. It's why I use OGRE instead of wrapping Direct3D or something. But in all honesty, there isn't much to reinvent (it's a wheel, not the steam engine). I've written my own overlay GUIs from scratch before (of similar complexity), and the process is quite trivial. Plus, I have reusable code. And is introducing a wrapper around a specific external GUI system really a better idea than introducing a stripped down GUI system? As far as I can see, there's no reason to believe that users won't have requests for the new wrapper to make certain tasks easier or to add a way to do so and so. You can't really avoid maintenance with this kind of solution, either. If CEGUI could have an easier interface, CEGUI would have one. It's not our job to maintain a wrapper for it.

All that having been said, I never did want to bring more troubles to the team. This system has the same advantages that BetaGUI has - overlays. With overlays, all the widgets that come with the sample framework are completely transparent (structurally, not visually). Their structure is fully exposed in an overlay script, and so are their materials, and their code. Each widget is literally just one overlay container template. Provided that I make good documentation, I think we will receive much fewer feature requests and whatnot. To make your own widget, you just have to make a new overlay container template and write a few custom callbacks. And if there happens to be a good feature request, I will be around, and happy to take up the task.

I really believe it's best to go ahead in this new direction. However, if it causes too much trouble in the future, I will personally tear it out and swap it for an external solution. Thanks for your support, guys.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

Go for it. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

Just as a precaution, here's what I did:

I renamed BasicGui.h to SdkTrays.h.
I renamed GuiSystem to SdkTrayManager.
I renamed CameraMan to SdkCameraMan.
I renamed OgreBites.zip to SdkTrays.zip.
I replaced "OgreBites/" in all of SdkTrays.zip's material and overlay names with "SdkTrays/".
I removed all "virtual"s from SdkTrays.h.

Lastly and most importantly... I removed all instances of the word "GUI" from the code I wrote.

This should help to make it very clear to people that these things were made for the SDK, and that the SdkTrayManager is definitely not a full GUI system. We should all start referring to this system as the "SDK Trays of Pain and Death" as opposed to the "OGRE GUI System". Just as people are unlikely to ask the team to add more features to a specific sample in the SDK, they will be much less likely to make feature requests on SdkTrayManager as opposed to GuiSystem. The naming can have a pretty big effect here (psychology is such a wonderful thing).

I removed all extensibility from the tray system and decided to limit it to just the widgets I create. There are no template methods to construct widgets. There are no virtual methods in the classes (aside from those needed for the system to work). Originally, I thought giving people the option to make their own widgets was a good way to stop them from demanding more, but I decided that a completely rigid system would be better. People would see that it's a specialised solution (hell they can even say it's a quick hack for the SDK), and hopefully leave it be. Sure, all the other code in this project was made to be flexible and extensible and easy to incorporate into other projects, but starting now, I will refrain from encouraging or suggesting this route. What happens in the SDK stays in the SDK. The smart users will figure out how to use this code for their projects anyway.

I hope this helps sinbad sleep better tonight. ;)

EDIT: All the widget creation methods now require you to specify a tray location. This does two things: it removes the need to move the widget to a tray manually after creation (something that almost always needs to be done anyway), and it makes people think: "It's all about the trays. Damn these trays... There really is no way to turn this into a real GUI."

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by sinbad »

Ok - as I said, this is your project and if you think this is the best way to deliver it successfully, it's your call. This wouldn't have been the path I would have taken, but I'm not omnipotent and open source is all about everyone pitching in with their efforts and seeing what works, and sometimes I'm wrong ;). Time will tell!

Thanks for trying to accommodate the concerns I have with your chosen path. I still have some reservations, but we'll see how it turns out.

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Praetor »

The important thing here is the core project: the sample system and browser. It needs to be relatively easy to make the existing samples use this new framework and to make new samples. Next, the sample browser needs to look appealing and provide a new front-end for people coming to look at Ogre. The GUI is a means to an end. If you feel like making your own serves those ends best then you should continue with what you plan. I really like the preview images of them. It does really have an "Ogre" feel to it.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com

Vectrex
Ogre Magi
Posts: 1266
Joined: Tue Aug 12, 2003 1:53 am
Location: Melbourne, Australia
x 1
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Vectrex »

Woah! for the love of jebus just use Navi! :) It's a 10 meg dll and it's a web page/flash renderer. A '100% do whatever you want, how ever you want, even use flash ffs' gui/anything system. It's got a small performance penalty only when updating the controls, but don't waste time with another gui when the ultimate gui system works.
Plus the interface code is tiny because all the boring stuff is in html/swf/whatever files. For the demos probably avoid a flash/flex gui until someone figures out how to include it without installing flash itself.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by jacmoe »

Vectrex wrote:Woah! for the love of jebus just use Navi! :)
You really can't be serious! :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

Vectrex
Ogre Magi
Posts: 1266
Joined: Tue Aug 12, 2003 1:53 am
Location: Melbourne, Australia
x 1
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Vectrex »

jacmoe wrote:
Vectrex wrote:Woah! for the love of jebus just use Navi! :)
You really can't be serious! :)
I can, I will and I am :D Only someone who's never used Flex would say such a thing :mrgreen: I was thinking the same thing about writing yet another half arsed gui that people will whine about ;)

User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

I've looked at Navi. I have a flash interface included for my own game engine as well. As far as I can remember, you gotta program flash interfaces with ActionScript. I also don't think I can just overlook the performance overhead so easily. A 10MB dll? That's 10% of the entire, uncompressed SDK's size, mate. The total resources for the tray system won't exceed 200KB. Guaranteed. And by not using a third-party system, all the resources are OGRE resources (instead of introducing html and swf and whatever), and are loaded from a resource group (so you don't have to provide a folder path to the GUI system or something).

There seems to be a huge concern over my allocation of time, but I can tell you that most of the code (about 75%) is code i'd have to write anyway if I were to wrap an existing system. The other 25% takes much less time for me to write than for me to learn another system and write wrapper code for it (and not to mention making skins and layouts). Besides, I'm well on my way to finishing this darn thing - I already have a minimal (but working and pretty) browser GUI up and running. I have a menu that displays all my samples, accessible while running a sample too (by toggling the ESCAPE key), and I can switch back and forth between samples, reset, or go back to the main menu, or quit the browser. All of this was done last night in ~50 lines of code.

I'll give you guys another update soon. :D

Post Reply