I've been looking at other people's responses on this forum for a little while, and thought I'd add my support for a few of the things that have been mentioned (and maybe add some more). And let me reiterate my admiration and appreciation for TNT Basic - I hope that it has a long and profitable existence. (So none of the following is a criticism as such, but rather represents those things that I feel will help cement TNT's place in Mac development circles)
My comments are broken into three categories - Hieroglyph (IDE), Functionality, Performance. I'm ignoring bugs, since I assume that they will get fixed just as soon as possible.
1) TNT is a great language because it is concise and powerful - you can do a lot with a few commands - but the IDE is terrible to work in when your projects start getting larger. We need a way to visually "collapse" or hide a procedure or set of procedures to assist with editing. Conversely, if this is too hard, then opening multiple windows on the same code would be okay, or even usng a split screen approach (although I'm not a great fan of this with smaller monitors).
2) Because a major benefit of TNT is the ability to do RAD, and therefore extensively prototype, I find that my procedures grow up in all sorts of order. Even if I use a consistent naming method (which I do), I end up with procedures that aren't necessarily grouped together in the code. Now obviously I can insert, cut or paste procedures wherever I like, and they don't need to be near each other for execution purposes, but if you've got four or five thousand lines of code with a couple of hundred procedures, it would be good to be able to have Hieroglyph re-order the procedures alphabetically, numerically or in other ways. Or, as above, to be able to collapse the procedures and then do a drag and drop to reorder them.
3) I know that this is a tough one, especially because Hieroglyph and TNT are separate programs, but we REALLY REALLY REALLY need a "step execution" mode when debugging. I know that you can set up "prints" to the console, but again, the idiosyncratic nature of the console means that you can't properly execute a program in graphics mode and simultaneously see what is happening in the code. I've spent many late nights chasing down a bug that would have been very simple to have picked up if I was stepping through. These things aren't as much of a problem if you're only writing little programs, but with the increasing richness of TNT Basic (and I would expect, its consequent popularity) you would have to expect people to start doing some larger and more ambitious projects. Setting useful breakpoints is obviously also required. And ... we must be able to print out the console or equivalent rather than just cutting and pasting. And, while I think of it, my TNT console always seems to overflow whenever I really need to see what has happened - we should be able to adjust the size of the console buffer or whatever you call it.
4) Related to larger procedures (not that I've found it a major problem so far) would be the ability to "bookmark" a line of code. Purists will insist that a procedure shouldn't get large enough for this to be a problem, but I've always found it a useful tool in other environments.
Functionality - people have raised a large number of potential enhancements though this forum. Notwithstanding that the relative difficulty of implementing some of the additions might be pretty high, the ones that I would find most important are -
5) True object orientedness (to coin a phrase), associated with ...
6) ... the ability to make calls to external objects. And I guess that we are really talking about an extensible architecture here, with potential for the concomittant problems of losing control and the integrity of the overall TNT Basic thing. Nevertheless, the nature of TNT Basic is that it makes some very complex programming tasks dead easy, but makes some very, very simple things unduly complex. I, for one, would like to be able to program the bulk of an application in TNT, but do a couple of maths intensive routines, or I/O, in a little Objective C chunk. I think that doing number 5) properly implies the rest.
7) Should be up the top of the list - a simple INPUT statement (the regular inverse of the Basic PRINT). This would remove a lot of the playing around with key mapping and " if pressed" and all the rest, when all the programmer really wants the user to do is to type in a string. I keep looking at the commands list thinking that I must have missed it - and if I have, then I humbly apologise, but really, even without complex string handling enhancements, this must be a given.
8) The ability to position the mouse pointer (and hopefully, an input cursor) at an x,y coordinate would be very useful in a whole bunch of ways.
9) Better file handling, supporting a wider range of regular file handling operations and, of course, file / record types. The ability to, for example, open an MP3 from disk, or load an image from disk as required by the program, is pretty important.
10) Operation in a window. Many of my "problems" are with the very poor performance of graphics hardware mode at higher resolutions. The ability to window the application and essentially have the program work on say an 800*600 space but still have the definition and graphics quality afforded by working at a monitor's preferred resolution would work for me.
11) Fleshing out the "line draw" commands to allow for the variety of draw parameters that are already available for other draw operations to be applied to simple lines. Agreed, few people are probably using the line draw commands because people are into richer graphics and sprites etc, however, I have a number of things that I would like to do with the line draw that currently would involve drawing thin filled polygons - which don't really look the way I want them to.
12) Selecting the colour mode, ie thousands or millions (or even 256 - yuck) as required. I understand that graphics hardware does millions and software does thousands, but we should be able to select this from within the program and negotiate the performance hit as appropriate.
13) Notwithstanding the value of these forums, It would be useful for the simple documentation to be a little more complete (for example, I was unaware that TNT could handle multi dimensional arrays until I tried it out). Before we get to the performance issues below, and while we're still on the subject of documentation, it would be quite useful for most of us if there was a little more information about how to write our TNT programs to optimise performance (that is if anybody actually knows).
14) Music, especially MIDI, isn't handled well enough and, I feel, detracts from the whole (excellent) quality of much of the graphics handling. I'm really disappointed in this aspect of TNT.
Performance - well we all want everything to go higher, faster, better etc but let's face it, TNT just invites you to put a lot of sprites on screen and do cool things with them, but it's not hard to hit the edge of the performance envelope and have everything slowing down too much. TNT Basic will not be useful for a number of my intended projects because -
15) Maths operations are too slow. Let's face it, most of us are using machines that can perform maths operations at a very high speed, under the right circumstances. I don't pretend to understand the complexities of creating TNT Basic - it would be way beyond me - but there must be a way of optimising simple arithmetic and trigonometric functions. Just has to be.
16) Graphics hardware mode is unuseable at higher resolutions, thereby robbing the programmer of all the cool sprite operations (rotate, scale etc) that are only available in hardware mode. My current project requires many (and I really mean many) more graphics files to be imported for use as sprites because I can't use hardware mode at 1024*768 with a reasonable frame rate.
Well, there you have it (if you got this far). It's getting late and I must away to bed. I would very much like to continue with TNT, and even some of the above would assist me considerably with my projects.
All the best,
TNT HQ, England
First of all -- thanks! That's some really useful and valuable feedback there, I'll go through it point by point.
Please pardon by brevity, I've just replied to this once and then lost my long reply through my stupidy - doh!
1) Collapsing procedures
Although I've never found this useful myself, there's been quite a few requests for this and it certainly warrants looking into further. I seem to remember AMOS Basic had similar features on the Amiga.
2) Better procedure management
We can look at this after point 1 is complete.
The debugger has been on our TODO list for a long long time. We'll get around to it eventually. You may have read elsewhere on the forums that we're going to be making some big improvements to TNT Basic's core over the course of the year. Throughout this, we'll be keeping in mind the debugger and making sure we make it as easy as possible to build in. We want one, you don't need to convince us!
4) Code bookmarks
Codewarrior has similar features called markers. You select a line of code, then add a marker with a name. The markers appear in a popup menu next to the procedures menu. Is that the type of thing you mean?
We'll be adding this soon.
6) Extensible architecture
This is unlikely I'm afraid. The main barrier is that for a 3rd party extension to do anything worthwhile, it would want access to TNT Basic's internal data structures (eg variable values, label locations etc), its canvases, other commands etc. This would require us to design, code, document and maintain an API (application programming interface) that has the potential to end up as large as the TNT Basic language itself. Given the size of our user base, and relative experience of our users, it is very unliekly that the huge amount of work we'd put into this would be worth it in terms of extensions produced by the community. Furthermore, it would also restrict TNT Basic programs to running on copies of TNT Basic with certain extensions installed, making it harder to pass TNT Basic examples around.
7) Better keyboard input
Yeah, we've been meaning to add this for quite a long time! Soon...
8) Position mouse cursor
We're looking into this.
9) Better file handling
We're looking at things like this at the moment. In particular we're trying to remove the 16Mb limit that is currently plauging several users.
10) Window mode
There's been numerous requests for this, we'll add it soon.
11) Better line drawing
Could you be a bit more specific?
12) Selecting colour mode
256 colours is unlikely because it brings with it a host of paletting problems. Furthermore, modern graphics cards are geared towards true colour depths such as 16 24 bit colour. It would be worth our while optimising for them rather than retrofitting 256 colours.
The ability to request 16/24 bit from within your program is an idea, we're at least going to look at adding a 16 bit graphics mode option in the future.
13) Better docs
As always with projects of this kind, they begin to reach a stage where authors find themselves needing to spend more and more time documenting and discussing new features rather than coding. What I would like to do is create a more community driven documentation system, where users can attach notes to our online help with their own experiences and comments, thus capturing the experience and enthusiasm that is so obviously present in these forums and using it to directly help others.
I've recently discovered Wikis and I've been wondering if we could do anything with them aswell. See http://macgamewiki.crissman.net/.
14) Better MIDI support
We hear you ;)
15) Maths ops are slow
We'll make it all go faster this year.
16) Hardware graphics mode is slow
We'll look into this.
I hope I've not been overly concise in my replies. This type of feedback is really valuable to us and I'd be happy to discuss any point in further detail.