Labyrinth Preview

Hi Eros,

I don't want anyone to get crazy so here is the code :)
Of course it was designed as the bug correction test ... so anybody who want's to test he must install at least thinBASIC 1.0.9.5 preview, because only with that you will get proper single line IF handling.

Thanks Eros for ( as always ) super fast debug and release !

Bye,
Petr

P.S. The code is quite large, so you bet I will update it and comment with some tutorial on TBGL pages in next weeks

P.P.S. Features of the latest version
:arrow: type variables for collision data storage
:arrow: particles and reflections
:arrow: shooting ( even in slow-motion now)
:arrow: spectacular explosions :)
:arrow: enhanced fileformat supporting multiple textures in level, even fog effects

Wow,

great! The wrong forum is pardoned. :lol:

Roberto

Hi Roberto,

thanks, how could it occurr to you I posted in wrong forum, it contains code which was executed in bad way with previous versions :lol:

It seems my expression "Of course it was designed as the bug correction test " was a bad camouflage :D

Bye,
Petr

Thread splitted from Bug Report forum.

Petr,

wow, wow, wow. That's what I want to see!!!!
I will use this code to study new technique for speeding up again code execution. I want is fast, faster, fastest.

On my new laptop it runs at 55/60 FPS. I will test on other machines.

An info: what is the meaning of the symbold inside .world file?
. is open space
# is a wall
The others?

Ciao
Eros

Hi Eros,

the format is little bit messy, I just used "level", which friend of mine uses for some AI program in Java. He had "just" 2D output in Java, so we settled it would be nice to watch replay of movements of robots in the labyrinth in 3D, both using robot fixed camera and overall view of the labyrinth.

The format of level is following:

First row:10X20Y means level is described as field of 10x20 characters
Second row:Whatever, originally some more numeric data
Next rows:
# is wall, only tiles with this character will be bumped as wall at this time
. is generally free space
g as "gold", treasure for the robots
b as "battery", energy source for robots
r,l,u,d are initiall positions of the robots, facing right,left,up and down

Of course in the preview there are no robots, treasures and batteries at the time, I want to create fully animated mechanical beasts in thinEdge and then put them there :)

Bye and thanks for moving the topic to place where it belongs :),
Petr


P.S. The main bottleneck of posted source is the particle engine, if you set %MAXPARTICLES to one, it will run much faster. I have to optimize it more, even the collision map should be arranged a little bit.

Too serius people live here, for me no problem for the 'post area', just a little witticism :D
I got an error on line 137 Token X, I'll have to check may be it's due to wrong version of my TB.

Regards,
Roberto

Hi Roberto,

yes, it is ideal to run this script under latest version, for example 1.0.9.5.

The older ones had problems with single line IF statement, and this caused the problem with "X" member of TYPE variable

Petr

I would like to add lateral moving with CTRL key.
I mean if CTRL+LEFT move lateral LEFT without turning left, if CTRL+RIGHT move lateral RIGHT without turning right.

How to do?
Eros

Hi Eros,

good suggestion. All modern first person shooters allow this kind of move.

The solution is pretty simple, just update the code in control checking area with this:
[code=thinbasic]
IF GETASYNCKEYSTATE(%VK_RIGHT) THEN
IF GETASYNCKEYSTATE(%VK_CONTROL) THEN ' straffing
CamPosX = CamPosX + 1.5/FPSCount * SIN(CamAngleLR+1.57)
CamPosZ = CamPosZ + 1.5/FPSCount * -COS(CamAngleLR+1.57)
ELSE
CamDeltaAngle = 2/FPSCount
END IF
END IF
IF GETASYNCKEYSTATE(%VK_LEFT) THEN
IF GETASYNCKEYSTATE(%VK_CONTROL) THEN ' straffing
CamPosX = CamPosX + 1.5/FPSCount * SIN(CamAngleLR-1.57)
CamPosZ = CamPosZ + 1.5/FPSCount * -COS(CamAngleLR-1.57)
ELSE
CamDeltaAngle = -2/FPSCount
END IF
END IF
[/code]

If CTRL is not pressed, it will behave as usually
If yes, it will simply move camera in direction perpendicular to current vector of movement.
CamAngleLR as angle of camera for left right moves :) is directed right forward, by adding/substracting ~half of famous number Pi ( Pi/2 in radians equals to 90 degrees ) we will move by side by distance of 1.5/FPSCount ( move relative to actual frame rate )

Hope this is what you wanted,
Petr

Pretty sure you would have the right immediate solution 8)

Please keep the labyrinth download file updated if you add significant code (if you like of course)

Thanks
Eros

Petr,

just one more thing, if possible, also post labyrinth preview image here. It was left in post under bug report :cry:
Maybe 2/3 images could help possible users to understand what's going on with TBGL potentialities.

Thanks
Eros

Hi Eros,

new version uploaded - it has the side walk implemented and also there are some tiny optimizations on the particle engine ( prototype particle is display list, it means parsing of 1 line instead of 25 or so ).

Also, regarding the framerate on your laptop - if it is about 50-60 FPS independently on resolution, it can be graphics card driver feature - probably the vertical synchronization is enabled.

V-sync assures the display is not updated more frequently than it is possible ( no 333 FPS on 60Hz display ). If this is enabled, it has possitive impact on generated image quality, no hectic redraws are done.

Thanks,
Petr

Thanks a lot Petr.

I'm working on optimization too inside thinCore.dll module.

I've already got some more speed but not much at the moment. I will test on a different machine tomorrow. Mine is too fast and sometime it is difficult to understand if some changes had effect or not.

Intel Centrino Duo is really amazing!

Ciao
Eros

Petr fantastic!

New moves are fine. Particles are much faster and FPS is between 60/100 not sure exactly what. Maybe an average calculation should help understand better.

Now I ask another one (please excuse me :D ): moving head? I mean looking UP and DOWN simulatying movimg of the head?

Ciao
Eros

I couldn't be more lucky to have a thinBasic user like you :occasion:

Thanks a lot for all.

:D

thanks Eros, I couldn't be more lucky to have a language developer and friend like you !
Version with moving head up and down ( using PgUp / PgDown ) is ready to download.

The "jumping", hard to read FPS report, is still there I will think about it.
The average value would be more suitable, maybe it could be presented in some graphics way...

Petr

Works perfectly!

Petr,

is it difficult to add a missile/rocket ?
Just for fun.

Eros

Hi Eros,

of course it isn't :).

I will have to redesign the collision code in some way to be more general, with some BYREFs. This would allow to use it for both player camera and bullets or missiles.

And it would be also good to include something to hit. Some poor robotic victims :). I will work on it during this weekend. At least some simple shooting should be easy to do.

Bye,
Petr

Hi Eros,

version with shooting ( but no enemies yet ) is uploaded.

You ( well not you as you have the hellish fast laptop :) ) may experience some performance hits, so the number of rockets on scene at once is limited to 12. They collide with the environment, even with the floor and top.

Petr

:D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D :shock: :P :D

:)

Little bug catched in version 1.3 ( bad collision with one wall ), corrected in new version 1.3B

Petr

Little problem in this version.
Fire a rocket and stay there looking. Fire does not disappear and remain there till another rocket is fired.

Hi Eros,

yes, this behaviour was not very realistic. I arranged it now, luckily it has very positive effect on performance. The version is marked 1.3C - I updated the file.

Thanks,
Petr

Hi Eros,

the version 1.3E brings more naturally looking explosions + destruction effect.
What is destruction effect? Any time you hit the wall, you will see explosion AND pieces of wall flying around you :)
Especially in case of multiple explosions it could look interesting.

Hope you like it,
Petr

Of course I like!

I've noted that if a rocket is on the screen, movements are ok.
If just moving around (and no rockets fired) movement it is quite slow.

Eros

ADDED: I think I'v efound the point where the problem is but do not have the correct solution. Problem is inside "help_CalcFramerate" function:

Code:

---

  FUNCTION help_CalcFramerate() AS SINGLE

    GLOBAL LastTime AS DWORD
    LOCAL ThisTime AS DWORD

    LOCAL FPS AS LONG

    ThisTime = GETTICKCOUNT
    FPS = 1000/(ThisTime-LastTime+1)
    IF FPS = 0 THEN FPS = 1
    LastTime = ThisTime
   
    FUNCTION = (FPSCount+FPS)/2

  END FUNCTION

---

and exactly at line "FPS = 1000/(ThisTime-LastTime+1)"
If I substitute 1000 with a lower value it gets much better and movements are faster but still if rocket is present on the screen movements are much more faster.

Eros

Hi Eros,

strange problems...

Off course the lower number instead of 1000 will take effect, all movement calculations are based on returned value, so change from 1000 to 500 will make all movements twice as faster ( and also bad FPS number on screen :) ).

That's why I callculate frame rate - when is lower, I need to make bigger steps with camera to compensate it.

Conclusion ? I have to study it more, but it is evident when rocket appears, thinBASIC has more calculations to do, framerate goes down and so movements are faster. Much faster because GetTickCount has still too poor resolution for scripts which are running on NASA boxes :).

Now I must go out, but I will study QueryPerformanceCounter later, maybe it could help.

Thanks,
Petr

Message via Messenger:

Quote:

---

hi eros, just quick-check : the speed difference beetween with/without missiles is by factor of ? ( just your guess )

how much ( if at all ) drops framerate ?

---

On AMD64 Atlon it is of 4/5 times. It is like accelerating on a byke.
On Centrino Duo it is about 2/3 times.

It seems the more complex scene the more speed ;)

Whan a rocket is fired, FPS remain quite stable, when no rockets on the screen, I can see FPS number going from 300 to 10 on both machines.

Eros

Hi Eros,

maybe you could try to dimensione FPSCount as QUAD integer and then modify the routine to:

Code:

---

  FUNCTION help_CalcFramerate() AS SINGLE

    GLOBAL LastTime AS DWORD
    LOCAL ThisTime AS DWORD

    LOCAL FPS AS LONG

    ThisTime = QUERYPERFORMANCECOUNTER
    FPS = QUERYPERFORMANCEFREQUENCY/(ThisTime-LastTime+1)
    IF FPS = 0 THEN FPS = 1
    LastTime = ThisTime

    FUNCTION = (FPSCount+FPS)/2

  END FUNCTION

---

It seems to have a better catch for higher framerates, I hope at least :)
I haven't updated the official version with that because I can't say it helps or not; I never go to 300 FPS on my box :)

Petr

Much much better.

FPS remain quite stable (70/80) and speed is ok. When rockets are fired there is a speed decrease to 20/30 FPS but this is a problem of the interpreter (more calc to do). Nice.

Thanks a lot and do not forget to update the source.
Eros

And of course now another request :)
It seems nothing is impossible for you :x

What about having the view-finder on screen? I mean a little cross indicating where the rocket will be fired.

Ciao
Eros

Hi,

Quote:

---

It seems nothing is impossible for you :x

---

I will keep you in this illusion as long as possible :D

Quote:

---

What about having the view-finder on screen? I mean a little cross indicating where the rocket will be fired.

---

Hope I understood you correctly, please check latest download :)
I will try to make more sophisticated HUD ( head up display ) with health and ammo status ( whenever it will make sense ).

Thanks and keep suggesting :),
Petr

Yes, exactly. Perfect.

Sure, I will not stop suggesting ... ;)

Flash example:
http://www.thinbasic.com/public/prod...rynth.swf.html

AVI file (size: 6Mb):
http://www.thinbasic.com/public/prod.../Labirynth.avi

Wow,

perfect in game videos. I like the new room and also the textures !
I wanted to make something simillar, but it seems no software can capture it in realtime on my PC :)

Thanks, thanks !
Petr

P.S. It seems there is a bug viewed on the AVI, when you passes the walls.
I think I know what's the reason, I will fix it tomorrow afternoon

No, there is no bug.
I removed collision for a while because I wanted to go out to see ... what was going on :D

I will send where to find free video recorder software.
Eros

For video rocording I've used CamStudio 2.0
Yoy can get from here: http://www.brothersoft.com/dvd_video...udio_3944.html
See Download button below in the page. It is an old software but working fine for what I need. Seems it has been bought by Adobe but version 2.0 is free and perfectly working.

I will return home this night.

See you
Eros

Hi Eros,

I'm happy to hear you disabled intentionally the collisions, it scared me.
Currently they could appear problems with collision but only if framerate drops under 5.

The CamStudio is realy nice, thanks for the link. Although it also steals some performance it is not so much. Good one.


Petr

P.S. The texture in your AVI looks perfect, where did you get it ?

http://www.grsites.com/textures/
Use drop-down on the right to choose type.
A lot of free textures.

Ciao

Perfect,

the number of textures is quite huge, that's fine.
And also free sounds! I think it's time to play with MCI to give the explosions some more juice.

I'm quite busy today, but I think tomorrow afternoon will be ideal time for next update ;)

Bye,
Petr

Hi,

I'm still inspired by your mod level in AVI video, so I updated new version.
In this one, you can create as many user levels as you wan't, you just have to specify which file to load. Each file can have unique texture set ( texture 'n' wall :) ).

As tiny bonus, you can go to bullet-time ( slow motion mode ) to watch explosions in detail - just turn it on/off using SHIFT key.

Bye,
Petr

Nice Petr :D

But better to talk "SlowMotion" view and use a key like "S". Very nice effects when rockets hit the wall. Quite professional !!!

In my example I've also used the SHIFT + UP/DOWN key to accelerate movements. It is nice when maps are big.

What do you think about a challenge for the best map? I will do mine in next days ;)

But we need something to destroy. Even a simple red target would be enough. But the target, once destroyed, must disappear from the map :twisted:

Ciao
Eros

Hi,

Quote:

---

But better to talk "SlowMotion" view and use a key like "S". Very nice effects when rockets hit the wall. Quite professional !!!

In my example I've also used the SHIFT + UP/DOWN key to accelerate movements. It is nice when maps are big.

---

Thanks :D. One of the first games which offered bullet-time was Max Payne, which used [shift] key. But your idea with [shift] for "running" is really good. I will implement it in next release, and the SlowMotion will be moved to [S]. Thanks!

Quote:

---

What do you think about a challenge for the best map? I will do mine in next days

---

Great idea! I will try to make a tiny changes to the format, to make it possible to use various textures for both walls/floors. You could define something like:

Quote:

---

WALLS "#",mytexture1.bmp ; "@",mytexture2.bmp
FLOORS ".",myfloortexture1.bmp ; ":",myfloortexture2.bmp

---

That could make the level more rich on graphics.
I'm awaiting your level with interest !

Quote:

---

But we need something to destroy. Even a simple red target would be enough. But the target, once destroyed, must disappear from the map

---

Yes, they must die in a cloud of green slime :D I was thinking about some flying "insectoids" - more fun to target them.

Thanks Eros for as usually very interesting suggestions,
Petr

Fine. Regarding target a simple one is enough for starting :D

On file format it would be nice to find a easy format to follow and to be used in some kind of map editor.

I think you should consider the following info to be present:
[list][*]a file ID able to identify the type of file. Something like ##MAPFILE## or whatever unique[*]a description of the map[*]x dimesion separated in different line[*]y dimesion separated in different line[*]the info about map elements: textures, char to use in map, ... like your post idea[/list:u]

Another option could be if the engine could be able to pass from one map to another. This could be used to make doors in maps. Difficult, isn't it? ;)

What ebout Jumping?
And a first person armour present on screen like old first person games?

This is just for today.

Ciao
Eros

Petr,

I'm playing with Labyrinth code and maps.

I think that inside ParseWorldToList function after the line:

Code:

---

    zSize = VAL(PARSE$(datastr, ".", INSTR(mask, "Y")))

---

you should add the following:

Code:

---

    IF UBOUND&#40;TheData&#41; < zSize THEN REDIM PRESERVE TheData&#40;zSize&#41;

---

This avoind GPF in case x/z dimension does not correspond to the lines of the map. Or instead of going on, give an error to the user and exit.

Ciao
Eros

Hi Eros,

this is interesting. I think it should end with an error message in this case.
I will arrange it. I know the level loading is really fragile in actual versions.

I'm also working on the new file format, at this time it looks something like:

Code:

---

##TB_LEVELCHAR_FILE##
MAPNAME;My first level
XSIZE;10
YSIZE;16
STARTPOSX;1
STARTPOSY;1
STARTANGLELR;90

BEGIN_WALL
  "#","sfWall.bmp"
  "@","sfWall2.bmp"
END_WALL

BEGIN_FLOOR
  ".","sfFloor.bmp"
  ":","sfFloor2.bmp"
  "p","sfFloor.bmp", "nf2.tblevel"
END_FLOOR

BEGIN_LEVEL
:.@@..#...
......p...
.####..#..
.#.....#..
.#..####..
.#...#.##.
.#.....##.
.#.##..#..
.#..##.#..
.#.....#.#
.###..##..
.#........
.#####....
..#....##.
..#....#..
#.......#.
END_LEVEL

---

It is already working, even the portals to jump from one map to another.
As you can see, you define portal just as simple as assigning file to the floor tile.

I hope to upload it this evening.

Thanks,
Petr

I uploaded the version 1.6

It contains the new level format ( few changes - multiple textures for walls and floors, individual setup of initial position and camera angle, fog setup and ability to jump from one map to another ).

Also the keys were rebinded so you can use [SHIFT] + arrows to run and [S] to toggle slow-motion.

Loading of old format is still included too.

There are two new maps. The first, called "startTheEldestDungeon.tblevel" is stylized as from some old classic dungeon game. If you manage to find the doors in the dark, you will be teleportated to ... absolutly ugly environment :).

Bye,
Petr

You are fantastic! A drake!

I'm astonished by thinBasic capability, TBGL power and your ... fantasy, development speed, ...
Did I say you NASA asked me about you :D

Thanks, thanks.

Prepare to have more requests !

Eros

:D

Thanks Eros, this stuff is piece of cake in thinBASIC 8).

I did not forgot about your previous request I have not implemented yet, like displaying a gun. I'm thinking about possible binding even small thinEdge models, for which cubic collision is sufficient ( like small fontains, chests and so on, to make the environment little more attractive ).

But the next stop will be AI and some simple enemies. I like maps with life in it. Especially if I can smash it with rocket :lol:.

Thanks and please suggest any other features !,
Petr

Petr,

a frind on PB forum suggested to calculate the average FPS during all the game. This can be of some usage to give a complete view of the speed.

I've done a modification like that but please correct me if I'm wrong.

Before main WHILE loop added:

Code:

---

  GLOBAL nFrames AS QUAD
  GLOBAL T0 AS DOUBLE = TIMER
  GLOBAL T1 AS DOUBLE

---

Just after the WHILE:

Code:

---

    INCR nFrames
    T1 = TIMER

---

and to print on screen:

Code:

---

    TBGL_PRINTFONT FORMAT$(FPSCount/SlowMotion, "000")&"now",-0.045,-0.035,-0.1
    TBGL_PRINTFONT FORMAT$(nFrames/(T1-T0+1),"000")&"avg",-0.045,-0.038,-0.1

---

where "now" mean instant FPS while "avg" is the average FPS.

What do you think?

Ciao
Eros

Another little one regarding ammonitions/fire.
Because GETASYNCKEYSTATE is too fast, what about this code:

Code:

---

    IF GETASYNCKEYSTATE(%VK_SPACE)  THEN
      IF TIMER - LastRocketTime > 0.2 THEN
        rocketLaunch
        LastRocketTime = TIMER
      END IF
    END IF

---

Just add a GLOBAL like

Code:

---

  GLOBAL LastRocketTime AS DOUBLE

---

Better would be every arm has its own properties, so rocket has maxrocketsonscreen plus interval time plus maxrocketsinthebag ....
But gun has other properties ...

Ciao
Eros

Hi Eros,

thanks for your work!
I updated version 1.6B with your code suggestions ( I just added a little arrangement to handle firing pauses in slow motion too ).

Very good idea to post it on PB forum, it seems Marco Pontello is catched :)

Thanks a lot,
Petr

P.S. Regarding arms they will be handled in more complex way ( arm will have a lot of TYPE properties ). I'm still thinking how to implement it in best way.

Nice changes! Firing is more realistic.

Thanks Eros,

it's your code which powers it.

I was trying tom implement some AI driven enemies yesterday, but it was little bit clumsy and slow :oops:. I must invent some better enemy handling.

I also thinked about "indirect object". Then you could type in your level file:

Code:

---

INSERT_OBJECT; %TOKEN_NonCollidableModel, 10 AT POSITIONS 1,1;2,2;3,4;

---

... where the 10 could be number of already ( custom made ) display list in the program. It would allow you to load decoration models in your prefered format and then use it.

What do you think? Maybe the guns could be "registered" in some similar way...

Petr

Not sure to understand what you mean exactly.

Regarding "10" you mean inserting those dynamic objects into a a display list in the code. But in this way you link the map file with the code while the map should be somthing general and independant by the program engine (the script code).

Well, because I'm not understanding well maybe I'm telling dummy things.

...

Hi,

I think you get it
10 meant to draw object previously "saved" in script code to display list #10

Of course, this *would not* be the only way to insert object, but sometimes it is easier to create some particular complex object using script in some advanced way, and save it into display list. So I thought it could be useful for some particular tasks.

Thanks for your opinion, I'm now thinking which model ( not level ) format should be used for general models. thinEdge seams to be good choice from my point of view, but I don't know if this would be suitable for you and others :).

Petr

Petr,

I can only say my opinion so take it as is.
This is your project so you drive it. And this is fine for me. Always.

That said, I absolutelly like the idea to use thinEdge to create 3D objects from little maps to complete landscapes to arms to characters. Obsolute power if we will able to work in this way.

The only thing I'm worried about is that the engine (the script, Labyrinth in this case) should be independant from the data it has to load. This will allow extreme freedom.

Another option just coming to my mind could be to transform Labyrinth script idea into a specific thinBasic module able to load thinEdge maps full of possible different options. This module could be something like a 3D engine much faster to play in and with all the power to be compiled. So, something similar to TBGL but specific to 3D first person games. You will have much more power for development.

Just ideas but always consider independence between engine and data.

Ciao
Eros

Quote:

---

The only thing I'm worried about is that the engine (the script, Labyrinth in this case) should be independant from the data it has to load. This will allow extreme freedom.

---

Quote:

---

Another option just coming to my mind could be to transform Labyrinth script idea into a specific thinBasic module able to load thinEdge maps full of possible different options. This module could be something like a 3D engine much faster to play in and with all the power to be compiled. So, something similar to TBGL but specific to 3D first person games. You will have much more power for development.

---

Eros I really like your ideas :occasion:

I'd like to write some module in future, let's say more game oriented. It would support both thinEdge models, something like like this labyrinth, block level format and some terrain rendering, which needs very different collision approach, general particle system, maybe even basic AI and sound handling.

At this time it is perfect to me to keep all in form of pure script, because this way I'm able to get even "insource" suggestions like yours regarding FPS count and missile firing techniques...

Only thing which my brain cannot understand ( I haven't slept much :D ) is your concept of entry data abstraction. Maybe something like "registering" data in token like this in datafile:

Quote:

---

REGISTER_DATA "m15", %file_thinedge
REGISTER_DATA "obj", %file_wavefrontobj

REGISTER_TOKEN "#", "mypreciouswall.m15", %collidable_using_box, %handled_using_my_wall_composer, params...

---

Where the file parser would handle data differently based on "equates".

Then the "matrix" of chars could have very general meaning. Maybe it could be possible to specify various matrices like a content layer ( first - just collision map, second - objects on scene, third - placement of AI elements ... ).

Do I understand it correctly ?

Thanks,
Petr

Petr,

take note of current FPS numbers.
Then download latest thinBasic 1.0.9.7 and please report me if any better performance.

On my NASA box I'm always above 100 FPS with this thinBasic update.
Thanks to your suggestion regarding debugging I discover that, when inside a function, every variable was read from the dictionary every time it was encountered. I've optimized this aspect reading from the dictionary only when function stack changes (it changes when a function starts or when a function ends). So, when inside a function, code interpretation is much faster then before.

I need a confirmation from your side of what kind of improvements you have got. Hope no GPF ;)

Thanks

Eros,

you are magician !

With previous versions of TB I got 22 FPS for the "dungeon" level normally, and I dropped to 10-12 FPS when firing all missiles. Playable, but small performance reserve for another code tasks.

Now? 45 FPS :!: when not firing rockets and luxury 27-29 FPS when all rockets exploding. That is not normal, that's voodoo magic ! :eusaclap:

I made some tiny tests yesterday, thinBASIC 1.0.9.7 is 5.4x faster than classic thinBASIC 1.0.1.1 on my PC. Although version 1.0.6.1 was fastest version ever for normal scripts ( 5.9x faster ), 1.0.9.7 is incredibly boosted in functions. Thanks again :shock:

Petr

P.S. When I started the script for the first time after installation from thinAir, it locked up :(. I'm afraid the GPF beast is still in the sources

Ok, 2 confirmations at the same time: speed :D and GPF :twisted:

Did it GPF only once?
If it will happen again please post a new bug into thinBasic bug report so we keep this thread dedicated to your fantastic game.

Thanks again and be prepared for another speed improvement.

Ciao
Eros