TNT Basic Forums > Beyond Basic
< Last Thread     Next Thread >
Thread        Post A Reply

12-07-2001 11:24

Posted by:

Click Here to Email Socrates   Find more posts by Socrates

Interpreted? I would have guessed byte code. I'm quite impressed with the speed then, I must admit. It's hard to tell from a lot of examples. The outdoor scrolling is impressive but isn't doing much in the program code if you think about it. The fireworks example though was a good benchmark. I cranked it up to 32 fireworks by 32 particles and got no intolerable slowdown on a 500MHz G3 Powerbook. That's 900 odd calculations, drawing commands and loops in a 30th of a second. Not to mention that 60fps is a very impressive speed at it's default setting. RB can't get better than 30fps in my experience, even when compiled (I use that in the loose sense of the word), even if you aren't drawing anything except a blank screen.

Does TNT get any further speed improvement for the standalone applications versus the ones ones that run under the TNT application, or does it just bundle them in the same file without modification?

12-07-2001 11:38

Posted by:
John Treece-Birch

Find more posts by John Treece-Birch


It's fast for an interpreter but it will be much faster when we move over to byte code. Having said that, most commonly it spends most of it's time handling graphics so it will probably yield better results if we work on optimising that up. Don't worry though, we'll do both ;)

I had no idea RB was that slow but it is aimed at apps rather than games so I guess they're not bothered. They will probably fix that soon though.

And no, unfortunately there are no speed gains from building a finished app. Sorry.


12-07-2001 18:22

Posted by:
Chris D

Find more posts by Chris D

Thats funny RB can get 200FPS on a blank screen on a powerbook/400.

So what are you doing with it?

Byte code issues....
Im worried that TNT does ot currently scale well.
Simply because it seems to do polling or a main loop
for every program... Am I correct?

BTW B! uses a interpreter with LIGHT byte code compilation... its is still and interpreter but the tokens have been changed to numbers when the scripts are preprocessed.

What I did you get around scripts doing any polling it
to have all sprite recieve and later post events.
Then scripts are only run in response to events.

This is also how Unreal Tornamet does it etc...

That way only like 10% of the time is spent in scripts.

Right now its looks like TNT spins in loops with a script constantly running. Am I correct?

BTW I will probably write up a simple R-Type clone
like I have used for testing RB...

12-07-2001 18:23

Posted by:
Chris D

Find more posts by Chris D

Fire works

Opps didn't see that part.
I have to run that.
That sounds really impressive.

12-07-2001 18:29

Posted by:
Chris D

Find more posts by Chris D

I played with fire works and it looks like that
interpreter is running very nice.

Well at least REALLY nice compared to mine written in
RB... just shows how slow RB is.... :P

Im not compareing it to a byte code compiler in C++
since I don't have a great way to bench mark then
with graphics right now.

Good Job :-)

12-09-2001 18:05

Posted by:

Click Here to Email Socrates   Find more posts by Socrates

RB Speed

By blank screen I meant an empty sprite surface or a blank double buffered fullscreen window updating itself at top speed. It seems that these are a fairer comparison to TNT than a literally blank screen, since RB is event driven and therefore need literally not be doing anything for non-graphic tasks. The point is, to acheive non-flickery graphics, you start at 30fps and it's downhill from there.

Of course my memory may be off, and I don't recall what version of RB it wa (they claim tohave made some small speed improvements), but I think you'll be hard pressed to do much better than 30fps with it.

12-10-2001 15:30

Posted by:
Chris D

Find more posts by Chris D

Blank screen

Yup I meant the same things by a blank screen.
I do get like 200 FPS with the srite canvas.
Now having it flisker free is a different issue
though I don't rember getting any.
Im playing with RB 3.5 now.

When you ran RB above 30FPS did you see tearing
in the screen?

12-10-2001 15:37

Posted by:

Find more posts by Socrates


Not sure now actually. I ran my tank game again as an experiment and despite the wildly swinging FPS counter (I think I did an integer divide where I shouldn't have) it seems to pop up 60FPS on occasion, and that's when it's calculating a (very short) draw tree and drawing the (very few) polygons on a double buffered screen.

Must've been a bug in my test program, my bad. RB seems to be faster than I remember.

06-16-2002 14:45

Posted by:

Find more posts by Namoreh

actually, Im getting excellent framerates in my current sidescroller project (with collisions already in place).

I never use the spritesurfaces NextFrame event, I always set up a method called "Game" and in that method set it up like:
#pragma disableBoundsChecking 'gain speed if you trust yourself with not accessing anything that doesn't exist

//whatever your NextFrame event would do
Loop Until Keyboard.AsyncKeyDown(&h35)
from my experience I can increase the framerate incredibly with this method of doing it.
of course, you'll have to change everywhere you say "me" with "SpriteSurface1" or whatever you named the spritesurface.

07-19-2002 11:04

Posted by:

Find more posts by Socrates

game loops

that is certainly faster, but has the disadvantage that it doesn't allow for background tasks like garbage collection.

This basically means that if you are dynamically allocating objects in your game loop (say that every time you fire a bullet a new object is created and then when it hits the enemy it is discarded) then they will not be destroyed when you stop reffering to them, as normal, and you'll get a memory leak.

I wouldn't have noticed this but for a game I wrote that synamically allocated and discarded pictures in a loop. This used up enough memory to crash after about 30 seconds, which alerted me to the problem.

Of course, you can avoid this by not dynamically allocating objects, but rather having a fixed array of bullets which have an idle property for when not in use, but this kind of thing can make a program a lot more confusing.

As for #pragma disableboundschecking, the rb help says that this only works on one dimensional boolean arrays. I don't know is this is true or just a mistake, but it makes the command virtually useless in the latter case, since most of your arrays are likely to be either integers of objects (pointers).

#pragma disablebackgroundtasks is much more useful though, and #pragma disableautowaitcursor is good if you've got loops as it gets rid of that annoying watch that appears (even better get the monkeybread software plugin and you can hide the cursor completely, along with loads of other great functions).

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.