#21075 - abilyk - Sun May 23, 2004 8:12 am
Granted, this forum is for GBA development, and there are a ton of forums and other resources geared solely towards developing Windows (and other OSes as well) apps. However, since map editing tools and the like are so closely tied to GBA programming, I think more information regarding tools development would benefit many of us. With all the talk recently of adding to the community's GBA-specific tutorials, I think it's a fine time to talk about adding some tools programming faqs or tutorials to the mix.
My tools programmer is currently working on a map/level editor for Windows using wxWidgets. So far so good, but I'm sure it would benefit us, as well as others likely beginning or considering tools development, to hear some tips from those who've already done some extensive tools development, like Nessie and Cearn. Cearn, I've read through the "Coding Lessons Learned" section of your Usenti help file. Some good information there, despite the fact we're not using MFC. More information such as this, as well as more basic discussions, such as "What GUI API should I use?" would be a great addition to the forum and the community.
What do you all think?
#21081 - poslundc - Sun May 23, 2004 5:33 pm
I code the majority of my tools in PHP, which is nice as a cross-platform compatible environment. Rapid interface development time thanks to HTML and quick coding thanks to a robust scripting language.
For more complicated programs (map editors and such that have graphical requirements that would incinerate most web servers) I use Cocoa on the Macintosh.
Dan.
#21086 - Popstar - Sun May 23, 2004 7:58 pm
I'm a 2D artist who never had the benefit of a tool programmer on my team, so I decided to do my own tool programming in Blitz Basic. I've made a tile reduction tool and a tool to convert a picture with a bumpmap into an isometric landscape.
I've also created photoshop actions to convert 24 bit images into tiled images with 16 palettes of 16 colors each. Which I've also written about here.
_________________
-One pixel to rule them all, one pixel to find them.
-One pixel to bring them all, and in the darkness bind them.
#21179 - Cearn - Tue May 25, 2004 1:21 pm
| abilyk wrote: |
... to hear some tips from those who've already done some extensive tools development, like Nessie and Cearn. Cearn, I've read through the "Coding Lessons Learned" section of your Usenti help file. Some good information there, despite the fact we're not using MFC. More information such as this, as well as more basic discussions, such as "What GUI API should I use?" would be a great addition to the forum and the community.
|
Someone actually took the time to RTFM? *boggle* And my tool development is hardly extensive, Usenti and Mirach are basically it.
As for what GUI to use, the thing about GUIs is that they are often platform dependent. As far I know only Java lets you have a GUI that'll work on all systems (although I did hear that GNU had some cross-platform GUI stuff).
The reason I've used MFC is because it does a lot of things by itself: recent file lists, toolbars/tips context menus, file dialogs, etc. These things and some others will make the programs look and feel like familiar windows programs, making them easier to get into. Additionally, every Windows version has the necessary MFC dlls, which will keep the size of the executable down as well. For example, all Usenti's tools use standard GDI functions, which not only saves space and execution time (blitting by hand is so much slower than using BitBlt), but also means you can do complicated functions like floodfill with ease.
#21186 - Nessie - Tue May 25, 2004 4:17 pm
MapEd also uses MFC.
Of course, MFC is not without problems. Overall though, I feel it allows me to develop an application/tool significantly faster than other methods, so I think it's easily worth it.
#21192 - tepples - Tue May 25, 2004 5:34 pm
| Cearn wrote: |
| As far I know only Java lets you have a GUI that'll work on all systems (although I did hear that GNU had some cross-platform GUI stuff). |
I know of several GUI libraries that work on multiple platforms: - GTK+
- Qt
- wxWidgets
- Allegro
- SDL
- Win32 (through Winelib on X11 systems)
| Quote: |
| For example, all Usenti's tools use standard GDI functions, which not only saves space and execution time (blitting by hand is so much slower than using BitBlt), but also means you can do complicated functions like floodfill with ease. |
The Allegro library, which I'm currently using for editors, has a blitter and a floodfill.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#21238 - Cearn - Wed May 26, 2004 8:43 am
Allegro, *smacks forehead* how could I've missed that one! Maybe I should get a little more sleep.
#21248 - bats - Wed May 26, 2004 12:53 pm
I've basically written every command line tool that I need in perl. It is ridiculously easy to develop tools that process files (text or binary) in that language. The fact that it has a built in debugger has saved me a lot of time, too.
Example:
I whipped up a perl tool that processes an xml file with resource data in it (make-style where a dependency's timestamp determines re-making) in a few hours.
I've written all my editor-style tools in Visual C# .NET. Managed code is quite a bit slower than natively compiled code, but it's a breeze to develop. I worked in Visual Basic 6 before that, and found the language a little limiting (I hear VB .NET is better, but why use that when you have C#?)
Ben
#21278 - wintermute - Wed May 26, 2004 5:12 pm
There's also fltk which I've been looking at recently http://www.fltk.org
Winelib looks interesting, I may have to investigate that and see if it's possible to port Xboo Communicator that way :)
[/url]
#21325 - sgeos - Thu May 27, 2004 9:20 pm
| bats wrote: |
| Managed code is quite a bit slower than natively compiled code, but it's a breeze to develop. |
Forget faster and slower. Is it slow? I have found that generally speaking, the answer is no.
-Brendan