Yeah I know, I really should continue work on it. I'll see what I can do tonight after work. No promises, thoughCutmanmike wrote:Someone really needs to make the perfect wad editing tool for zdoom, which includes all tools such as this. Slumped would be a good choice if slayer worked on it more
A program to remove unused textures here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
-
- Posts: 1026
- Joined: Wed Jul 16, 2003 4:47 am
- Location: Australia
-
- Posts: 150
- Joined: Thu Sep 14, 2006 8:56 pm
Sorry I couldnt answer sooner. My internet connection was unavailable for quite a while now. To answer the above I would say a couple days from the time of this post. As the net was not available, the info on the format was out of reach but I've just reviewed it and it would not be to hard to code.Tormentor667 wrote:Uhoh... so blind I am Well, Niya, this is actually one of the features mostly needed so when do you think will you have enough spare time to add this support?
Its written in VB6 mainly. One procedure is written in C++. I don't haveAgent Me wrote:Is this made with VB 6, or VB .NET Express?
If it's the former, you really need to upgrade to .NET Express. It's FREE and you only need the .NET package to run it, and it's better.
.NET here and from what I read, its quite different from VB6 and needs
the .NET framework installed. How is any different than using an installer. I wager that one still has to install the framework. Anyways if it were written fully in VC, it would have been easier to just copy and run
as C interfaces with the windows API directly for its GUI but thats quite too much more work than I am acustommed too.
Must DL VBRUN300.DLLNITEMARE wrote:WinTex is a VB application, and doesn't require a fancy installer.
If it had an installer then you wouldnt have to go through all that trouble.
The whole point is that applications written in VB6 inherit way too many dependancies. These dll(s) as ocx(s) do all the work of interfacing with the operating system for the advantage of ease of use, unlike VC++ which interfaces with the OS directly through the windows API (eg. user32.dll kernel32.dll etc) to achieve similar functionality. So the actual dependancies are the OS system files. Sad to say but this is how it is. Why would I choose to code a GUI (VC++) when I can visually create it (VB) with very minimal coding. It is much faster to create a windows GUI application in VB than it is in VC. VC may be good to code gaming engines, writing drivers or building system tools (eg. Scandisk, Anti-virus)
but for simple GUI applications or database applications VB is far better suited for this as the tools available make building these types of applications much faster than VC.
-
- Posts: 10002
- Joined: Fri Jul 18, 2003 6:18 pm
- Location: Idaho Falls, ID
Have you even looked at the tools available for creating "GUI" (Dialog-based) applications in VC recently? You can slap together a dialog very easily by grabbing controls and dropping them on the dialog. In fact, I'd imagine it's the same tool you're talking about using to create your VB apps!Niya wrote:The whole point is that applications written in VB6 inherit way too many dependancies. These dll(s) as ocx(s) do all the work of interfacing with the operating system for the advantage of ease of use, unlike VC++ which interfaces with the OS directly through the windows API (eg. user32.dll kernel32.dll etc) to achieve similar functionality. So the actual dependancies are the OS system files. Sad to say but this is how it is. Why would I choose to code a GUI (VC++) when I can visually create it (VB) with very minimal coding. It is much faster to create a windows GUI application in VB than it is in VC. VC may be good to code gaming engines, writing drivers or building system tools (eg. Scandisk, Anti-virus)
but for simple GUI applications or database applications VB is far better suited for this as the tools available make building these types of applications much faster than VC.
-
- Posts: 150
- Joined: Thu Sep 14, 2006 8:56 pm
Well I dont' have an in-depth understanding of VC's GUI designer but I know enough to say that it exposes a lot of lower level activities that takes place with its creation and operation and while I'm not intimidated by thisHotWax wrote: Have you even looked at the tools available for creating "GUI" (Dialog-based) applications in VC recently? You can slap together a dialog very easily by grabbing controls and dropping them on the dialog. In fact, I'd imagine it's the same tool you're talking about using to create your VB apps!
VB's GUI designer makes it unnecessary to know how these things work while still giving you considerable power over its creation. As you say, it may not be faster but it is sure as hell simpler.
I use VC++/APIs mainy for writing/accessing procedures that are either impossible to write in VB or if written in VB will run to slowly. VB is not very fast with long loops that have complex calculations or extensive string manipulation. VC excels at this among many other things but for me, just not with designing a windows GUI. You may be right, VC++ may be as fast or even simple at a GUI design but I don't see it that way.
BTW....
You still interested in applying a proper GUI to it once I update it to examine TEXTUREx lumps ?