Feature request: Drive list

christianclavet · Post by **christianclavet** » Fri Jul 17, 2009 9:53 pm

I would like to have in the next release of the system a function that would query the OS to have a drive list.

Since IRRlicht is multi-system, it would require coding this for the different OSes (Windows, Linux, MACOSX, ?)

Once that feature is implemented, and since IRRlicht 1.6 will have a treeview, we could create very complete file requesters (Since i find the current one to be very limited)

I could even write a new file requestor (Already did it with the one I have in FKEditor. with file filter and icons but the code is horrible, JP has done a better job on this), but I don't know how to create list of mounted drives on the OS of the "client". Right now, drives have to be entered manually.

wITTus · Post by **wITTus** » Sat Jul 18, 2009 9:58 am

Posts like this make me believe that Irrlicht is a game engine, and not a simple scene renderer as always promoted.

christianclavet · Post by **christianclavet** » Sat Jul 18, 2009 5:21 pm

A "simple scene renderer" that all you hope for IRRlicht?!

Seeing post like you send just tell me to shut up and do it by myself. That's ok. I'll check how it's done with windows and do it.

IRRlicht is a rendering engine. I want it to be a powerful engine that could be used in AAA games someday, High tech simulations, research things. A really fast realtime 3D engine. It was certainly not you that has given us the GUI, INPUTS (joystick, keyboard), Basic collision, the file system, the ability to read a lot of formats... With you, it's still be a "simple rendering engine" doing nothing else than rendering a "simple" scene (no occlusion of anysort) and used only by you.

I'm really happy that you're not in the DEV group, because we'll be in the dark ages. These guys and other that collaborated to send patches and suggestion have helped improve the engine and make it popular, it's now very flexible and it's getting better at every revision.

Since it's has GUI function integrated, I'm only asking for improvement in a small thing (the requester is done already, just missing that function). And I'm asking this to everybody that has time (on their own OS) if they can do this.

You seem to talk about games in disguss. Games are what is now pushing the technology further. With a thinking like your's we'll never be able to reach on a level of quality and speed as the next gen games can give today. What are you plan with IRRlicht? Doing math graph and little pie graph to look at your money?

Have you ever heard of "serious" games?!
Check there and learn:
http://en.wikipedia.org/wiki/Serious_game

FreakNigh · Post by **FreakNigh** » Sat Jul 18, 2009 6:41 pm

There should obviously be focus on irrlicht being both a great scene rendering engine and providing all the basic elements for a game engine if it wants to compound it's purpose in this world the greatest. Although it's direction is respectfully up to its original developers and current developers and not the beggar public.

Hirte · Post by **Hirte** » Sat Jul 18, 2009 7:31 pm

Yes, Irrlicht and its features is completely dependent on its developers, but I think user should be able to suggest new features.

To topic: maybe a nice idea, but not necessarily essential for a graphics library like Irrlicht.

Dorth · Post by **Dorth** » Sat Jul 18, 2009 7:54 pm

Well, it was suggested a couple of time that Irrlicht itself and such features be splintered. I think an epurated, streamlined Irrlicht would be nice with a secondary project, using and extending Irrlicht, possibly IrrExt or something else.

christianclavet · Post by **christianclavet** » Sat Jul 18, 2009 7:55 pm

Ok. Found this on MSDN:
http://msdn.microsoft.com/en-us/library ... S.85).aspx

They have the function "GetLogicalDrives" that will retrieve a bitmask for every logical drives mounted on the system. It requires
- Winbase.h
- Kernel32.lib/kernel32.dll

Are theses dependancy are used right now with the IRRlicht windows version?

Are there similar commands for Linux and MacOSX?

I think that command could improve the GUI subsystem of IRRlicht. I'm so happy that the TREEview is out in 1.6. that using this with the treeview could make a really nice and complete file requester GUI element.

Hi, FreakNigh.

I think the DEV team are taking a really good direction at the developpement, in that they are doing a really complete rendering engine with goodies to help the developper create an application fast and easily. Making IRRlicht one of the easier platform to create 3D applications.

- They are really improving what is there. Quake 3 elements have been implemented, but now there are really improving. (The Quake 3 explorer show that IRRlicht could be used to create 3D games, not just demos). The new GUI elements (treeview for example) is really improving and now the GUI can be more than a MENU of a demo or game.

- Developping new tools/to make it easier to develop ANY 3D application

- The new examples are awesome and help any "noob" get out something fast out of the engine.

- Effort put in optimizing the speed of rendering (occlusion techniques/VBO)

- The new filesystem is really incredible, and will allow creating "compact" setup for any 3D application really easily.

As of a game engine, forum members have started doing very interesting stuff

- New frameworks being developped fit nicely with IRRlicht
- Extensions and wrapper are coming out with more feature than ever
- Some user are really putting lots of effort in creating a better occlusion for IRRlicht. Since occlusion is a rendering technique, it could help the devs implement something that really work well.

EDIT:
Dorth. Theses features CAN be removed. You only have to set the proper option when you compile the DLL. (You can remove the GUI system, the file formats, etc)

Since It would be nice for me to have a really nice file selector it would be disabled easily if you remove the GUI from the DLL. Separating thoses in other DLL would make this more complicated to use them.

r2d2 · Post by **r2d2** » Sat Jul 18, 2009 9:26 pm

A drivelist might make sense if one uses windows, but the standard fileopen dialog already got one, afaik. But linux doesn't distinguish between the drives, so why should one try to retrieve the list of logical drives on a unix or mac based OS?

I think a good rendering engines also needs a powerful interface to access files, so if there is a good reason to access the logical drive list on a unix based os, one should think about implementing such a feature in irrlicht. If there is no reason (linked to rendering) for accessing the drive list on a linux based os then i think it shouldn't be implemented, cause irrlicht aims to be multiplatform and implementing basic functionality which is only accessible on win based systems, which arent linked to rendering, one shouldn't put that into

CuteAlien · Post by **CuteAlien** » Sun Jul 19, 2009 7:51 am

Reworking the IGUIFileOpenDialog, including giving access to other drives, is rather high on the list of things I want to do. And I think the windows-fileopen still doesn't allow this (unless someone added it recently without me noting). Is that what you mean with drive-list query?

I just need some other things to be working first before starting to rework the fileopen dialog. One of the features I want to be in there was also the ability to select more than one file at a time. Which needs the multi-selection listbox first with some features. A few features had to do with mouse-events (those got added by now) but another features which is blocking progress right now completely is how to do the s32/u32 stuff. Once that is decided work on listbox will continue. Once that is done reworking fileopendialog has for me top-priority (I need it also in my own project...). But right now things blocking me - the s32/u32/npos stuff (mentioned in another thread and still not solved) and as usual the lack of time (no free weekend this time... ). edit: And I also haven't made up my mind yet what to think about those c16's which are since a while used for all filenames.

hybrid · Post by **hybrid** » Sun Jul 19, 2009 8:56 pm

As said, other OS often don't have this problem, as they have a properly defined root of the file system. But we should probably just add a proper root for Windows (and maybe others) as well. That would mean that we need to add some artificial directories when going up one step beyond the directories found on the local drive. At that stage, one wouldn't be allowed to go up anymore, but all drives would be listed. This would allow to change drives under Windows, and sync with other OS's features. The current filesystem should have the possibilities to do so.

c16 is currently just a renamed wchar_t, but should make it possible to switch to some proper locale supporting string class at some point.

christianclavet · Post by **christianclavet** » Mon Jul 20, 2009 1:48 am

Hi, Hybrid and CuteAlien.

I think being able to choose a DVD drive, the Hard Disk, a USB key, Network drives, etc. would really be super nice. It was really repetitive in my editor to load meshes when I was testing it. I want to get to the files really fast.

I know that on the MAC, it's about all on the desktop. I think Linux does also the same. On windows you can select "My Computer" and it will give you all the drives (as a list) directly from the filesystem. I found out a simple command (if you include the Kernel32.lib, and Winbase.h) that would give you a list of the mounted drives on the system:
"GetLogicalDrives"

I really know that if a new feature is added to the IRRlicht GUI, it should AT LEAST work the same at least theses 3 OS's. So if this is implemented, it should be for theses 3 systems. I'm about sure that nobody know how to do this for all theses OS, so it would require some teamplay to integrate this.

From what Hybrid says, the Mac and Linux have already the ability to get this (root to all devices and browse them?) Is that true? If yes, would it be hard to add this "root" to the windows versions.

CuteAlien, I will rework my file selector, will not be ready in a couple of months. But my last version of the fileselector I had, had icons, filters. You could check the source code from JP filerequester, his source is much better than mine and it has all the features I had.

As I'm using a framework now and will redo my project starting from it. I will try to implement a list of devices for windows systems and get a "root" ("My computer", and a "Desktop" shortcut, as in windows). Want to add the treeview to get a quick way to browse the paths, and even perhaps add "shortcuts" so the user could define "pre-defined" paths he often use. (Will be really usefull in my editor). So if it's not done, no worry. If a new IRRlicht version come out with a function to get this "root", I will update my code and be very thankful since it should work on any platform and not just Windows. I could call directly the GUI from windows, but I prefer that the GUI be in IRRlicht not a window outside.

bitplane · Post by **bitplane** » Mon Jul 20, 2009 1:57 am

Another thing worth considering is some kind of filesystem events, for example when a user inserts a CD or plugs in or removes a USB drive the app (the Win32 device at least) gets an event telling it what happened. If we're going to enumerate drive letters then we'll also have to support removal, and if we want asynchronous loaders in the future then filesystem events are one way of implementing this.

wITTus · Post by **wITTus** » Mon Jul 20, 2009 8:59 am

christianclavet: Why so aggressive? Calm down. You got my sarcastic post totally wrong anyway. I'm not against new features for Irrlicht, it's only that many things have been rejected argumenting, that Irrlicht should stay "only" a renderer. Now, if we go this way, I just asked myself if one should be able to write a file manager with a rendering engine.

hybrid · Post by **hybrid** » Mon Jul 20, 2009 11:08 am

Well, we have two parts in Irrlicht where we already offer some support for such kind of features, namely the GUI filechooser and the virtual file system. Whether this is an integral part of the render engine or not, we should have support for file systems which are capable of the same thing cross platforms. And this requires some support for Windws platforms (and no, I don't really know about OSX, but since it's Unix based I guess there's a common root node somewhere).

christianclavet · Post by **christianclavet** » Mon Jul 20, 2009 3:42 pm

Hi, wITTus.

Sorry but your post completely pissed me off. I didnt perceived any sarcasm but I felt it like you were telling my request was for a game engine, when I ask a thing for the GUI.

Thanks for the info Bitplane... The only thing I would like is that it would be added on the list.

and if we want asynchronous loaders in the future then filesystem events are one way of implementing this.

You mean, that we could load and display something animated at the same time?

Yes, Hybrid I think all system should have events when a dismount occur. But I'm pretty sure everyone of them do it their own way.

Using the command ""GetLogicalDrives" in windows should refresh the logical drives? I'll check that on windows, when I'll redo my fileselector.