forums

TNT Basic Forums > Feedback
A wish list
< Last Thread     Next Thread >
Author
Thread        Post A Reply

07-14-2003 16:55

Posted by:
Boo

Click Here to Email Boo   Find more posts by Boo

Well, I've been tinkering with TNT to see how much I like it over the last several days, and here's a few things that I've noticed that would make life a little easier:

* Alpha-channel support for image resources. Currently, it doesn't appear that an image can have transparency information unless it's an image bank (is this true?). Ideally, images could store their transparency information themselves for use in maps or elsewhere. Also, if I import a file that already has an alpha channel in it, it should be able to remember that. I shouldn't have to create a separate grayscale file to import.

* Maps should be able to draw their tiles out of image banks, should be able to display all the layers, and should be able to display some layers *on top of* sprites, so that sprites can walk behind things that appear on the map.

* A way of organizing code so it isn't all in one big window. This could simply be a menu on the left that lists blocks of procedures. For instance, if your game has two modes (wandering around on a map versus fighting a battle, for instance), it would be handy to be able to only look at the procedures regarding whatever we're working on.

* I read somewhere that functions are coming. That's good - having to use 'result int' is tiresome.

* Being able to add more information to map objects and map polygons would be good. Ideally, it would be customizable fields, but it could also be just a string value.

* Maps shouldn't throw an error when they are displayed over-edge. They should wrap. That way, if people want wrapping maps, they can do them, and if they don't, they can add the code to constrain the map motion.

(I hope I don't sound like I'm ripping on TNT Basic here - it's actually very nice. These are just things that I think would make it even more powerful without too much complexity being added. Keep up the good work!)

07-14-2003 18:14

Posted by:
eekaydee

Location:
CA, USA

Click Here to Email eekaydee   Find more posts by eekaydee

I also think it would be nice to be able to display all the layers of a map at the same time. Is there a way to do this?

I just used the polygon names to store data, but the object names cannot be read.

As for the procedures, did you know of the little blue "P" button at the bottom left corner of the heiroglyph code editor? Clicking on it pops up a little menu showing all your procedures and allows you to jump to one.

07-14-2003 21:38

Posted by:
Boo

Click Here to Email Boo   Find more posts by Boo

Yeah, I knew about the little blue "P", thanks to another thread on these boards.

What I was suggesting was more along the lines of grouping a bunch of related procedures together into logical groups for clearer perusal. Jumping to a procedure name is one thing, but being able to look through a bunch of related code to get a feel for how it works is more difficult.

For instance, suppose your game can be in one of three modes, and the programming is pretty much separate for all three. You could place the code for each mode in a separate folder so that you wouldn't have to scroll through or even look at code from a part of your game you're not working on. It would be much nicer to be able to page-up and page-down to the top and bottom of a small code block and have it all self-contained, rather than having to visually parse where the code of interest starts and stops.

Another use of this would be to separate "support" functions from "logic" functions. For instance, if you develop, say, a vector support library, but you don't want the particulars of it cluttering up your programming, you could hide that away in a separate code folder so you wouldn't have to look at it.

Another benefit of this would be to facilitate code sharing between developers - if you could save off folders and load them, you could share that vector math support library with someone else. It would show up in its own little folder, and it would keep a nice separation of your code from their code.

07-16-2003 20:29

Posted by:
someone

Location:
Quebec ( Canada )

Click Here to Email someone   Find more posts by someone

You CAN display many layers. You just need to use sprites. Look in programming Q & A, it's one of the most recent posts, everything is explained

07-16-2003 20:35

Posted by:
Boo

Click Here to Email Boo   Find more posts by Boo

I know - I was the guy who posted that. What I meant was to have the multiple layers naturally supported within the map object. Having to roll your own sprite-based map engine kinda minimizes the value of the map object type (although I guess you could still use the editor to generate data).

With just a few new (seemingly simple, although who knows what it looks like under the hood) features, the map object could really multiply its usefulness, so I figured I would suggest it.

07-21-2003 22:51

Posted by:
Mark Tully

Location:
TNT HQ, England

Click Here to Email Mark Tully   Find more posts by Mark Tully

Hi there,

Thanks for the feedback!

* Alpha-channel support for image resources.

We're planning to add this in a future version, it's a fairly common request.

* Maps should be able to draw their tiles out of image banks, should be able to display all the layers, and should be able to display some layers *on top of* sprites, so that sprites can walk behind things that appear on the map.

There's quite a few features missing from the map layers stuff. We'll try and build on it more in a future version. It would be quite easy to layer tiles and sprites together. Hopefully we'll get chance to look at this in the future.

* A way of organizing code so it isn't all in one big window

Yeah, we'd like it so you could organise your code better. One idea I was throwing around was to have project files that were 'libraries' that you could link to your project and use all the code/graphics etc from it as if it was in your project. With suitable gui enchancements to stop you having to continuously switch between the different files this could help a lot.

The idea is to try and avoid having the same code duplicated in many programs to ease code reuse.

Any thoughts?

* I read somewhere that functions are coming. That's good - having to use 'result int' is tiresome.

This is a limitation in the interpreter, we'll address it when we redo the core which should be this year.

* Being able to add more information to map objects and map polygons would be good. Ideally, it would be customizable fields, but it could also be just a string value.

We've played around with this before and have means of having customisable fields. It's something we hope to improve upon in future.

* Maps shouldn't throw an error when they are displayed over-edge. They should wrap. That way, if people want wrapping maps, they can do them, and if they don't, they can add the code to constrain the map motion.

I guess it should be an option really.

Thanks for the feedback, wish we had more time to implement it all! But keep it coming as we really do keep putting in on our todo list and it really is all being genuinely considered, even if it does take ages for the results to get to you!

Cheers,

Mark

07-22-2003 00:34

Posted by:
eekaydee

Location:
CA, USA

Click Here to Email eekaydee   Find more posts by eekaydee

quote:
We've played around with this before and have means of having customisable fields. It's something we hope to improve upon in future.


Sounds like this might come a lot later. If it's any easier to implement, I would be more than happy with just being able to read the object names, like you can with polygons. The object names could be like object string values, and I could store all the info I need in them.

07-22-2003 14:23

Posted by:
someone

Location:
Quebec ( Canada )

Click Here to Email someone   Find more posts by someone

>
I would be more than happy with just being able to read the object names, like you can with polygons. The object names could be like object string values, and I could store all the info I need in them.
>

I guess that's not the idea, because all objects of the same type would have the same string.

07-22-2003 16:36

Posted by:
eekaydee

Location:
CA, USA

Click Here to Email eekaydee   Find more posts by eekaydee

quote:
I guess that's not the idea, because all objects of the same type would have the same string.


Oh yeah, you're right. I forgot about that :) Well, you could just make each object a separate type, and just store the real type number in the object's name string.

For example, objects types 1 to 10 each have only one object. The first 5 are dog objects, and the last 5 are apple objects. So, the first 5 types, each actually representing a single object, all have 1 in the beginning of their name, meaning dog. Likewise, the last 5 types all have 2 in the beginning of their name, meaning apple.

07-23-2003 08:00

Posted by:
eekaydee

Location:
CA, USA

Click Here to Email eekaydee   Find more posts by eekaydee

quote:
Well, you could just make each object a separate type, and just store the real type number in the object's name string.


I just realized that in that case you might as well put the data in the program somewhere and use the object type to get the data for each, and you wouldn't need the name anymore. So forget I said that :)

All times are GMT        Post A Reply

Forum Jump:
< Last Thread     Next Thread >

< Contact Us - TNT Basic >

Powered by: vBulletin Lite Version 1.0.1 Lite
Copyright © Jelsoft Enterprises Limited 2000.